Mr James
After I read your question, I looked back at my posting. I have to agree that the language was not accurate.
I have a class TAdoBase derived from TDataBase.
Both have the same methods and behave identically ( almost ).
Now for ADO I need to use TAdoBase class and for DBFs TDataBase class.
But what I do is I have also a connection class ( and other classes )
The connection class is a wrapper for ADODB.Connection object with more methods used regularly.
I can also create dummy connection object for DBFs with the same connection class. This works both for ado and rdd for DBFs
I open tables with the connection object:
example: oCn:OpenTable( "tablename or sql" )
If the connection object is for a normal RDBMS ( oracle, mssql, etc ) the object creates recordset and uses TAdoBase to open the table.
If the connection object is for DBFs it uses TDataBase for Tables ( like CUSTOMER.DBF, etc ) and TADOBase for SqlStatements ( like "SELECT ." ). Note: This uses both RDD and also ADO for DBaseIII.
I need to think about the provider only at the outset, whether I am connecting to Oracle, SqlServer or simply a folder with DBF tables. Once I establish the connection I now forget about the source. Even forget if I am working with ADO or DBF.
In the rest of my application:
oCon:OpenTable( "SELECT NAME,ADDRESS,DUES FROM CUSTOMER" ) returns TAdoBase table ( both for DBFs and RDBMS )
oCon:OpenTable( "CUSTOMER" ) returns TDataBase for DBF and TAdoBase for RDBMS.
Usage of the table is the same whether it is DBF, ADO or whatever.
At the same time I should agree that I do conditional coding in the application but that is minimal.
Hope I am clear
Note: This approach works for me because I belong to the school of thought who believe in opening connection once at the beginning of the application and closing at the end and I am seriously against opening a separate connection for each recordset. (a) This approach increases the strain on the server resources and (b) opening a connection adds to the time of opening recordset (not totally relevant today).
We see present day programmers open recordset and connection together. These are the examples we see often.
Then they normally use detached recordsets. Open connection and recordset and then detatch it and close the connection. After handling the modifications at the client's end, re-connect to the server and update in batchmode and handle exceptions. This is good because the connections for each recordset do not remain open on the server. Reconnecting also does not take time, because present day application servers maintain connection pool in their Cache.
But the way we use ADO from Harbour code is different and we better do not hold more than one open connection per application.
