GTRR inconsistent behaviour

[mav]

Here's the set up . . .

Our database has multiple 'buttons' with various scripts attached to each, and there is only one script step in each - which is GTRR Showing only related records matching current record only. The related record and button is being displayed in a portal.

Here's the fault . . .

Click on the button and the user is taken to the first layout, and to the most recent record on the layout they had visited. No error given to the user about not being able to 'reach' the layout due to permissions - I have seen this one before.

Unfortunately, this is not a repeatable fault . . .

This can happen to any one of five users just once in a month, or even twice in a row for the same button, and then not for months - it has not happened to me personally, although I'm using FM Advanced 8.0v2 and I'm not navigating as much as the users are. All other users are Mac OS X 10.3.9 FM 8.0v2 networked from a Mac OS X 10.3.9 FMS 8.0v2.

The script step shows the correct layout, not as mentioned my others on these forums.

Any thoughts ?

[Søren Dyhr]

When such jiffy logic occures is usually down to mismatch in key types, one being text and the other being number.

--sd

[mav]

You've lost me, what do you mean by key types ?

[Vaughan]

Søren means that the field on one side of the realtionship is not the same typ as on the other -- usually one is text and the other is number.

The only other time I have seen similar weirdness happen is in FMP 6 when the relationship has a sort order defined, and the sort order includes a field that has been deleted.

If the file was used with FMP 8.0v1 or FMS 8.0v1 I'd also suggest indexes may be corrupted. This is reasy to fix -- turn off indexing, then turn it back on again.

[mav]

Thanks for point out what Soren means regarding the keys. All of my primary and forgeign keys are text.

As for the index being corrupt, the file did begin as a FMP 8.0v1 file. Are you suggesting turning indexes off and then on again for every key field ?

Do I need to do a search within each key field after turning the index back on to rebuild the index ?