Hi James, I have seen this error message also and I have had a recurring problem for months (I was a very early beta tester of 10.2). Unfortunately, I don’t know the precise answer to what occurred, but I have a hypothesis for what is happening and how to fix it, which I will share in the hopes that others may be able to contribute to the discussion.
The fact that this worked fine in single user mode is strong evidence that the client/server operation is implicated. The error message reflects a server issue. Committing a record, I think, refers to modifying a record already on the server.
I can quite reliably reproduce the error you have reported by making one change to your code: I added an assignment after the addrecord before the save statement.
First, I suggest you remove the Save statement and see if it works. From our classes you will recall that the server is automatically saving changes. First to the journal and then to the hard drive after a user controlled time delay. So the Save statement here theoretically is unnecessary.
Here is the code that failed when I tried it, starting from my database called Navigator:
alertsheet Dutch+" TimeStamp is "+info("serverrecordts")+" ID is "+info("serverrecordid")
alertsheet Dutch+" TimeStamp is "+info("serverrecordts")
I get the same error message you reported. Initially, I see a new record on my client database with the assignment there (Bonjour appears in the Dutch field; I know its French, but the Dutch use a lot of foreign words.). When I synchronize the database, the Dutch field changes to empty. So now there is a new record, but it is empty and the alert never appears. Seems like the procedure has been interrupted by the error.
I am quite sure now that this error is occurring frequently at my client’s office where people are using PanX 10.2 with several shared databases. Quite often I find that empty records have appeared without explanation (until now).
If I remove the Save statement from my procedure, I do not receive the Cannot Commit error message and I do get the alert with ID 11768, TS 986. This matches the data that appears in the instrumentation log. If I now synchronize the client, the data is present. In other words, the procedure works properly with the Save statement removed.
I conclude from this data that the save statement is causing the problem in this context.
In the first case, with Save statement included, instrumentation log has this block (which is different when the save statement is removed):
CLIENT COMMIT RECORD ==================================================
[CLIENTCOMMITRECORD] rid: 2
[CLIENTCOMMITRECORD] hostDatabaseName: DutchVocabulary on hostServer: TGC PanX Server
[CLIENTCOMMITRECORD] Request commit. rid: 2, sessionID: 7
[CLIENTCOMMITRECORD] === DICTIONARY xreply ============
[CLIENTCOMMITRECORD] INFO=“Cannot commit - record is not locked.”
[CLIENTCOMMITRECORD] === END OF DICTIONARY xreply ============
[CLIENTCOMMITRECORD] Commit failed: Cannot commit - record is not locked.
So what is happening? My hypothesis is that the problem is related to the run loop. When a record is added in a shared database, there are communications back and forth between the client and the server. When the client code encounters a save statement, the run loop is implicated. (I think this will be a topic in a future class.) See
Display-updates and save-actions cause another branch of code to be run outside of the main procedure code. This could be interfering with the back and forth communications that must occur in order to add a record to the server. That is, the server expects a response from the client but does not get it because the client is busy with a save operation.
The problem may be cured by adding a wait 0 statement immediately before the save statement. I think, but am not sure, that this will cause the prior code to complete its execution before the save operation begins. This strategy is discussed in the Run Loop pages. When I tried this, I got the alert I expected with TS of 1005 and ID of 11770. Now when I synchronize the data, the record is retained and no error message appears. The log shows that the original TS was 1004; after the assignment, the TS has updated to 1005, as expected. And the Commit record log block ends with “Commit finished.” and no error.
So the addition of a Wait 0 statement before the save statement cured the problem.
James, I am so glad that you reported this issue and I think I have a better understanding now and know that I am not crazy, having seen the problem numerous times.