Problem commiting change to server when closing file

Panorama X
1

I’m having problems committing changes to the server when closing a shared file without saving first.
I created two test databases, TestA and TestB. TestB is shared in the server.

Database TestA has a procedure with this code:

openfile "TestB"
FieldA=today()
closefile

If database TestA is not shared, I get this error: “Cannot commit to server. empty sessionID”

If I then upload TestA to the server and run the procedure, I get this different error: "Cannot commit to server. Cannot commit record: 1 in database: TestA (The record is not locked).

Adding a save statement before closefile fixes the problem, however this solution doesn’t work if the shared file is secret using setactivedatabase.

This doesn’t work, as the save statement changes the focus back to TestA:

setactivedatabase "TestB"
save
closefile

I can use openfile instead of setactivedatabase, but I wanted to report this unexpected behavior.

2

It shouldn’t be necessary, but try adding an unlockrecord statement in between the assignment and the closefile statement, like this:

openfile "TestB"
FieldA=today()
unlockrecord
closefile

I think that will make it work. Please let me know either way. If that does fix it, I should be able to change closefile so that it does the unlockrecord automatically.

3

Yes, unlockrecord worked. Thanks!

And closedatabase? Probably it uses closefile internally, but just making sure.

4

No, it doesn’t use the same code at all. It’s completely different because it closing a database other than the currently active database.

Thanks for bringing this to my attention – I think there is a bug here even for single user databases. I think the code below will fail even for single user databases.

openfile "TestB"
FieldA=today()
window "TestA"
closedatabase "TestB"

Actually, come to think of it, I think your closefile example would also fail for single user databases. The good news is I think I have determined the necessary fix, though I need to do some additional testing to make sure. The same code change should fix both single and multi user operation.

5

Great! Thank you!

6

I didn’t quite read your post carefully enough yesterday, and missed this key point. On further researching this, I realized that the save statement is required to make sure that the data gets saved locally. This also unlocks the record.

However, as you pointed out, when you use save with a “secret” database the window changes. There are two solutions to this:

opensecret "TestB"
setactivedatabase "TestB"
FieldA=today()
save
setactivedatabase "TestB"
closefile

Or:

opensecret "TestB"
setactivedatabase "TestB"
FieldA=today()
save
closedatabase "TestB"

I’ve tested both of these approaches and they appear to work correctly with the b29 release. The unlockrecord statement isn’t needed (the save statement unlocks automatically). I’ve changed closefile and closedatabase so that they also unlock automatically, but the save statement is still needed.

7

Thanks for confirming, I started using exactly this code after my original post to save locally, but I didn’t realize it unlocks the record, fixing the shared file situation as well. I will remove unlockrecord from shared files. Thanks!

8

To be clear, the unlockrecord statement doesn’t hurt anything. So you can leave it in or remove it at your convenience.

9

The following lines of code freezes or crashes Panorama around 3 out of 10 times. TestB is a shared database.

opensecret "TestB"
setactivedatabase "TestB"
... something here ...
save
closedatabase "TestB"

I’m wondering is this is related to the fix to unlock the record before closing the database.
If I remove the save, there is no crash.

The following also crashes:

opensecret "TestB"
setactivedatabase "TestB"
... something here ...
save
setactivedatabase "TestB"
closefile
10

Adding to the report above, sometimes there is no crash, the database closes locally, but it is still shown open in the server.

This is confirmed by monitoring the server in real time with the terminal and the Server Administration panel shows the database still active by the same user.