Nav bar move-next button skips records when connected to remote database

[Gerald_Dueck]

Hi,

I’ve created master-detail forms populated with data from a localhost instance of MySQL server. I’ve exported the data to a MySQL server on an AWS instance. The forms work correctly when being served from local host but problems arise when I change the database connection to the AWS server.

The problem is that when I click on the Next button of the master-form nav bar, the form is briefly populated with the data from record two, and then populated with data from record four. The next click goes to record five and then to record seven.

I would speculate that the reason for this is some interaction between the lag introduced by going to a non-local version of the data. I would note that this lag is not particular noticeable from the user’s point of view, but certainly long enough to create possible race conditions in the underlying mechanism.

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-CA (en_CA); UI: en-US
Calc: threaded

remote server: mysql Ver 15.1 Distrib 10.5.15-MariaDB for Linux (x86-64) using readline 5.1

[RobertG]

Any macros running in you *.odb-file?

[Gerald_Dueck]

@RobertG good call on the Macros.
I have two form designs using form-subform-subform patterns. Both exhibit different behaviour.

One of the form designs has a macro attached to the mouse-button-release event on a table within the first subform. This macro doesn’t get called during navigation.

The other form design has a macro attached to the after-record-change event of the first subform. This macro enables a button depending on information in the rowset of a table within the subform.

The two designs exhibit different behaviour when the nav-bar-next button is clicked. For the first design, if R is the current record, R+1 is briefly displayed, then R+2. For the second design, with the macro attached to after-record-change event, R+1 is briefly displayed, then R+3.

[RobertG]

I have seen the same behavior here on a database I created with internal HSQLDB. Works well under Linux, shows navigating problem under Windows. Sometimes it seems it couldn’t be stopped under Windows.
If macro does something with Form.Reload I would add WAIT(500) in next row. Might be you have to test a little bit. In the database I created I see sometimes WAIT(100) for 100ms or WAIT(500) for 500ms. It is some times ago I created and corrected this …

[Gerald_Dueck]

Having looked for a while, I can’t seem to find anything that I can tweak to make this problem go away. However, I have managed to find a workaround.
I’ve added my own prev and next buttons to each form that exhibits the problem. The next button, for example, executes a macro like this:
sub MoveNext(form)
row = form.row
rowCount = form.rowCount
if row < rowCount then
form.absolute(row + 1)
end if
end sub

[nicholas59]

Hello Gerald,

May I say something? Thanks. After having read your title, i was wandering if you could maybe reset the response of your mouse-device, this in terms of reaction to the click you made…

[robleyd]

@nicholas59 If you read the question carefully, the issue only arises with a remote database; thus mouse sensitivity settings would be a most unlikely solution.

[nicholas59]

Ok robley! I do not give a DAMN anymore!
bye!

[Gerald_Dueck]

@nicholas59
Thanks for the suggestion. I haven’t found a way to modify the mouse-click time in Windows, but I don’t believe two mouse down/up event pairs are being generated. However, I can report that when I quickly click, release and move the mouse away from the next-record button, the button appearance remains “down” until R+1 is loaded, at which point the subforms have also been updated and the appearance reverts to “up”. At this point, one would believe the entire navigation to be complete. Then, with no further visible change in the appearance of the button, another record is loaded.

[nicholas59]

Have a nice time Gerald. Thank you for your kindness.