This is the weirdest and most troublesome issue in my years of developing TaxiCab Manager.
A user is entering the driver shift takings into the Shifts table and has created a new record and is on the editing layout entering data. What happens is - at randomly different points of the data entry, the user suddenly notices that the record has changed to the first record in the file.
When brought to my attention a few weeks ago, I tried replicating the issue on my build version and could not - when talking to the user a few days later, he said it had cleared up and had not happened since.
Another depot who has the latest version installed two weeks ago said that she too, saw the issue for a few days, but that it had fixed itself.
Not all taxi depots use the same process of entering the driver shift takings - two of five depots recently upgraded from v11 to v12 are reporting this issue - the other three depots don't use this process. It has only been since upgrading from v11 to v12 that this problem has started, but since development is continous I may have done something since changing my master version from v11 to v12.
So I set up a TeamViewer session on three machines at one of the depots reporting the issue so I could see it for myself. About one in eight records showed the errant behaviour - but I was not able to detect one common cause. Sometimes five in a row would jump, then the next eight would be fine. Sometimes it would jump when tabbing out of or into any of the four portals on the layout, sometimes when clicking into a field, sometimes when clicking white space. It appears that from watching the three users that the incidence today was less than yesterday, but I have no stats to prove that and anyway, even if it only happens once, something is awry! The one depot who does not do this process often but did see the behaviour was using a different editing layout, so it is not layout based. It does only show up in the one table of a 134-table separated solution.
My first thought was a trigger on the layout which was failing in some gtrr manner. The problem layout has no triggers attached to it at all - there are two fields on the layout that have triggers on them - one shows a custom dialog, the other does a Refresh Window. I also created a new layout in case it was a corrupted element on the layout.
There are no hidden buttons which might be firing off a 'go to 1st record' step. The users performing this task do not have the status area enabled, so the mouse scroll wheel does not flip records. I examined every button on the layout to make sure it did what it was supposed to - but since the jump happens randomly (as far as I can tell) an inadvertant button click sounds highly unlikely. None of the buttons are in the tab order.
Today I downloaded a copy of their data files to my local machine and have been doing the same process for a few hours but it has still not happened to me. With the debugger on, there are no scripts hanging around unfinished while entering data, so its not an errant script.
One of the files of the six-file solution has an OnTimer script, but this is not accessed by all users and the three users I TeamViewed did not have that file listed in the Windows menu since they do not access it. BaseElements confirms there are no other OnTime scripts in the entire solution.
I am stumped. Obviously FileMaker does not randomly go the first record of the table for no reason.
Any suggestions will be most welcome.
Steve Silansky - aka Dubl