Message statement exits a database opened in secret


When I run this code:

; Procedure within database 'Travel'.  
; The database 'Misc' has a field named 'Category'.

opensecret "Misc"    
setactivedatabase "Misc"
    message Category
    message "Current database is " + info("databasename") 
    message Category
until 2

… the first message gives “Veterinarian” which is the value in Category. the second message gives “Travel”, so I appear to have exited the secret file. This is confirmed when the third message gives " Field or Variable [Category] does not exist.".

Is this expected behaviour? If not, can anybody repeat this result?


Not certain of this but it does appear that the save statement also interferes with access to a secret database.

I find that I have to insert setactivedatabase statements before lots of other statements to make sure I’m operating in the correct database.


I get the same behavior, which is not what I expected either. I though the active database would continue to be the secret database until intentionally changed or the procedure ends.


I think it is too easy to close a secret database without knowing it. I have added a .CurrentRecord procedure to reopen it if it is closed. Lookups in a form will not change until you change the record, so that avoids lookup errors. I think that it is necessary to add procedures that reopen secret databases that might have closed whenever you need data from them.


Whenever the visible window changes, Panorama resets the active database to the topmost visible window. In this context, the message statement counts as a visible window, so when the message statement appears and this disappears, that counts as the visible window changing. That’s why you are no longer in the “secret” database after the message statement. One option I find useful in this situation is to use nsnotify instead of message.


That’s fine if you have Notifications turned on. I find Notifications to be the single most annoying feature(!) of recent versions of macOS and I never have it on.

But your explanation is helpful and I now know how to handle the problem. Thanks Jim.


As I mentioned in my second post above, the save statement also resets the active database. This actually good because saving is usually the last thing you do but the documentation is a tad deficient - I’ll put it on my to-do list.