A few scripts occasionally end up on an old, unused layout..

[Steven Cappiello]

Hi everyone,

I have a weird problem.. occasionally, a user reports that they end up on an unintended layout. A few of the scripts that end these users up on this unintended layout are simple go to related records scripts pointing to other layouts.

Has anyone ever experienced anything like this??? any ideas what I should look into, think about, etc... ?

[Ender]

The Go to Related Records[] script step will not change to the destination layout if there are no related records. For this reason (and others) it's good to check for the presence of related records prior to the GTRR call. This is easily done like so:

If[isempty(relationship::recordID)]

#no related records

...

Else

Go to Related Records[relationship; layout: whatever layout]

...

End If

[Steven Cappiello]

Hi Ender,

Thanks for the tip!! But.., it's happened a few times when I'm sure there are related records. For example, when in list view, and want to go to a details page... the relationship is a self-join based on ID so it's relating to itself. though this is just one of the scripts it has happened with:

The go to details script is:

1. Commit Records (perform without dialog, but perform data

validation) (should I change it to skip data validation??)

I have step 1 in so that the user can't be editing the record in list view and then also in the form view

2. Go to Related Records (match current record) in a new window, new layout (all in the GoToRR step)

3. Adjust Window, resize to fit

4. run another script (Window-center)

When the error has happened, the script doesn't seem to get to #3 and #4.

One thing I noticed is that the weird, old layout it's ending up on is the very first layout in my layout order.

This problem rarely happens so it's hard to debug. I just hear from a user about once a day.. yeah, that happened again.. I ask how it happened and they say "i just clicked on the guy's name to go to his details.."

ALSO.. it's not reproduceable. Next time they try to click on the same person, it works. It has also happened with another script, which is on another layout.. which points to a different layout..

weird thing is.. the same error, caused by trying to run two different scripts on two different layouts, has the same effect...they both end up on the first layout in my layout order-- a layout that was in the file back since 2004..and is part of an unrelated table..

occasionally the user has told me that they see the error, this script cannot be performed because blah blah is not part of a related table..

Any more thoughts

thanks :

[Steven Cappiello]

should I be worried that this might be corruption? should I possibly delete THAT layout that it's ending up on ??

the layout is first in the layout order.. that's got to be meaningful to this problem .. i think??? ??

[LaRetta]

I've had the exact same problem. There were no obvious reasons. But I had a mix of versions; a few clients on 7.0v3, server 7 and clients on 8. I spent weeks trying to solve it and never could. It completely disappeared when I upgraded server to 8 and upgraded all 7 clients to 8 [color:green]and there were NO design changes during that time.

This phenomenon has been reported by others during that transsition process between 7 and 8. My personal belief is that this was the cause. I know of two other similar cases which also resolved on the upgrade. There have been maybe 4-5 posts here on Forums about it - jumping to Layout #1 at random. Do you have ANYONE still on 7 or is your server still on 7?

[color:green]Oh and yes - it was always layout #1 that it would end up on - never any other layout.

Edited October 14, 2007 by Guest
Added green

[Steven Cappiello]

Thanks LaRetta!

It's certainly reassuring to know that others have had the same problem. In my situation though, the original file was created in 7, but it's currently being hosted on Server 8 Advanced.. and, all of the clients are definitely 8.0v3 or higher...

so, I'm confused about how to proceed. The database is huge and heavily used.. I'm hoping I can make this problem disappear. Any ideas for what I might try ??

[Steven Cappiello]

Any idea for what I should search for to find those other posts??

[LaRetta]

I've tried searching for them. I don't believe they would help because the 3 that I know of (one was mine) all resolved with upgrade. Are you on the latest updaters? I wish I recall the specifics, sorry.

[Steven Cappiello]

I've tried searching as well, to no avail. Does anyone have any ideas for what I could try to alleviate this problem? Can I recreate Go-to-RR with more manual scripting that might circumvent it, for instance? Was the problem ALWAYS with the Go-to-related records script step???

My clients and server are all running updated versions of FileMaker 8.

[LaRetta]

There may be other reasons this can occur. Just a break in a GTRR script-step would leave you on the layout you are on - and not send you always to the first layout. It is the 'landing on layout 1' which indicates the unexpected behavior I (and others) were experiencing.

But I wonder if, since You are all on same version and most updated version, that we shouldn't go back and revisit your specific scripts. For instance:

"... when in list view, and want to go to a details page... the relationship is a self-join based on ID so it's relating to itself. "

In this case, you don't need a GTRR at all; a simple Go To Layout [ detail layout ] when cursor is on a specific record will work. The next time it happens, let us know the specific script steps, the RECORD involved and present your file (if possible). Otherwise, it might be very difficult to pin down. I know this type of break is maddening. I wish I could help more and I'll try to search again when I can.

[Vaughan]

Weird things can happen when a developer is modifying a layout in a system that's being used.

[LaRetta]

So, true, Vaughan.

But as with being always left on layout #1, I have never modified a layout in a system that is being served. I don't work in it at ALL. The behavior described happened to several people when mixing versions and it always dumped people on Layout #1 - always.

I didn't get the impression that modifications were being made when it happened here either.

[Steven Cappiello]

Modifications weren't being made when it has happened...

What's interesting is that it NEVER happens to me when I am logged in with full access privileges, so it leads me to believe it only happens to users that have less than Full Access.

[Ugo DI LUCA]

so it leads me to believe it only happens to users that have less than Full Access.

I think you catched it.

Edited October 18, 2007 by Guest

[LaRetta]

Interesting. How would you think different privilege sets would consistently drop Users on the first layout in layout order (layout 1?). It seems that if they didn't have privileges, it wouldn't fire at all, no? Just curious as to why you went that direction, Ugo? :wink2:

[Steven Cappiello]

what's frustrating is that the error will happen, and then, the user will repeat the exact same action and it won't happen...

it happens occasionally and infrequently.. and I think that some of the scripts run with full access privileges...

i was also wondering if it could be a situation whereby two buttons might be slightly overlapping and a user clicks on both at the same time...

but I don't think that's the case...

frustrated....

at this point, all I did was edited that first layout to say something along the lines of: "if you have ended up on this layout there has been a system problem, you should be able to close the window and proceed with your work..."

[LaRetta]

Alright. I told everyone that I've seen this before (I've watched this problem for awhile because I spent many months fighting it) and I'm convinced it was a bug between versions. I have NEVER modified the program while being served and it would (at random) break and drop Users (always) on Layout1 and I ALWAYS tested for related but it sometimes would do it with straight layout switch as well, and I never used Go To Layout [ by number ].

Below is a list of threads I pulled just from FM Forums - Cafe' had many as well. They have four things in common: 1) They all end up on Layout 1 no matter what, 2) The script-steps are all different, 3) everyone offers different solutions; none of which work and 4) the problems have disappeared, ie, there have been NO reports of this behavior from anyone since vs. 8.0v3.

Again ... I did NOT make a single design or script change during the period of time it was breaking and when it fixed itself when we upgraded all versions. Are you running on FMSA 8.0v4? Are you SURE all clients are on 8.0v3? Because in every instance, it was a mix of versions; or those on 8.0v1 when the problems appeared?

here and here and here by Genx and here

And don't patronize me, guys. I know how to test if there is a related record etc. For me, it fixed itself the day I ran updaters and moved those on vs. 7.0v3 and 8.0v1 to 8.0v2.

[Ugo DI LUCA]

Interesting. How would you think different privilege sets would consistently drop Users on the first layout in layout order (layout 1?). It seems that if they didn't have privileges, it wouldn't fire at all, no? Just curious as to why you went that direction, Ugo?

Because I cross this situation where a Go To Related Record on a calculated Layout Number in a new window couldn't be reached because of insufficient privileges. Set error capture in this case wasn't set to On, and the user was directed to the first layout in the Layout order.

Locally, the script stayed on the current layout, in a new window, when accessed remotely, the user ended on the first Layout number in a new window, as if the layout number calculation couln't be evaluated.

I got it corrected throuh access privileges.

Interrestingly, there was a different behaviour according to the method used to target the layout, and it seems FM9 corrected it

Up to FM8.5, if the layout targeted was set through the layout list, then user with insufficient privilege would end on that greyed Layout with the "no access" label. If it was calculated ( either by number or name ), the layout would not be evaluated and user would stay on the current Layout in a new window.

Edited October 19, 2007 by Guest

[LaRetta]

Thanks for explaining that. Using Layout number is never a good idea but I didn't realize it would also mis-direct a Go To Layout [ ] script-step. So there were as many reasons for the break in 'ending on Layout 1' as there were breaks. If Error Capture wasn't on, the script should continue as if the error wasn't thrown and proceed to the layout anyway. Yes, I haven't heard a single report of this in 8.5 or 9. I wish I understood what FM did to fix it.

Thank, Ugo! :wink2:

[Steven Cappiello]

Hi there,

unfortunately I may be the "single report".. I've confirmed we're running FMSA 8.0v4, and all my users are on at least 8.0v3. Those that have reported the problem have been using 8.5v1 on both Mac and PC.