Variables Disappearing

[Brian C]

I am not sure if anyone else is having the same issue as I am but in FMP 8 and 8 Adv, my global variables dissappear when another file is opened. This kind of defeats the idea of a global variable imo...

I have had to result to storing my data in global fields again - and I was hoping I would no longer need to do that.

[Søren Dyhr]

Pass them on further via script result.... allthough it requires you to split up the scripting.

But you have to defend your position, in choosing several files for a solution ...I would in a migrated solution copy/paste tables from file to file, gathering every dealing in one single file!

--sd

[Brian C]

This solution has been consolidated a lot already - Trust me

I was already at the file limit for FMP Svr 5.5 and I had to do a bit of scripting in FMP 6 to make sure the client's open file limit was never exceeded (50).

The solution does a lot of importing and mass deletion of records on a regular basis.

This causes the files to have a need to be compressed on a regular basis. I have also found that over time this has a caused a issues with the field indexes - forcing a semi-annual rebuild.

Because of these issues - I have tried to plan ahead in case I discover issues in v8.

So for the sake of safety, speed (and my own peace of mind) I have split the largest tables into separate files since some of them are quickly approaching 2gb.

[Søren Dyhr]

So for the sake of safety, speed (and my own peace of mind) I have split the largest tables into separate files since some of them are quickly approaching 2gb.

This cieling for reliabilty, can easily be exceeded now (8tb) In fact can a single text field now store 2gb. The same thing could be said about the 50 table limit you once should work around, therer is no limit to the number of tables beyond what the memory availiable allows.

The solution does a lot of importing and mass deletion of records on a regular basis.

The mapping allows imports between internal tables....

--sd

[Brian C]

I am aware of the specs for fmp 8 and it's ability to import data between tables within the same file. I made sure that I understood all of v8's specifications and limitatios long before I began my conversion. I waited until 8v3 before I even considered moving forward simply because of the problems that the earlier versions posed.

Lets just say that until I feel that FMP 8 has proven it's reliability over the long term in a real-life scenerio and not just in a test enviornment - I will have my reservations about keeping absolutely everything inside the same file at least for the time being...

FYI: I am using the separation model in my solution. This mey help you to better understand another of my reasons for using multiple files.

Edited June 19, 2006 by Guest
Revision

[Søren Dyhr]

Lets just say that until I feel that FMP 8 has proven it's reliability over the long term in a real-life scenerio and not just in a test enviornment

Yes that's very much a psycological issue, when you dare or not... But when it comes to it, mightn't it be the integrity of the data which is the biggest problem, but instead the time it takes you to pin down a flaw in the way business rules were interpreted pre fm7 vs. the way it could be done today. It might very well leave your solution disfunctional for days ...just a simple thing like the ownership of a record (record locking) has changed considerably.

In a solution of your size, would I be very, very carefull because it's said in the migration foundations that:

For more complex solutions, if you try to just convert and run, you may fairly quickly realize that it is not the ideal approach and start again with a more methodical approach. This document is intended to enable you to take a sequential approach to a successful migration of your solution.

This means that you could jump to wrong conclusions in your chase for unreliability issues.

The way you can make relations work, clearly exceedes anything you've been used to with fm6, so a lot of the measures to tunnel values hardly are issues any more ...it simply have to be redone with the raw tables anyway.

--sd

[Brian C]

I don't consider it a psychological issue.

You generally don't see some bugs in in a product until it is put through its paces and pushed to it's limits over time.

I am just choosing to be more conservative until I feel FMP 8 has proven itself to me.

Because I have switched to a separation model, I felt it would be best to do a complete rewrite. I am not doing a simple / fast conversion at all.

[comment]

my global variables dissappear when another file is opened.

I am quite sure you don't mean that? You mean they are not carried over to the other file, right?

[Fitch]

I am not sure if anyone else is having the same issue as I am but in FMP 8 and 8 Adv, my global variables dissappear when another file is opened. This kind of defeats the idea of a global variable imo...

That's not a bug, it's a documented behavior: the scope of global variables is the current file. They don't disappear when another file is opened; go back to the first file and you'll see that the $$variable is still there.

Now if I could just find where that's documented...

[Brian C]

I never said that this particular behavior was a bug - just that it was inconvienient for what I wanted it to do.

Thanks Fitch, for further clarifying this behavior for me.

Soren's almost clued me into this behavior but I did not pick up on it.

When I started having problems with using the global variables across files I looked in the documentation and noticed what you are referring to. Wether it retained the data or not was unclear in the documentation - which led me to an incorrect conclusion.

It was the behavior of the Data Viewer in FMP Advanced that caused me to make this mistake:

1) switch files - global variables in the data viewer disappear

2) queried the variables/clicked refresh = empty result

3) switched back to the first file and data viewer was still empty

It did not occur to me to try the refresh button one more time when I was back in the current file - which after I just tried it caused the data to magically reappear! Yay!

Thanks again! While this still feels a little like the old days of passing data between files - It is still an improvement.

Edited June 19, 2006 by Guest
added more info

[comment]

Now if I could just find where that's documented...

Help > Script steps reference (alphabetical list) > Control script steps > Set Variable script step:

A global variable can be used in a calculation or script anywhere in a file, for example, other scripts or file paths. The value of a global variable is not cleared until the file is closed.

Help > Functions reference (alphabetical list) > Logical functions > Let function:

The scope of global variables is limited to the current file.

[Razumovsky]

I believe it makes some good sense though. Imagine if they were not limited to the current file - every single global variable you wanted to create in any files that might possibly ever be open at the same time would have to be unique in name.

I suppose they could add a Filepath prefix as well, but that would get kind of awkward in my opinion. I have been enjoying the simplicity of being able to use $$n or $$row in calcs across many files. So nice and quick...

[Brian C]

While I do see pro's and con's to keeping global variables restricted to the current file, it still makes it cumbersome to have to write scripts to send data back and forth. It just seems to make it more of a "local" variable than a "global" variable to me. Perhaps it should be referred to as a "File" variable since that seems to make a bit more sense logically.

I think that perhaps an addition of one more type of variable is in order. Perhaps $$$variable would be a logical format?

This would provide one more layer that would make tracking user session data much simpler when using a multifile solution.

Not everyone can or will use the single file approach in fmp 8 especially if you bother to consider that some of us need to be able to create separate modules for a product which naturally lends it-self to separating data into multiple files.

[comment]

I don't think Filemaker currently has an object where such super-variables could be kept. It seems like file is the highest in the hierarchy.

Perhaps a better wish would be for FMI to implement the separation model natively.

[Søren Dyhr]

Alright, this task seems to be the perfect candidate for this approach:

http://edoshin.skeletonkey.com/2006/02/options.html#more

--sd

[comment]

I think I like this one better.

[Søren Dyhr]

Indeed it's a cool technique, but when it comes to debugging ...won't it hurt anyone with the extended readability Mikhails approach has to offer and how fast it's implemented. I have used your approach several times ...although I still scratch my head to make it work ...where Option( and Get Option( are almost self explaining.

One more thing to remember, is that scriptparamters are stacked, so if you call a subscript will the previous paramters not be overwritten or evaporate before the outer script is terminated.

Finally should it be said that a developer not should be a stranger to recursive scripting ...although $variables have made them relatively redundant. Could really elegant code stem from the use of recursions.

--sd

[comment]

Seems to be a matter of preference - I find it much more convenient to define variables in the accustomed manner of declaring them in a Let() function.