I decided to make the first "real" engine for working with a database through the OLE DB interface. The main (and almost the only) source that turned me on this path was the documentation from Microsoft, namely MSDN. Based on what I read there, I decided that this is the most progressive of all interfaces. It is he who is used by the modern ADO system as the lower level for communication with the database.

 

In order to keep the size of the application as small as possible, I decided to sacrifice a few things. Namely: parameters in SQL queries. In reality, the use of parameters is not strictly required, that is, you can do without them perfectly. Moreover, for some time now I have stopped using them altogether. The main reason why I didn't make friends with them is the inconvenience of debugging SQL queries containing such parameters. If the query has no parameters, and all values ​​are inserted as string values, then the query can be copied unchanged into the same Query Analyzer, and run for testing in offline mode (in the sense, separately from the application). For comparison, try doing the same with a query containing more than a dozen parameters.

 

Note: Several methods can be used to copy a query generated dynamically in the application code as a result of concatenating several (or many) strings. For example, just before executing a query, when it has already been formed, its text can be saved in a debug text file.

 

The KOLEDB package contains a sufficient minimum of tools needed to connect to the database server and get started with it (TDataSource objects, TSession objects). At this stage, the greatest difficulty is the formation of the connection string: each server needs its own string, with its own set of parameters. And even the syntax for different servers can vary significantly. But an application is usually developed for one type of server, so this difficulty has to be overcome only once.

 

The TSession object allows you to organize transactions, and is the "parent" of all created SQL TQuery objects.

 

The main workhorse of the package is TQuery. It allows you to execute SQL queries, get results, and can work with almost all major data types. To avoid the use of cumbersome and slow variant data types, the properties for accessing data fields are separated by type. For example, to refer to string fields, use the SField [idx] and SFieldByName ['name'] properties, for integer fields - IField and IFieldByName, and so on. This does not mean, however, that the value of a numeric field can only be accessed through a property whose name begins with the letter corresponding to its type. Access through the SField property is allowed: in this case, the field will be automatically converted to a string, if possible.

 

In practice, access to BLOB fields remained unimplemented for KOLEDB (of the really useful features). I think that when someone needs this module for serious work, then this programmer will not have too many problems to modify it to the desired functionality.