Global Variables, potential corruption in file

[cincin]

Hello all,

Two fellow developers and I are working on a FM9 solution that's to be boxed and sold. We are hosting the file on FMP 9 Server Advanced (Mac) and working on it using FMP 9 Advanced (2 of us on Mac OS 10.5.1 and 1 on Windows Vista).

Our solution makes use of a Back and Forth navigation system based on a slightly modified version of SeedCode Back Magic. The system uses various global variables to store the back and forward navigation trails and such.

We just recently started experiencing very bizarre behavior with the the Back and Forth script, more precisely with the setting of global variables. I'll note that the script was working fine then started to act up without any modification.

The problem is easy to isolate, the script step:

Set Variable [$$Nav_InUse; Value:"Yes"]

sets the variable to ""

Further more:

Set Variable [$$Nav_FWDStack; Value: LeftValues($$Nav_BackStack; 1) & $$Nav_FWDStack]

works and sets the variable to the first value of $$Nav_BackStack BUT:

Set Variable [$$Nav_BackStack; Value: RightValues($$Nav_BackStack; ValueCount($$Nav_BackStack) - 1)]

{I don't know why but FMForum adds spaces to my variable names in the line above...}

doesn't affect the value of $$Nav_BackStack but instead clears $$Nav_FWDStack...

Looks like corruption to me.

I called FMP's tech support but they were of very little help, the person I spoke to confirmed that it was indicative of corruption in our file but could not suggest a way to detect it, much less correct it. He said something like:"Global Variables are a bit screwy when used with FMP Server".

If I could do that phone call again I'd get him to elaborate on that statement... alarming.

I have tried recovering the file using the FMP Recover function, which did not report any corruption, did not skip anything and reported a recovered file size just slightly under my original file size. The resulting recovered file was actually slightly bigger than my original file. So it doesn't look like the recover function did much more than optimize the file content. The "bug" behaves exactly the same after the recover.

I examined the file with FMDiff which reported no corruption.

I tried creating a new script within the same file and re-writing those faulty Set Variable steps and the new script worked fine.

Running a duplicate of the faulty script within the same file causes the same bug.

Copying (copy, paste) the faulty script steps to a new script within the same file causes the same bug.

Copying the faulty script steps to a new script in a new empty file works and the steps behave as they should.

Rewriting the faulty script steps in the original script and original file causes the same bug.

Importing the faulty script in a new file worked fine and the Set Variable script steps behaved as they should.

So at this point we're a bit stuck... Rewriting the script would probably cure the symptoms but we're quite reluctant to keep working on a file that probably contains some sort of corruption, considering that this DB is to be boxed and retailed then updated to future versions. But we have no way of detecting the corruption other than witnessing the symptoms and so even going back to backup is a shot in the dark.

So my questions to you, fellow developers, are:

Have any of you had any such problems with setting variables ?

Have any of you had any sort of problems with variables (on a server hosted solution or not) ?

Can any of you suggest a way to detect the corruption (allowing us to go back to a clean backup) ?

Can any of you suggest a best course of action to follow to minimize the risk of building on a potentially corrupted file ?

Should we avoid developing a solution while it's being hosted (this allows all three of us to work at the same time) ?

Should we give up on using global variables ? any variables ?

Any insights are greatly appreciated.

Thank you!

[bruceR]

They are variables. They are in-memory. They are not part of the file structure; corruption is impossible. Sounds like a logic error somewhere. As mentioned elsewhere, try printing out your script and look carefully at the repetitions you are using.