Hi,
as specified in docs, table variable t<tablename> is extern (global) variable and is shared as a pointer to all dll-s that are used inside process.
I would like to make a cursor - in - cursor function in 2 separated dll-s on the same table as follows:
dll1:

table tppmmmxxx
select *
from ppmmmxxx
where ppmmmxxx.type = 10
selectdo
if (dll2.process(ppmmmxxx.orno, ppmmmxxx.pono) = tcyesno.yes) then
dal.change.object("ppmmmxxx")
...
dal.change.object("ppmmmxxx")
endif
endselect


dll2(note same table update!):

table tppmmmxxx
select *
from ppmmmxxx
where ppmmmxxx.type = 20
selectdo
dal.change.object("ppmmmxxx")
...
dal.change.object("ppmmmxxx")
endif
return(tcyesno.yes)
endselect
return(tcyesno.no)

Is there any way that these 2 extern declaration of the same table would not share same pointer to data structure? Idea is to have updateable table cursor inside dll. Thanks.

Hi,

Is there any specific reason for using dal.* functions across the DLL's? Also, you can use dynamic sql instead of normal selections.

actually it is use exit issue. I don't know which table(s) are used inside parent dll. Child dll (user exit) does some work in the same table that is also defined in main user script. Because of that, cursor on master table is "messed". Is there any option to have totally isolated cursors(table variables that not interfere with any existing pointer and that is fully "updateable")? in my case, I would define sort of "alias" in a way {dll.name}.{tablename}. Is there any hidden functionality to define have 2 or more updateable instances of the same table that does not interfere to eachother?
if not, is there any functionality in 3GL similar to db.store.record()/db.restore.record() (this one is only 4GL)?

if not, is there any functionality in 3GL similar to db.store.record()/db.restore.record() (this one is only 4GL)?

This function can be used in all script types.

Do you know for sure which of the table update occurs first? or they can occur in random sequence.

In either of the case, its better to commit.transaction before the other update on the table can start. If not using in a case like this, the cursors would surely get messed up. And it does gets.