Antonio,

Are you showing some data from the window ?

try not to paint any data from the database on the window, so the RDD is only used once

Later on we will find a way to solve it,

Antonio,

I'm showing on a modal dialog with an array with several elements extracted from that table.
The error does not occours in the modal dialog but when I close the table just after the do while and before the moda dialog.

It seems crash occurs in ADO_CLOSE line with RETURN UR_SUPER_CLOSE( nWA )

Is it a GPF ?

Do you get any log file ?

Antonio,

Sorry I forgot to send it.

Assinatura do problema:
Nome do Evento de Problema: APPCRASH
Nome da aplicação: fllup.exe
Versão da aplicação: 10.0.0.0
Carimbo de Data/Hora da Aplicação: 5507d7fe
Nome do Módulo com Falhas: OLEAUT32.dll
Versão do Módulo com Falhas: 6.1.7601.17676
Carimbo de Data/Hora do Módulo com Falhas: 4e58702a
Código de excepção: c0000005
Desvio de Excepção: 00004974
Versão do SO: 6.1.7601.2.1.0.256.48
ID de Região: 2070
Informações Adicionais 1: ae2c
Informações Adicionais 2: ae2c80fe4dc0da3fe8c919694d2e67bb
Informações Adicionais 3: 61a9
Informações Adicionais 4: 61a9386778096c577ec0f18cdcd7098d

Antonio,

Please copy ADO_CLOSE source code here, thanks

Antonio,

Here it is.

Antonio,

We just found out that previous GPF occours with:

oRecorset:Open("SELECT * FROM "+ cTableName.... GPFs in any condition

oRecorset:Open(cTableName .....GPFs if oRecordSet:CursorLocation := adUseClient

Its ok if oRecordSet:CursorLocation := adUseServer

Any ideas why?

Antonio,

No idea why, but its great that you found a workaround so you can continue testing and working on it

Antonio,

There are some issues that we must workaround in order to have full compatibility between ADO and normal RDD with no changes in the code if at all possible.

These are the issues:

1) INDEX – In SQL these should be independent of the code itself. The programmer should only think about
the data he needs, the rest its up to DB admin.
By ordlistadd or createindex it would add to some array in the adordd the name of the indexes attached to
that workarea.
By ordsetfocus() the code simply asks for new recordset replacing the one in the same work area using
SELECT …. ORDER BY….
The ORDER BY is extracted and parsed from the original index expression in an array of all dbfs used in
the app in the form of:
{ {"TABLENAME",{"INDEXNAME","INDEXEXPRESSION"},{"INDEXNAME",”INDEXEXPRESSION"} }} if
called by ordlistaad.
If called by createindex the expression would be save in that array to the corresponding table name.
Thus it doesnt matter to the programmer if the indexes do not physically exists in the database.
The DB admin creates them enabling faster access for the app as the DB grows.
We already use this kind of approach in queries in ADS with goods results.
Using the SEEK we test if is supported otherwise FIND

2) RELATION – We must work with as many records sets as the relations and basically works the same as
indexes with an array for all the relations in the current work area.
If it has indexes FORCE REATION will use SEEK otherwise FIND and also verifies that the SQL expression
corresponds to the expected INDEX RELATION expression if it doesn’t rises an exception as other rdd child
not "indexed".

3) RECNO – Work with bookmarks if there isn’t any column AUTO INC named RECNO.
Of course bookmarks have some compatibility limitations but I think its not big issue at least for our
application.
If it becomes a problem we must alter structure of the table and add RECNO field AUTO INC.

4) LOCKS – we need to save all record locked like any other rdd to be used by dbrlocklist() that are either
Bookmarks or column RECNO.
In our case this is very important because in our transactions we lock and append all needed records and
when updating we go through an array of locked records returned by dbrlocklist() using dbgoto().
So it doenst matter so much the lock itself to prevent others from updating but the array of recnos locked.

5) CONCURRENT UPDATES – This is a big issue and the simplest and safe way its to treat everything as a
transaction and here we have to place in the code in every update BEGINS TRANS and COMMIT TRANS. I
think it’s the only way to prevent concurrent updates.
In the errorsys ABORT TRANS in case of an error.
Perhaps we could in the first LOCK issue BEGINS TRANS and COMMIT TRANS in the first UNLOCK.
The second LOCK checks if it is in a TRANSACTION (I dont know how to check it) if it doenst starts one.
On the other hand if one issues an unlock during a transaction because the fields information needed
didn’t checked right and did not proceed with it issuing a COMMIT TRANS after the unlock isn’t a problem
because there isn’t nothing to commit and the TRANSACTION is finished assuming that all info verification
is done before ny writing to the table.
With an open transaction concurrent updates will be in principle safe.
Databases not supporting transactions I really don’t have any alternative.

Doing this we could increase the level of abstraction to the database and it might function with any database no matter if supports or not INDEXES,RELATIONS, ROW LOCKS, whatever.
If it is too slow DB Admin creates the needed indexes and the adorrdd issuing the SELECTS speed will increase drastically.
I would forget CATALOGS and leave it to the DB Admin.

My questions are:
What are these arrays of information already in the adordd?

What is your opinion ? Do you think this is feasible ? Do you think it’s the better approach or do you have any other ideas?

By the way there are some FWAdo functions that I cant find anyware and could help doing the job.

Looking foward to all comments,

Antonio,

Check the functions for each task that you mention. There you will see where the indexes, etc. are placed:

i.e. in ADO_ORDCREATE()


You have to try and check it for yourself. I never tested a large app with Adordd.prg, not sure if Miguel did it (see the copyright of adordd.prg)

Antonio,

I need to alter function IndexKey() to work also with adordd.
How can I do it ?

Antonio,

IndexKey() se traduce en una llamada a OrdKey() y OrdKey() llama a ADO_ORDINFO()

https://github.com/harbour/core/blob/master/extras/rddado/adordd.prg

Antonio,

At ADO_ORDLSTADD how can I save the all open index info to workarea array to be used in ADO_ORDINFO?

Antonio,

Change this:

define WA_RECORDSET 1

define WA_BOF 2

define WA_EOF 3

define WA_CONNECTION 4

define WA_CATALOG 5

define WA_TABLENAME 6

define WA_ENGINE 7

define WA_SERVER 8

define WA_USERNAME 9

define WA_PASSWORD 10

define WA_QUERY 11

define WA_LOCATEFOR 12

define WA_SCOPEINFO 13

define WA_SQLSTRUCT 14

define WA_CONNOPEN 15

define WA_PENDINGREL 16

define WA_FOUND 17

define WA_INDEXES 18 <==== New !

define WA_SIZE 18 <==== Changed !

Antonio,

The aOrderInfo[ UR_ORI_TAG ] can be Numeric or String.

Is this behavior correct?