Are both the Inventory List and product details layouts based on the same table occurrence? (Do you see the same name selected in "show records from" in layout setup for both layouts?)
Yes, they are. Both show records from "Inventory".
So you use QuickFind to pull up a list of records as your found set.
You click a button with "go to layout" to switch to a layout based on the same table but set up as a "detail view". Instead of getting the record for the one you clicked/tapped, you get the first record of the found set.
There are two common causes for that issue:
1) Your script doesn't have a single go to layout script step and some other part of your script is changing the focus to a different record before the go to layout.
2) A script trigger is being tripped by the go to layout scirpt step. This triggered script is then interfering with your results.
Well when I find something the first record in the list is highlighted but I have absolutely no idea why this is the case. As to the two common causes I can't see how any of them are applicable to my case.
Well when I find something the first record in the list is highlighted
If you mean that the first record in your list of found records is highlighted immediately after you perform the quick find, this would appear to be normal and expected behavior. But that doesn't seem to be what you were originally describing--that clicking a button that changes layouts was not showing the correct record on the second layout.
Does your button only use go to layout to change layouts?
Are there any script triggers set up on either layout? (go to layout can trip a great many different triggers depending on where the focus is at the time it is performed.)
Yes, it only uses go to layout to change layouts. No script triggers are set up that will affect it (because this issue is relatively new. It appeared only after a period of use of this database. No changes were made to scripting that would affect this)
It appeared only after a period of use of this database.
To rule out some "buggy" behavior with OS devices and FM GO being a factor, try this test: Double click the home button. Find the screen for FM GO and "flick" it upwards to close the FM GO App. Then return to FM GO, open the database file and test to see if you get the same results.
This is a bit of a long shot, but try using FileMaker Pro to recover your database file, then test the recovered copy (even if recover reports not finding any problems) to see if it has this issue.
Finally, if the above trials have no effect, open your DB in FM GO, create a brand new layout for your detail layout. Do not copy and paste any layout objects from the current detail layout. (You can keep the layout very simple for this test, put just enough on it to see which record is which when you select one.) Then update your button to go to this layout instead of the original layout. If the new layout works for you when the original does not, there are two possible reasons: There really is a script trigger on the detail view layout that is interfering or the layout is corrupted.
An older file does not have this problem. I guess the database is corrupted. Is there anything that I can do to rectify this?
try using FileMaker Pro to recover your database file, then test the recovered copy (even if recover reports not finding any problems) to see if it has this issue.
Take a clone of the older back up and import the records from your current file into it.
Or you can try removing the layout and replacing it with a brand new layout that does not contain any objects copy/pasted from the problem layout. (But the issue could be with either layout...)
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).