I did a search and found SQL Anywhere doc that said that once a transaction is committed or rolled back, it is deleted from the transaction log.

Somehow the app is not committing the changes, they are getting rolled back instead.

Your app is probably AutoCommit=False and a COMMIT isn't being issued after the updates are made. Then on exit the app is issuing a ROLLBACK automatically.

The proper thing to do is keep AutoCommit=True until just before updating. Change it to False and then issue the updates with error checking/rollback. Then when the last update is done, do a COMMIT and switch back to AutoCommit=True. This way if the Save button does an update on multiple DataWindow/DataStore objects and one fails, the rollback will rollback all the changes within the 'unit of work'.

When you translate the log, are you including rolled back transactions? What about trigger-generated transactions? (by default neither are included)

John,

It must be that SQLCA.AutoCommit is set to False before making the connection to the database. If the user starts making operations to the database and an error ocurrs that chrashes the application everything will get rolled back. That'll explain why he could print the invoice but no invoice is found in the database.

If the user properly closes the application a Commit will be issued before the SQLCA object is destroyed and all data will be saved even if the code does not sets AutoCommit = True.

I experienced this when I started developing applications using PB. Now I always start a connection with AutoCommit = True and set it to False before making updates to the database. After issuing a Commit Using SQLCA I will set it to True again.

Regards,

Ricardo

Hi John;

  Normally if the UpdateBlob command works once for this App's business transaction - then it should work 100% all the time. The only two things that I can think of that might interrupt this blob processing are:

1) The UpdateBlob command is failed by the DBMS and the PB App fails to check the SQLCA status to catch the error. Yet the DB Commit continues and commits all datum but the blob.

2) Since you are using ODBC, and the blob data is variable - it might be possible that the "PBMaxBlobSize" and/or "PBMaxTextSize" are not set to the proper largest size setting in either the SQLCA.DBParm or via the PBODBC170.INI file. Thus, the Blob processing is curtailed the odd time if the blob exceeds a max setting.

HTH

Regards ... Chris

Roland,

thank you, but can the wrong use of this autocommit lead to "blank" sybase sql logfiles ? Its not one record he's missing, he's missing everything from a few hours of work. Yet he can show me a PDF of an invoice for example he created , nowhere to be found in our database , nor in our translated sql log file...:(

TIA

John

The UPDATELOB statement acts as if AutoCommit = True, even if it is set to False. My personal preference is to have AutoCommit = True and then set it to False prior to performing an update. I then switch it back to True after the updates are done. If an error happens on the second update, both can be rolled back. This method supports the Unit Of Work design pattern.

My guess is the user forgot to click the save button.

Hanlon's Razor:

"Never attribute to malice that which is adequately explained by stupidity."