Go To Layout Step Problem

[Matt Haughton]

Hi,

A rare but potentially dangerous problem with the Go To Layout script step, just wondering if anyone else has come across this.

The Go To Layout script step has been known on occasion to go to the first layout in the file. The layout is explicitly selected in the step so its not some calc problem.

The step works fine in testing and on a day-to-day basis. The first layout in the file has ID 401 (which is not the lowest ID in the file) so it's deciding on first layout by layout order (rather than by ID).

This is happening in a windows environment (ignore the platform on my profile), on files served on FMS7 on Windows server, and happens to users using FM7 and FM8.

The problem is not localised to 1 script, it seems to happen more often when a developer is editing layouts in that file (creating, duplicating, re-ordering). It should be noted that live layouts never have their order amended while there are users on the system. All live layouts are at the top of the layout order and no new layouts are moved up while users are using the system.

Yet still occasionally a script goes and sits in the first layout of the file.

Could anyone shed some light on the inner workings of the Go To Layout step and maybe why this behaviour is occurring, would upgrading to FM8 server help?

Also take heed, if you have many users using hundreds of scripts across hundreds of layouts and you start editing the order of those layouts or create or duplicate layouts, you may find some users ending up in the first layout unexpectedly.

[Genx]

I used to have this problem with one file, but i scrapped it ages ago. You might have a corrupt file, but what i suggest you do is try and spot the scripts that send you to the wrong layout - delete the goto layout step, and re-enter it.

[Matt Haughton]

Thanks for the response but there are a couple of problems with that solution.

1. There doesn't seem to be any pattern to how or when this occurs (except it seems to increase when a developer is editing layouts). I have quizzed the users as to what parts of which processes they were using at the time, and can't see it occuring in specific scripts.

2. The scripts work for the majority of the time, they are used all day every day its only occasionally they go wrong. So if there is corruption it only rears itself in very specific circumstances and is well behaved for the rest of the time.

Just wondering if upgrading the servers or the users to a newer FM version would fix the given problem?

I'm not sure replacing all of the Go To Layout script steps would actually solve the problem, at present the problem isn't dangerous enough to spend days implementing this course of action with the risk that it wouldn't solve the problem.

Any other insights, or word on whether a later version of FM fixes the problem would be much appreciated.

[Lee Smith]

This question should probably have been asked in one of the Server Topic Areas. Specifically, the one that matches how the files are being served.

However, you should not be working on files while they are being served, it can cause corruption.

Lee

[Matt Haughton]

Lee

That's a very interesting comment and something i'd like more information on. I've always worked on files while they are served, being able to amend scripts in live files is something that's been present long before I met FileMaker and its one of FileMaker's huge advantages why would this cause corruption?

Are you saying any schema changes, script changes, value list changes and layout changes require the file to be taken off the server?

Note - I'm not working on the file from the server, I am connecting from a client machine via the server software.

[Ted S]

Lee, you said:

However, you should not be working on files while they are being served, it can cause corruption.

Really? I've been working on live files for many years. No corruption. Where does it say that this can cause corruption?

Edited July 24, 2006 by Guest

[Ted S]

Matt,

I noticed fairly recently that changing the order in which the layouts appear on the list actually changes their layout number. The layout number is returned by the function: Get(LayoutNumber). I had mistakenly assumed that the layout number was an internal number that was permenantly assigned to the layout and remained until the layout was deleted. It's not that way.

My thought was that it would be better to use this number rather than the layout name because I sometimes change the layout name and I didn't want the scripts to break. I think I went at this exactly backwards but since I change neither the order nor the names very often I didn't notice any problems.

I'm now navigating by layout name instead. Is this possibly your problem too?

[LaRetta]

I've been reviewing the issue of working in definitions on served files and I don't have answers either. But here is my opinion:

Much depends upon the TYPE of work being performed and working in definitions (or graph) alone doesn't cause corruption but ... if a Client box is performing definition or structural changes and their system locks up, then it CAN trash your served file (and you may not even know it) - just like you may not know it's damaged if you have a regular crash of served files. This is a distinction I have been unwilling to risk in most instances. Here is one such reference: Making changes from a guest can ruin your database. PARTICULARLY read the article referenced at the bottom of that post. I have read other such references but this is the quickest to point towards.

Is it likely? Is it true? I don't care. I won't risk it except for very simple changes. If I have backed up and there are no Users then yes I might risk it but if I lock up during the process (or lose a connection), I'll trash my work and grab a good backup. I will add this point ... it is now known that 7 had problems with remote development but I could find NOTHING in TechInfo mentioning it during 7's reign. How safe do I feel with vs. 8 just because there is no TechInfo saying it isn't safe? Nada squat ...

LaRetta :wink2:

[LaRetta]

Oh ... about it jumping to Layout #1 ... I had that happen (unpredictably over a dozen times during a four-week period) when we were splitting vs. 7.0v3 and 8.0v1. Nothing had changed in those scripts during that time! I finally moved my Main Menu to position #1 for safety - at least Users would end up in a safe place.

This unexpected behavior has stopped now that we are all using 8.0v2 (soon to upgrade to 8.0v3) and those nav scripts are exactly the same as they were. But I could not rule out the interaction with SecureFM (which handled much of my script triggers based upon layouts and so on) because SecureFM (for 7) added another dimension of complexity (we also upgraded our SecureFM to 8) so it was impossible to pinpoint. But the behavior was very strange indeed and it went away on its OWN!!

[Ted S]

As Paul Harvey says; "And now for the rest of the story."

Check our answer ID 6095 in the FM KB. It would seem to indicate that schema changes are indeed an okay thing to do.

I understand that there is a risk. But there is a reward too. Often the riskier something is the bigger the reward is. This holds true in many aspects of life. Take investing for example; if you put your money into rock solid safe financial instruments, you can plan on having minimal returns. Take a bigger chance, you will probably get a bigger ROI.

Another not so obvious example is vehicular travel. Riding is a car is quite dangerous when you think about it. Thousands of people die in automobile accidents in the US every year and I would guess that hundreds of thousands are injured. This really is a big risk. Why would anyone take it? Well, it's because there is a huge reward. Just think how different your life would be if you made a personal decision to not ride in automobiles anymore. Of course you'd be safe...

With Filemaker I'm generally willing to take the risk. I make reasonable changes. I'll add a field, change a script, move some stuff around on a layout, etc. I do not do big wholesale changes because the risk is too great for me. I also try not to do much experimenting on the live system because that seems like its inviting trouble.

People are different. There is probably no right answer.

[LaRetta]

Nicely explained, Ted. I'm a bit overly-sensitive about my files because I've had three major crashes in a four-day period (unrelated - it was running XP and Server 7). And it was VERY painful. I'm also a fuddie-duddie (sp?)and overly-protective. But you've reminded me that there is a limit (and a price) for being too safe (at times). So far, I've always found alternatives and have never had to design remotely (except a few times when NO Users were on board). If I reach a point that I have little/no alternative then I'll remember this conversation and relax a bit. Thank you!

Your words sway me (a bit) but 6095 doesn't at all. I'll spare you the reasons.

L

[Vaughan]

This is a known issue and has been discussed in the FSA forums (another very good reason to join the FSA).

Basically if a layout is being edited it cannot be accessed by other users. Scripts that call to this layout will fail, and FMP defaults to the first layout.

It might not be a bug but it's probably unexpected or undesirable behaviour.

[Ted S]

Vaughn,

You said:

Basically if a layout is being edited it cannot be accessed by other users. Scripts that call to this layout will fail, and FMP defaults to the first layout.

With all due respect I think you're statement is incorrect. I have a two reasons for saying so.

1. I've been doing lite development on live systems for a long time. I expect that I would have had at least 1 user complaint by now. Nothing.

2. I have two PCs on my desk. Both are connected to the same network and both have the Filemaker application. I can get myself into the layout mode on my main PC and move some objects around. If I log into the other PC using an account that has been established to mirror that of a typical user I can get to that same layout, navigate around, press buttons, etc. and everything works fine. Layout changes don't take effect until you leave the layout mode. It's kinda fun to watch the changes happen instantly on the other PC.

[Lee Smith]

With all due respect I think you're statement is incorrect. I have a two reasons for saying so.

ha, ha, ha, ha, well okay lucky.

Fore warned, fore armed.

Lee

[Ted S]

Lee,

Show me some official documentation, prererably from the Filemaker corporation, that states that working live is not recommended. If you produce such a document I'll probably change my position. I know there are folks out there who *think* this is a bad practice but of course that just their opinion. And opinions are just that; opinions. I did uncover a document from FMI that I think most reasonable people would conclude indicates that it is at least okay to develop on a live system.

Can you support your position with anything other than opinion?

[Lee Smith]

If you don't believe fellow developers, what would an article or white paper by FileMaker do to change anything. After all, any such article would be written by these same developers.

The Link in the Reply above, to Datatude.network, is one that was written by Ilyse Kazar, considered by many, including me, to be the foremost Expert Severing Files.

Lee

[Ted S]

If you don't believe fellow developers, what would an article or white paper by FileMaker do to change anything.

Lee, you and I both call ourselves developers right. Well you believe one thing, and I believe something else but we are both fellow developers. So which one of us is a casual observer to believe? I'm not aware of any 'consensus' in the development community. I'll grant you that it is possible to introduce corruption by developing live but just how likely is it? To me this is the real question. In my earlier analogy I mentioned that driving is inherently dangerous and the consequences are much worse than just a corrupted database. Everybody knows somebody who has been killed in an automobile accident so there is plenty of data to support the idea that riding in an automobile is risky. Using the same logic that you use with FM development wouldn't it be prudent to give up driving altogether because its dangerous?

On your second point; an article or paper from FMI would add great credibility because they designed the software. No regular developers have that kind of inside knowledge that I'm aware of.

Lets not forget that we can remove all the risk by simply not using the software at all. Just leave it in the box and it should be pretty darn safe. Of course a meteor could fall on it...