ADO RDD xHarbour

[AHF]

Pieter,

Thanks

[AHF]

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

[byte-one]

Antonio, cMark must defined as LOCAL!

Code: Select all

STATIC FUNCTION ADOTEMPTABLE( DbEngine, oCon, cTable)
 //LOCAL cMark := ""
  TRY
    oCon:Execute( "DROP TABLE " + cTable )
  CATCH
    //DO NOTHING IF DOE NOT EXIST
  END
  cMark := "TABLE "
 ....
 

A suggestion:
In ADOSHOWERROR() should also the database an the actual table displayed!

[James Bott]

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

[AHF]

Gunther,

Thanks.
Done!
But in fact its not used.

[AHF]

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.

[AHF]

James,

Its really very simple.
I port apps like this:

1) Add adordd.prg to the actual project.

2) Then code in at the initial proc or function :

Code: Select all

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. )

 ENDIF

3) Compile and re link. Only adordd.prg and the prg where you place this code get compiled.

4) To revert to your previous app just comment rddregister and reesetdefault and rebuild it.

You can test it immediately in a real app. Doesn't work ? You dont like the result ? go to step 4.

If you need in later stage to USE... WHERE clause you must include adordd.ch in your files and then all get compiled.

Hope this will help you to go a head.

[James Bott]

Antonio,

Thanks for your prompt, extensive, and encouraging responses. I will be reading and re-reading them, and I will test them as soon as I can.

Keep up the great work.

Regards,
James

[byte-one]

Antonio, a suggestion:
In ADOSHOWERROR() should also the database an the actual table displayed!

And a question:
Code like

Code: Select all

INDEX ON TESTADISC->REDATUM TO TMP

are functioning? Maybe this command can fill the SET ADODBF TABLES INDEX LIST TO...

[AHF]

Gunther,

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?

[byte-one]

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!

[AHF]

Gunther,

Im glad to know that it suites you.

...that indexes with ADODBF INDEX ... are in ordernumber < indexes created with INDEX ON... and both can used the same time

I dont understand what you mean.Is it a bug?

[byte-one]

Antonio, not a bug!
I have tested ADODBF INDEX ... and INDEX ON... at same time. The OrdList begins always with the indizes defined in ADODBF INDEX ... This is very important to know!

[AHF]

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!

[byte-one]

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 ......)