We have struggled with one file becoming corrupted on the server. On the client side we noticed an eternal syncing indication in the record number status bar. The problem was two fold. The first problem to solve was to determine the root cause, and the second problem was how to fix the server side file.
We finally discovered the root cause to be the dreaded ObjectAction “OBJECT”, “Open” statement. We thought we had removed all of these statements, but we missed one which was the cause of the freezing and corruption of the server side database. However, PanX client side crashes had never damaged the server side file. A few of the errors that we received are:
The only way that we found to fix the server side database was to remove and replace it on the server while at the server computer. We have given up trying to remove a file via a remote client. We only have success by deleting the bad server file while operating the server computer. Then we compress a good file and email it to the person operating the server. (Yes, we need to install a backup system to our server, but we have a good backup system on a developer client that works well for now.). No, we have not had success removing the file from the server by the person operating the server, and then uploading a file from a client. We have only had success by emailing a compressed file to the server and uploading the file at server computer.
I have also found that the objectaction/open statement causes a freeze if the object is a text editor tied to a field. In that case, the result is a loop where the server log reports a stream of two items, repeated over and over until a force quit stops the client:
04/09/2021
9:58:36 am
Session 195 (TGC M1 Mac Mini:Thomas Cooper) locked record 165 of database: Navigator
04/09/2021
9:58:36 am
Automatic unlock of record 165 in database: Navigator (already locked by this user)
I don’t think the objectaction/open statement is to be dreaded; it is still useful in standalone databases and where the text editor has a variable linked to it rather than a field.
This is the third set of actions that I have reported which will result in this kind of loop. (The refresh text list procedure used in a text editor object, the autounlock under some circumstances, and this one.)
I have NOT found that this corrupts the server file. Once the client is force-quit, the server functions normally, and the client re-opens normally.
I was an early beta tester and did very early replace the server when some confusing situations occurred that I was not able to solve any other way. But I have NOT experienced the problem that James is describing. Instead, we have removed the suspect file from the server using the detach and delete feature, then uploaded a new database from a client. [I am not seeing graphics; is that just me or is .png not a compatible file type?] This is relatively easy to do and it’s the nuclear option in my opinion.
Somehow I have missed this bug report, I will look into it. But assuming this is true, there is probably an easy workaround, just precede this statement with a lockrecord statement.
lockrecord
objectaction "Some Text Editor","open"
This should not be necessary, the objectaction statement should perform the lock itself (or actually the Text Editor should perform the lock in respons to the action). But if this isn’t working, explicitly locking the record ahead of time should take care of the issue. Once the record is locked, it won’t need to be locked again by the objectaction, which should work just as if it was a single user database at that point.
If one of you tries this, please let me know the results.