Posted: Fri Jun 01, 2007 11:17 pm
Enrico
This could be a complicated issue for Antonio and the ADO rdd developers .. RDD is so engrained with the concept of indexes .. for me ( with your help ) .. I have been able to leverage my rdd knowledge in substituting the ADO methods and have almost finished my complete re-write of a very complicated and robust application in MS SQL.
I see where the current ADO rdd builds on indexes for relations .. to me .. going into this ADO project .. I have totally abandoned indexes and sharpened my SQL to to just query what I want and not ( never, never ) do a SELECT * from TABLE unless I have to do an APPEND addnew() and that cursor is a bit UGLY 25k worth of records with a complete field recorset.
For the most part .. ( day to day ) data entry is limited to editing existing records and adding or editing related records spun off with a seperate recordset SELECT * ( or fields ) from <relational table> where <condition> = <primary key> .. returns only a cursor with limited records and I might add with no INDEXES... very fast.
I have noticed a 'severe' limitation to the SQL part of the ( open ) connection string in that if you list fields to limit your query .. if you add more than 6 or 7 .. xHarbours ADO will lock up .. apparently there is a limit on the length of the charactor string you can pass ..
I have taken a fresh approach to ADO and have totally wiped indexes off my radar scope. Now .. with that said .. I think the FIND method could be wrapped up into seek .. however if you use .dbf and ADO in combination you are going to have a translation problem .. what perhaps could happen is leave traditional seek in the ADO rdd for those developers that can use those databases that support indexes .. but spin off a new command like SeekAdo ( cSQL ) that one could use the oRs:Find() wrapper.
Also needed is the <order by> clause in the USE command which I have found to have very little overhead in presenting a records fetch.. plus I think it helps if the <order by> is your primary key ..
Lots of potential here .. could open up the whole RDMS world to xBase !!
Rick Lipkin
This could be a complicated issue for Antonio and the ADO rdd developers .. RDD is so engrained with the concept of indexes .. for me ( with your help ) .. I have been able to leverage my rdd knowledge in substituting the ADO methods and have almost finished my complete re-write of a very complicated and robust application in MS SQL.
I see where the current ADO rdd builds on indexes for relations .. to me .. going into this ADO project .. I have totally abandoned indexes and sharpened my SQL to to just query what I want and not ( never, never ) do a SELECT * from TABLE unless I have to do an APPEND addnew() and that cursor is a bit UGLY 25k worth of records with a complete field recorset.
For the most part .. ( day to day ) data entry is limited to editing existing records and adding or editing related records spun off with a seperate recordset SELECT * ( or fields ) from <relational table> where <condition> = <primary key> .. returns only a cursor with limited records and I might add with no INDEXES... very fast.
I have noticed a 'severe' limitation to the SQL part of the ( open ) connection string in that if you list fields to limit your query .. if you add more than 6 or 7 .. xHarbours ADO will lock up .. apparently there is a limit on the length of the charactor string you can pass ..
I have taken a fresh approach to ADO and have totally wiped indexes off my radar scope. Now .. with that said .. I think the FIND method could be wrapped up into seek .. however if you use .dbf and ADO in combination you are going to have a translation problem .. what perhaps could happen is leave traditional seek in the ADO rdd for those developers that can use those databases that support indexes .. but spin off a new command like SeekAdo ( cSQL ) that one could use the oRs:Find() wrapper.
Also needed is the <order by> clause in the USE command which I have found to have very little overhead in presenting a records fetch.. plus I think it helps if the <order by> is your primary key ..
Lots of potential here .. could open up the whole RDMS world to xBase !!
Rick Lipkin