Converting DBFCDX to SQL (ADO)

[James Bott]

Rao,

For my personal development, I use a class derived from TDatabase, which handles both DBFs and RecordSets.
Methods and behaviour are identical.

Do you mean you are using the same class for both? I am having a hard time picturing this. Do you use IF/ELSE in every method? If so, why?

James

[nageswaragunupudi]

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.

[Enrico Maria Giordano]

it is far far more easier to handle DBFs than ADO particularly in multiuser environments.

I agree! DBFs are easier and most powerful. But the market pushes for the archaic SQL technology...

EMG

[lucasdebeltran]

Mr. Nages,

Do you sell TAdoBase or do you plan to incorpórate to FWH?.

Could you please provide more information about it?. It seems very very interesting.

Thank you.

[nageswaragunupudi]

it is far far more easier to handle DBFs than ADO particularly in multiuser environments.

I agree! DBFs are easier and most powerful. But the market pushes for the archaic SQL technology...

EMG

I agree with you totally, including the adjective "archaic".

But when tables are really *huge* with lots of concurrent users working round the clock, we are left with no choices. For medium sized databases ADS is still the best providing us the best of both the worlds.

[dutch]

Dear Mr.Rao,

I do agree with Lucus, it's really interesting.

Regards,
Dutch

Mr. Nages,

Do you sell TAdoBase or do you plan to incorpórate to FWH?.

Could you please provide more information about it?. It seems very very interesting.

Thank you.

[elvira]

Hello,

I am interested too. It would be great to have a TDBF class for ADO or, at least MySQL.

X ailer has those feature included, so with same class and methods they handle whatever database engine.

Thanks a lot!