Not a big deal but I discovered while troubleshooting a problem I have with Permanent Variables that in making a simple test database if the only change I make to the database is changing the Permanent Variable with a procedure and then quit I am not prompted to be asked to save changes.
When I reopen the database the change is not saved.
I am not sure if that is the intent so I am just sending an alert of sorts.
George
In the same permanent vain, what’s the easiest way to see a list of all the permanent variables in the open databases? For example, after you establish a P.V., it’s, well, permanent. So if you remove the line from the procedure that established it, it seems there would be no record of its existence. That could be … troubling.
Unfortunately that is correct. You are only asked about saving changes if you have made at least one undo-able change since the last time the database is saved. Changing a permanent variable is not an undo-able change, so no prompt. If there is any doubt, it’s probably best to explicitly save in the code that changes the permanent variable.
letpermanent flurgle = "gobble-de-gook"
save
If you’re using a Text Editor object to change the permanent variable, you should add code to the text editor that saves the database.
It would of course be nice if a document could be marked as changed even if no undo-able change has been made. Unfortunately, Apple has not provided a mechanism for that.
The easiest way (and also most difficult way 
) is to use the dbinfo(“permanent”,“databasename”) function.
Note that this ability of the dbinfo( function is mentioned on the permanent statement’s help page.
I like Gary’s Variable View Utility in the Database Exchange
Thanks Jim. Moving to my new computer so I have to get transition all my Pan 6 databases. It has been a lot of work. Some of this stuff has not been looked at in decades so often it’s “How did I do that?”
James, I will check out Gary’s Variable View Utility. Thanks again all.
I’m not 100% sure, but I think Panorama 6 also would not prompt you to save if the only change you had made was to change a permanent variable.
I’m sure that was the case. My explanation for it was that there were actually two variables, the permanent variable, which was part of the database, and an associated file global with the same name.
Data entry objects, and procedures would set the value of the file global. The permanent variable would not be updated until the database was saved. The file global wasn’t part of the database, so changes to its value didn’t change the database, and there were no changes to be saved. Unless of course there had been changes to a field, procedure, form, or some other part of the database.
George - that is why adding comments to your procedures is so important. In my programming classes in the late 60’s. the instructor would mark our coding assignments down if we didn’t have adequate comments. Sometimes it’s handy to write the comments first. In the procedure, using comments, outline the steps to be performed - focusing on the “why” - then go back and fill in the code for the various stages.
Another discipline is adding a dated comment to the procedure whenever a modification occurs. Maybe even leave the older code in but comment it out (and possibly indent it for easier identification).
The practice will serve you well as the years go … bye.
Thanks designer!
Sage advice. I have been doing that more as the years (decades!) have advanced but I need to follow your advice more.
There really is an art form to this stuff. A sort of Chess Game where quickly you have been where you have not been before. And Pan X has put this to a new quantum level. Even procedures. Use call statements, or paste it into a button. To Case statement or not to.
Fascinating stuff. And challenging!
Me too! 
That’s a rather clever explanation! And everything you say is true.
However, it’s still the fact that this is not an undo-able operation that is the issue. For example, suppose you had code with this assignment to a field.
Name = "Jane Doe"
In this case, the database is definitely getting modified, but there still would not be a prompt if you closed the database, because there was no “undo-able” operation. You could make it undoable like this.
startdatabasechange "currentrecord"
Name = "Jane Doe"
If you ran this code, and then closed the database, you would be asked whether or not you want to save changes.
In fact, you could do this with an assignment to a permanent variable.
startdatabasechange "currentrecord"
letpermanent flurgle = "gobble-de-gook"
With this code, closing the database would ask you to confirm. Note, however, that if you used the Undo menu command after running this code, it would not reverse the effects of the assignment. Assignments to variables are not undo-able. But this would be enough to notify Apple’s document management code that the database has been modified and that you should be prompted to save changes.
I was talking about your statement that Panorama 6 didn’t ask if you wanted to save the changes if the only change was to a permanent variable. You said you weren’t 100% sure that was the case. I was sure, because I remembered my explanation for it. I wouldn’t have needed to explain it, if it hadn’t happened.
Aha, I didn’t realize that is what you were referring to.