ADO RDD xHarbour

[lucasdebeltran]

Antonio,

I guess, at ADO_LOCATE(), in aWAData[ WA_SCOPEINFO ][ UR_SI_CFOR ] for the find, all before -> should be ignored, with substr o sttoken.

Thank you.

[lucasdebeltran]

Also, to add at ADO_INFO:

Code: Select all  Expand view

    CASE uInfoType == DBI_ISREADONLY // LUCAS
         uReturn := .F.


 

Thank you.

[lucasdebeltran]

That info about readonly or not is in aWAData, but I don´t know it´s structure.

[AHF]

Lucas,

Antonio,

I guess, at ADO_LOCATE(), in aWAData[ WA_SCOPEINFO ][ UR_SI_CFOR ] for the find, all before -> should be ignored, with substr o sttoken.

Thank you.

The problem its not only this.
We need to know if expression has more than one field mentioned on it.
As I investigate and test :find only allows one mentioned field.

Thus LOCATE FOR field1 = "???" AND field1 = "whatever" its not :find valid so we must send it to filter instead.
Ill change ado_locate to overcome this.

DBI_ISREADONLY --> lIsReadOnly (READONLY)

See also: command USE. The return value is .T. (true) when a database file is open in READONLY mode in the current work area.

We'll have to check open mode and put it here.

Im finishing it. Ill post new version soon.

[lucasdebeltran]

Thank you.

Please, don´t forget about:

i) You have ANNOUNCE ADORDD twice on top of it.



ii) Also, at ADO_OPEN() you have to comment out:

/*
aOpenInfo[ UR_OI_NAME ] += ".dbf"

hb_adoSetTable( aOpenInfo[ UR_OI_NAME ] )
hb_adoSetEngine( "")
hb_adoSetServer( "")
hb_adoSetQuery( )
hb_adoSetUser( "")
hb_adoSetPassword( "" )
*/


iii) And:

// aWAData[ WA_TABLENAME ] := SUBSTR(CFILENOPATH(aWAData[ WA_TABLENAME ] ),1,LEN(CFILENOPATH(aWAData[ WA_TABLENAME ] ))-4)



iv) Browses requiere mandatory at ADO_OPEN() :

oRecordSet:CursorLocation := adUseClient //its slower but has avntages such always bookmaks
oRecordSet:LockType := adLockOptimistic

[Antonio Linares]

Antonio,

It may be a very good idea if you announce and publish your modified and greatly enhanced adordd.prg version
in the Harbour users group list and also in Harbour devel group list. This way surely you will get more feedback:

https://groups.google.com/forum/#!forum/harbour-users

https://groups.google.com/forum/#!forum/harbour-devel

Also in Facebook in:
https://www.facebook.com/groups/harbour.project/

[AHF]

Ok Ill do that.

[AHF]

Antonio, Lucas,

:find wiht more than one field diferent or the same mentioned on the expression its not possible in ADO.

Thus Im going to filter .
Then calling continue will skip through the filter set.

Is this ok for the general use?

[lucasdebeltran]

Yes, that´s the only possible way in ADO.

Also, please don´t forget to open indexes automatically.

Antonio L., I think we might wait some days, as adordd.prg need some extra testing.

But, indeed, it´s going to be superb.

[AHF]

Lucas,

Yes, that´s the only possible way in ADO.

Also, please don´t forget to open indexes automatically.

Antonio L., I think we might wait some days, as adordd.prg need some extra testing.

But, indeed, it´s going to be superb.

What do you mean open indexes automatically?
Thats not in the scope of adordd thats to the application itself isnt it?

Now its working with :filter but thats temporay the final goal its to work with selects. Much more rapid.

Adordd needs much more working and testing.

Please remember that relations arent working, record movement in many situatons can still faill (eofs not tested)

A complete sqlparser for filter expressions although fortunatly we have one already workng many years in this app with ADS but must be adapted.
Creating temporay tables.
Replaces arent yet 100% ok for certain field types.
Memos I didnt even tried.

Im working on relations now.

[lucasdebeltran]

Hello,

In DBFCDX, there is not need to call SET INDEX TO..., indexes are opened automatically. Just:

Code: Select all  Expand view

 USE ( cMyPath + "CUSTOMER.DBF" )           NEW  ALIAS "CUST"
   CUST->(OrdSetFocus("CUST1"))

 

Nothing more.

I don´t use relations, and I guess there are not used very often.

I tested basic operations already and they seem to work fine. But the true way to test it is with a complete application, which is going to be my next step.

Also, I suggest you to use ACCESS, instead of ADS. Using Access will arrise the pending issues to be solved. Once ADO Works with Access, it Works with every RBDMS, just changing the connection string.

For correct field managment, please review ADOCreateColSQL().

For deleting, FWAdoDelRecord().

For dates, FW_DateToSQL().

For filtering, FW_Filter2Where().

Thank you.

[AHF]

New version adordd https://github.com/AHFERREIRA/adordd.git

Relations working. (I hope)

I think we can even relate tables in 2 different connections ex one MySql another Oracle. Didnt tried yet.

Find works.
If only one field mentioned in the expression calls Find if not Filter
When CONTINUE is called and when is filter skip +1

Seeks working.
Please remember that seeks are truly selects. Thus after a seek the "table" select is left only with the seek results.
If we do another seek or a while seek expression true there isnt any problem however if we try to go to a record saved before the seek will get error.

There is a new aWAData[WA_ISITSUBSET] to control this but I didnt yet find how to know if the default set is needed. For a ex a goto out of the set?
This seems to be a huge problem.

Antonio do you have any idea over the seek problem?

[AHF]

Lucas,

Hello,

In DBFCDX, there is not need to call SET INDEX TO..., indexes are opened automatically. Just:

Code: Select all  Expand view

 USE ( cMyPath + "CUSTOMER.DBF" )           NEW  ALIAS "CUST"
   CUST->(OrdSetFocus("CUST1"))

 

Nothing more.

I didn't understand that you meant auto open structural indexes.
You are absolutely right we have to take care of that in adordd.

If you don’t use relations what do you use for ex. to display fields of different "related" workareas?

Thanks for your valuable information

[Antonio Linares]

Antonio,

Antonio do you have any idea over the seek problem?

Could you provide a example to reproduce it ?

I am not sure which problem you refer to.

[lucasdebeltran]

Antonio,

In DBFCDX indexes are created like this way:

Code: Select all  Expand view

     
         INDEX ON FIELD->NOMBRE                TAG CLIENTES1   FOR !Deleted()
         INDEX ON FIELD->CODIGO                TAG CLIENTES2   FOR !Deleted()
         INDEX ON FIELD->NIF                   TAG CLIENTES3   FOR !Deleted()
         DbCloseAll()


 

Once they are created, when opening the dbf there is no need to open indexes with SET INDEX TO, they are opened automatically with the USE command:

STRUCTURAL BAGs
A structural index is no more than a BAG whose particularity have the same name as the table.

What we gain from this? Is that opening the table to which it is associated, also opens automatically
command economy. It is usually created automatically with:

USE MyDatabase New
INDEX ON TAG TO FILE NAME = TABLE´S NAME
....


Also:


SET AUTOPEN
Toggles automatic opening of a structural index file.
Syntax
SET AUTOPEN ON | off | (<lOnOff>)

Arguments
ON | off | (<lOnOff>)
The option toggles if a structural index file is automatically opened with the USE command. With ON or .T. (true), an index file is automatically opened. OFF or .F. (false) switch this mode off. Description
Some replaceable database drivers support automatic opening of index files with the USE command when the index file has the same file name as the database file (without extension). An example is the DBFCDX driver. SET AUTOPEN toggles this behavior.
When SET AUTOPEN is set to ON, which is the default, the USE command automatically opens an index file having the same name as the database file and the file extension returned from OrdBagExt().
Note: if an index file is automatically opened, a controlling index is not activated. The default index order is zero, i.e. records are accessible in physical order in the work area. To select a controlling index, call OrdSetFocus() or use SET AUTORDER for a default controlling index.
Info