change schema owner from PUB to sysprogress (ODBC + Transact

Posted by Admin on 08-Jun-2010 15:21

Hello,

I have a problem running a DOS program from a provider.

This program should be able to READ and UPDATE fields on 1 table.

But this table is INSIDE a transaction, so, I have the following:

DO TRANSACTION:

      FIND FIRST tablename.

      OS-COMMAND "program.bat".

END.

When program.bat wants to UPDATE a record from tablename the following error raises:

Warning:  odbc_exec() [function.odbc-exec]:  SQL error: [DataDirect-Technologies][ODBC PROGRESS  driver][PROGRESS]Failure getting record lock on a record from table  PUB.tablename., SQL state S1000 in SQLExecDirect in program.bat  on line 11

Reading this: http://www.oehive.org/node/1025

I wonder how can I change the schema owner from PUB to sysprogress ????

Thanks!

W.

All Replies

Posted by kevin_saunders on 09-Jun-2010 03:19

There is no need to change the ownership from PUB - PUB is public.

The issue is the procedure that finds the record is creating a lock (a SHARE lock in this case) and when the ODBC program tries to update it, Progress is telling the ODBC that there is already a lock on the record and it cannot be updated.

Change the find tablename statement to include a NO-LOCK on the end:

FIND tablename NO-LOCK.

Posted by Admin on 09-Jun-2010 08:21

This will not work, because the code involves a CREATE (I simplified it before just to put it here).

It's like this:

DO TRANSACTION:

      FIND FIRST tablename.

     /*something*/

     CREATE tablename.

     ASSIGN

                   tablename.field1

                   tablename.field2.

     OS-COMMAND "program.bat".

END.

I tried with a RELEASE tablename or FIND FIRST tablename NO-LOCK before calling program.bat and it fails.

Thanks,

W.

Posted by Admin on 09-Jun-2010 08:29

I tried with a RELEASE tablename or FIND FIRST tablename NO-LOCK before calling program.bat and it fails.

 

The release statement won't release the lock because you're still in the transaction (it becomes a share lock effectively). The OS-COMMAND needs to be outside the transaction or create the record itself (INSERT SQL statement). The 4GL Client and the SQL client are two different clients, so maintaining record locks during running transactions is an intended functionality.

This thread is closed