Third cause of Automatic unlock/locked record loop

Panorama X Beta 10.2
1

I previously reported two circumstances that will result reliably in a loop between a client and the server, where the server log shows a repeating pair of log entries, an Automatic unlock entry followed by a locked record entry. This pair repeats until a force quit or other action disconnects the client from the server. I have now found a third way to cause this failure.

In this case, I have a form with one text editor linked to a DB field. I opened the database (Navigator) With a procedure, I opened the form, which contains one text editor. I then pressed the tab key. After a couple of seconds, a spinning beach ball appears and stays until force quit is executed.

The log shows this, from the moment I opened the database (which in turn opened an aux database, until interrupted:

05/14/2021 11:15:27 am Session 44 (MacBook Pro:Thomas Cooper) start of new session
05/14/2021 11:15:28 am Session 44 (MacBook Pro:Thomas Cooper) opened shared database: Navigator
05/14/2021 11:15:28 am Session 44 (MacBook Pro:Thomas Cooper) synchronized database: Navigator (ts:313-313 changed:0 deleted:0)
05/14/2021 11:15:31 am Session 44 (MacBook Pro:Thomas Cooper) opened shared database: Timekeepers
05/14/2021 11:15:32 am Session 44 (MacBook Pro:Thomas Cooper) synchronized database: Timekeepers (ts:102-102 changed:0 deleted:0)
05/14/2021 11:16:02 am Automatic unlock of record 1 in database: Navigator (original session gone)
05/14/2021 11:16:02 am Session 44 (MacBook Pro:Thomas Cooper) locked record 1 of database: Navigator
05/14/2021 11:16:02 am Automatic unlock of record 1 in database: Navigator (already locked by this user)
05/14/2021 11:16:02 am Session 44 (MacBook Pro:Thomas Cooper) locked record 1 of database: Navigator

In variation of these steps, I revised the procedure that opens the form but adding a changeobject, [texteditorname],“open” statement. This should look just like tabbing into the text editor, and it resulted in the same failure.

Then I change the text editor data to a variable, and no failure occurred. That would not make any call to the server, so I would not expect a failure.

2

I am surprised that there are no responses to this post. This is a very serious problem. I can reproduce it reliably. I wonder if anyone else has observed this. I wonder also, Jim, what comments you have. I can share my screen with you if you would like me to demonstrate for you how it happens.

3

I found that I can prevent the loop between client and server if I insert a lockrecord statement immediately after the openform statement. Then I can press tab and the first Text Editor is activated without a problem, and I can proceed to tab through the Text Editors in the form.

4

This seems like it might be related to this previously reported bug.

Also I haven’t yet fixed this problem, which could possibly be related.

5

That seems likely to me given the log messages are the same in these various situations. I am surprised that nobody has either confirmed that they can reproduce this issue or say that they cannot.