DBLX Version compatability
DBLX3 is compatible with all DBLX 2.2 table formats.
DBLXClient3 and DBLX3jdbc JDBC driver and DBLX_ADO ADO.NET driver are compatible with DBLX3 in any language. (Java client with C# server, or whatever combo you want)
DBLX3 clients are not compatible with DBLX 2.2.
DBLX 2.2 is compatible with the .dat and .edat table formats. DBLX 2.2 in Java and C# can read and handle the same data files.
DBLXClient 2.2 is compatible with the DBLX server in the same programming language. That is, DBLXClient for Java will work with DBLX 2.2 Java and DBLXClient for C# will work with DBLX 2.2 C#.
The DBLX 2.2 JDBC driver is compatible with DBLX 2.2 Java.
Versions of DBLX 2.x prior to 2.2 are compatible with the .dat and .edat table formats in DBLX 2.2.
DBLXClients from v.2.x will only work with DBLX 2.x (the same revision, which would be 2.0 or 2.1)
DBLX Application modes
DBLX can run in two modes, server and embedded.
Server mode requires that access to the DB be made from a client. Clients send queries to DBLX over the network using TCP-IP port 7169.
The DBLX server can be on any system that is addressable on the network. DBLXClient can be on the same system as the DBLX server, or on a completely different system or platform.
To send queries to DBLX server you have to use DBLXClient, and you have to start DBLX via the Main() method.
Embedded mode operates the database as if it was a private component in your application. To send queries to DBLX you just use one of the classes in the embedded namespace (C#) or package (Java).
The API for DBLX embedded mode allows use of the database through either standard SQL or through class objects that eliminate the need for SQL. You can use the one that you like the most.
DBLX server mode, and database connections
Please remember that those who created DBLX are programmers. We have to use database systems every day in our 'regular' jobs. DBLX was a way we could create a database without all the
baggage of the current database systems that make it difficult to use and/or deploy.
The first thing we did was to not use cursors.
[insert pause here for dba's to have a moment to crap themselves when they read this]
The reason was two-fold, but cursors put a lot more into the memory of the server, and this does not work well in low-memory or portable devices.
The other reason for not using cursors were the goddamn database connections.
In the Big 5 relational databases, the #2 most costly operation is a client attaining a connection to the database server. To mitigate this, there are a plethora of database connection pools that can open lots of connections and hand them out as application code attempts database queries.
Really? That Big Ass $20000 RDBMS can handle many Gigabytes of data with hundreds of concurrent users, and the #2 Pig in the poke is getting a connection?
We felt this was Nuckin' Futz and were not having it.
DBLX uses a single-lifecycle client-server message that returns the results to the client. When you issue a query, the entire query is sent as the request, and the output of the query comprises the response.
This pattern infers there is no measureable time penalty to making requests to the DBLX server compared to how requests work with cursors.
You will not need a connection pool with DBLX. There is no performance advantage to pre-connect clients to DBLX.