New build adordd ver 1.0 at https://github.com/AHFERREIRA/adordd.git
Changes:
1) Bug creating indexes was searching index name with = instead of == returning sometimes wrong name and expression.
This has been disrupted when coding UDFs in indexes.
2) New #ifef to compile with Harbour and xHarbour
STATIC FUNCTION ADOTEMPTABLE( DbEngine, oCon, cTable)
//LOCAL cMark := ""
TRY
oCon:Execute( "DROP TABLE " + cTable )
CATCH
//DO NOTHING IF DOE NOT EXIST
END
cMark := "TABLE "
....Antonio,
I have a big concern with the new update.
I program exensively using objects. In these objects I may open the same DBF in many methods--often just to look something up, then close it. I do this mainly so I don't have to worry about reusing an already open copy of a database. If I did use already open DBFs, then I would have to save the entire state of the database (recno(), index order, filter, relations, scope, etc.) at the start of the method and restore it at the end of each method. Often I open several DBFs in the same method.
So it seems that my code will not be compatible with the current ADORDD. If I understand it correctly, all databases are opened at the start, and the same copies of each must be used during the entire program. Is this true?
If so, then I will have to do very extensive recoding to use the ADORDD. Others may have the same issue.
Best Regards,
James
Gunther,
Thanks.
Done!
But in fact its not used.
James,
The fact of the tables defined in SET ADO THRESHOLD has nothing to do with the apps.
It internally used by adordd but for the user everything is the same.
You can do whatever you want in your app just like with any other rdd.
When I say opening the tables means to build the recordets and this takes some time.
So its better to wait a little in app initialization than to wait every time we open and close a table.
Besides that the memory usage is much more effective because adordd its not building 3 recordsets if you have the table opened 3 times.
Instead its cloning 3 times that initial built recordset.
This is much faster and takes less memory because clones are like a pointer to the recordset.
The main goal of adordd continue to be absolutely no code change in our apps!
adordd its more compatible with clipper code than ads rdd.
Resuming you dont need any re coding.
The best way for you to try is to do:
1) All sets in the top of your main check the 01_readme.pdf
2) At the top of your app, after all SETs place hb_AdoUpload( "c:\yourdatabasepathroot\, "your actual rdd", "for ex MYSQL", .F. // TO LET YOU RUN THIS AGAIN IF SOMETHING FAILS )
3)Attach adordd.prg to your project Compile and link.
You should be able to run your app agter the uplaod of all tables.
I ve ported last Monday a big app just like that.
1) Steps mentioned above
2) Overnight to upload all the tables to MYSQL
3) Its running and being tested and it seems everything its ok
Building the SET ADODBF INDEX might take longer because if app does not have already a central function to do it you will have to look at the code or build a small function to do it auto for you but then you must to run all routines.
In this app Ive ported was not the case as it had already a function to take care of all this so it was extremely fast.
Go forward.
RddRegister("ADORDD",1)
RddSetDefault("ADORDD")
IF RDDSETDEFAULT() == "ADORDD"
SET ADODBF TABLES INDEX LIST TO { ....... }
SET ADO TEMPORAY NAMES INDEX LIST TO {"TMP","TEMP"}
SET ADO INDEX UDFS TO {"IF","&","SUBSTR","==","DESCEND"} //at least these must be in and our Udfs
SET ADO DEFAULT RECNO FIELD TO "HBRECNO"
// SET ADO FIELDRECNO TABLES LIST TO {...}
SET ADO DEFAULT DELETED FIELD TO "HBDELETE"
//SET ADO FIELDDELETED TABLES LIST TO {.... }
SET ADO LOCK CONTROL SHAREPATH TO "******" RDD TO "DBFCDX"
SET ADO FORCE LOCK ON //might be off
SET ADO DEFAULT DATABASE TO "******" SERVER TO "*****" ENGINE TO "MYSQL" USER TO "****" PASSWORD TO "*****"
SET ADO TABLENAME WITH PATH ON
SET ADO CACHESIZE TO 50 ASYNC ON ASYNCNOWAIT ON
//MSGINFO("PRE OPEN")
SET ADO PRE OPEN THRESHOLD TO 3000
// MSGINFO("PRE OPEN END")
SET AUTOPEN OFF //can be on
//comment this line after first execution to be faster
//if you dot comment it every execution will check if all tables have been loaded and because lOverwrite is .F.
//do nothing
hb_AdoUpload( "c:\yourdatabasepathroot\, "your actual rdd", "for ex MYSQL", .F. )
ENDIFINDEX ON TESTADISC->REDATUM TO TMPGunther,
Any valid clipper expression must work. If not something is wrong with adordd.
ADODBF INDEX ... is only for indexes that are used by the app and are created only once.
All indexes created (normally temporary) during app run time should not be place there.
adordd will create them as any other rdd.
See my previous post to James regarding porting of apps to adordd.
The best way is to go straight forward with a real app.
You dont alter anything so it really easy to roll it back if you are not happy with it.
Do you have already a real app working with adordd ?
What engine you use?
Antonio, i use MSSQL. I have explored in the meantime the rdd. All is ok. And i found out, that indexes with ADODBF INDEX ... are in ordernumber < indexes created with INDEX ON... and both can used the same time. Indexes without UDF are really extreme in speed! Some indexes (fields) i will change to use this speed.
Thanks!
...that indexes with ADODBF INDEX ... are in ordernumber < indexes created with INDEX ON... and both can used the same time
Gunther,
Still I dont get it.
If you have autoopen on always the ADBODBF INDEX its added first to the order list when you open the table.
If INDEX ON is after it will be added after.
If autopen off index on will be added first if you not did explicitly set index to the index in ADODBF INDEX.
If you found other behavior this is not the standard clipper its a bug!
Antonio, for me the RDD works perfect!
A practice suggestion:
In ADOPREOPENTHRESHOLD() not only the size in records should work as a filter. Also a substring (or a array with substrings) of the tablename are interesting for filtering the DBs for pre-open! (ex. only "2015" -> DB2015 and Faw2015gt and Klima2015 and ......)
A practice suggestion:
In ADOPREOPENTHRESHOLD() not only the size in records should work as a filter. Also a substring (or a array with substrings) of the tablename are interesting for filtering the DBs for pre-open! (ex. only "2015" -> DB2015 and Faw2015gt and Klima2015 and ......)