'record is in use by another user' preventing updating a table

[205xld]

Help! Got a very strange problem.
I have form with a Optimistic Table Buffered table 'Purch' in the data environment.
I am the sole user of this app - it's running against a test database.
I add a record to the table using the form, and run tableupdate(.T.,.T.,'purch') in a transaction to save the buffered changes to the DB.
I then try to edit the record using the form, and when I try to update a form control which has its controlsource set to a field in Purch, I get the 'record is in use by another user' error message.
If I suspend and go into the debugger, Getfldstate(-1,'purch') shows all fields having a status of 1 (unchanged).
Txnlevel() returns 0 (i.e. the transaction is definately completed)
If I browse the Purch table in the current datasession and edit a field then something changes so the code can resume, but if I try instead to programmatically make the same change using the command window ("REPLACE field1 WITH 99 IN purch") the error stays the same.
Does anyone have any idea what's going on here please?

 

[TamarGranor]

Are you checking the return value of TableUpdate()? Is it working?

Tamar

 

[205xld]

Thanks for the response Tamar - I've been away so I only just got it.

Yes, I'm checking the return on TableUpdate() and it's fine. Have you come across similar behaviour before?

 

[Olaf Doschke]

You're working on different levels here. Using manual Transactions and Tableupdate(). What's your full code to update the changes into the table?

What you describe would be like this:

Set Multilocks On
Use Purch In 0
CursorSetprop("Buffering",5,"purch")

REPLACE field1 WITH 99 IN purch

Begin Transaction
? TableUpdate(.T.,.T.,'purch')
End Transaction

Or do you start/end your transaction at another stage? A transacation should be as short as possible, even if you work on the data as a single exclusive user only. It's not needed in this case, as TableUpdate() will care for the needed locks in the purch table in itself, but it can be usefull if you make several Tableupdates on related tables and need to Rollback if at some stage an error occurs.

If you begin the transaction after using the table that's your error, as you misuse transactions then for locking/buffering. You should then instead use pessimistic buffering, if that is your goal.

Bye, Olaf.