‘disappears’ may be misleading. it still exists; it just loses its value.
this behavior occurs in just one file. it’s a permanent variable that is supposed to store a folderpath. it’s used in a form, in an object that displays images. anyway, from time to time, the form quits displaying its photos because it no longer has the folderpath.
this happens so often, i’ve created a procedure to reinstate the value.
this is why i say the variable hasn’t disappeared, just lost its value. the proc just makes an assignment; it doesn’t create the variable.
i was trying to recreate a beloved pan6 functionality.
i wanted to be able to start again where i left off following a crash or a force quit (crashes, thank god, have become quite rare, but i do have to force quit frequently when a proc seems to take forever.)
to this end, i created a permanent variable called ‘workspace’ in a file i always have open, called ‘p’, as well as a proc to give it a value.
the value is a table with all open files and a field indicating whether the file is secret or not. there’s also a proc to reopen all the files, making them secret as appropriate.
everything works, but if i force quit panx, or even just quit panx in a normal way, then relaunch it and open ‘p’, the file with the permanent variable ‘workplace’, the variable no longer has the value it had when i quit panx. its value is now the value of the current workspace, ie, just the file named p.
so the variable still exists, but it has lost its value, and taken on a new value: ‘p’. always the same value. the only guess i have as to where it could possibly get this value is that its the first value it ever had.
the database has an init, but it doesnt do anything with the workspace variable.
When you open a database with a permanent value, or create a new permanent variable, Panorama creates a fileglobal variable with the same name, and gives it the value in the permanent variable. It’s actually the fileglobal your procedures and form objects are working with. When you save the database, the permanent variable is updated to the value in the fileglobal, and saved as part of the database.
If the file closes without being saved, possibly because of a force quit, the permanent value doesn’t get updated.
I should also mention that changes to a fileglobal variable aren’t changes to the file, so you may not get any automatic saves, if you haven’t been making changes to the file. A normal quit could easily be a quit without saving.
here’s the sequence of events.
i launch panx by launching ‘p’.
i open a few files, do a little work.
(remember there’s now a timer started by p’s init proc, so by now the workspace is saved.)
i check the value of the workspace variable. it’s as it should be.
(remember also that both the proc that captures the workspace and the proc that shows me its value include a save, so if i’ve checked the value of workspace, i have saved the file.)
i force quit.
i launch panx by launching ‘p’.
workspace has lost its value; its value is now ‘p’.
yet another instance of a database that forgets the value of a permanent variable.
here’s is how it goes.
i run a proc that uses the variable.
the proc fails with the message 'variable doesnt exist’
i run message dbinfo(‘permanent’, ‘’) and see the the variable listed.
i run a proc to assign the value to the permanent variable.
i run the first proc (the one using the permanent) and it works as expected.
i fiind this annoying as hell.
can no one replicate this issue?
has anyone else experienced this.
I have just had exactly Sam’s experience with the only PX file which I have been using daily over several months. It stores complex production data from four factories.
It contains three permanent variables. On friday after running the daily report (which requires the presence of two of the three initialised permanent variables) the file was saved without saving any of the permanent variables’ contents. I only discovered this on monday when I tried to run the daily report and got the error “variable does not exist”. I went back through my Time Machine backups and found the file backups from before and after running the report on friday, the former with values in the three permanents, the latter without any.
Just as Sam experienced, the permanent variable names were still declared and saved, but all three were as if they had never been initialised, and did not even contain nulls. Today I reinitialised the three variables and ran the daily report without any problem and with the contents of the variables saved intact.
I remember reading these posts of Sam’s above rather cursorily over the months, and note that nobody else has reported this problem. Surely that can’t be because very few of us use permanent variables? Unlike Sam I have only had the problem this one time – so far.
Sam, do you still lose the permanent variable’s value?
I’m pretty sure that on friday when the permanents’ values were lost that Pan X either crashed or that I had forced quit when it hung at the end of the report process. I’m not certain because I didn’t realise that the variables’ values were lost until late monday, but I did have several stability problems with PX when coding and testing files over the intervening period.
As an experiment I’ve tried to clear the value of a permanent variable procedurally using Pan X statements and functions, and I have not been able to, except by using undefine to destroy the variable and then recreating it with the permanent statement but not initialising. I have never used this sequence in any procedures before.
When the values in the permanent variables are put into fileglobal variables upon file opening, are the permanents’ values retained until they are replaced with the values in the matching fileglobals upon saving, or are the permanent variables cleared of values until the file is closed?
When a file is open, Panorama simply keeps a list of permanent variable names. The permanent statement creates a fileglobal variable, and adds the name to the list.
When the file is saved, Panorama goes thru the list of permanent variables, and saves the variables and their values into the saved file. Each is actually saved as a pair – I can’t see any way that the name could be saved without a value.
When the file is opened, Panorama restores the list of permanent variable names from the disk. It then creates a fileglobal with that name and loads the value from the disk file. From that point forward there is no actual “permanent variable”, just a fileglobal variable with a name in a list.
So the answer to your question is – permanent variables don’t really exist when a database is open. All there is is a list of the permanent variable names – no values.
As I said I can’t se any way that a permanent variable could be saved without a value. However, in Panorama X that value could be the error “variable does not exist”. So it could be that something happened to the fileglobal value before the file is saved. In that case the permanent variable would be correctly saving the value “variable does not exist.”
Of course that just possibly leaves a different mystery – what happened to the fileglobals? There haven’t been any reports of missing fileglobals. Of course normally if Panorama crashed or hung you would have no way of knowing what the value of a fileglobal was. It sounds like something happened that would eventually cause the crash or hang, but perhaps the Apple auto-save kicked in and saved the file in the middle of that.
I’m sure someone is going to suggest that in that situation Panorama should just resave the original permanent variable contents from when the file was opened. Let me shoot that down – there is no record of those values after the open process is completed (other than the fileglobal variable values, of course, but those are apparently compromised).
What might be possible would be to refuse to save at all if the variables are compromised. Assuming, of course, that this is really the problem, this is really just speculation on my part. I’ve written up this speculation as a bug report.
Of course that just possibly leaves a different mystery – what happened to the fileglobals? There haven’t been any reports of missing fileglobals. Of course normally if Panorama crashed or hung you would have no way of knowing what the value of a fileglobal was.
This is sort of consistent with my recent experience, that is, the permanents’ names are saved but without values during a crash or hang.
However, this is far from the only time that a Pan X file of mine containing permanent variables has hung during processing (or a Pan 6 file, for that matter, and from what you say their permanents would be handled the same way as PX’s are).
But I can only recall one previous occasion on which the permanent variables’ values were lost, and that was perhaps nine months ago when I was converting a P6 file to PX and lost the values of over a dozen permanents in the P6 file. I didn’t even realise this until I sent you the P6 file and you discovered that the permanents were empty, much to my embarrassment at the time.
My point is that this is an extremely rare event. Sam and Jeff have reported similar experiences, and theirs appear to be reproducible, unlike mine so far.
It appears no update to this, so I will add what has happened to me today, and a couple of times in the past. I have two permanent variables keeping track of a few things. Never had a problem in Pan6. Now, when I have a power failure (as we did last night) with PanX open (as it usually is) the values of the permanent variables are erased.
I gather there is no way to recover those values.
UPDATE: It is possible to use Time Machine to go back and retrieve the data that was in the permanent variable.
This was just discussed under a different topic (“Favorites Vanish Mysteriously”) two weeks ago. I believe I have been able to track down and fix this problem, which did turn out to be a problem with permanent variables. The fix will be in the next release.
hope its soon because i’m still having the problem, although it’s intermittent.
got the error today in a database i use once a month. it managed to remember the value for the last few months, but not today.