Panorama X says open database is not open

I really don’t know what to do when this happens (often):

Screen Shot 2022-01-26 at 4.20.51 pm

… and Panorama X is frozen.

At a minimum, you could surround the Closedatabase statement with a try catch block. Maybe that would allow you to escape from the problem without restarting. I would also try putting a wait 0 statement before closedatabase to make sure that no other code is running when the closedatabase statement begins execution.

Both of those are worth a try - thanks Tom.

Really curious as to know what your thoughts are on this with re to whether your ideas are the way that a programmer should have to be working in the programming world, or if these are items that really need to be fixed from the ProVUE side. I’ve seen more use of and recommendation of the Wait statement than I like. In my world, I’d like for code to work or not work. (I am specifically wanting to speak towards the item of timing.) I don’t want to have to guess whether a previous item has had time to finish and account for that kind of stuff. If a programmer were to have to be responsible for timing, the coding might never be correct. 10 years of it running fine could then find a failure due to some process that in later life didn’t wait long enough for another process that then took longer to complete. I am imagining that this could be from processes being accomplished by different threads? Am I off base in my expectations?

This and similar problems are occurring frequently in a large procedure which manipulates about a dozen databases. The insertion of message statements at regular intervals fixes all problems and the procedure runs as it should.

It has all the hallmarks of statements executing before earlier ones have completed. I could live with that if I knew what the rules were.

I have the same problem frequently. I get spurious errors referring to databases that don’t exist. Putting in message statements tames the beast.

How many Messages should we use? Where should we put them within the procedure? Have I added enough?

Is this the way we are supposed to be programming? Put in enough Messages until it works. Or if it breaks, add more?

I think I have seen earlier communications from Jim that some statements have built into them a requirement that other code finish before they begin. And I think Jim has expanded that list of such. statements. It does seem like it would be useful to know which statements have that feature, so the programmer could add a wait 0 if she suspects that it will be needed. I have encountered this issue when using an arraybuild followed immediately by a filesave-the filesave fails because the array is not yet ready. I am sure Jim has more carefully considered ideas on this topic than I do. Understanding these issues might require reading

I have no problem that my FileSave might be delayed by Panorama waiting until a previous process is finished. But I want that on Panorama to see if any other processes have not been completed, and if they have not, to wait. I don’t want to have to add cautious, uncertain time outs, just in case, prior to commands. That only causes slower procedures that may actually not be slow enough until we figure out the right amount of Messages or delays to add. Sounds like a crazy way to program.

On the other hand, if you force every statement to wait for prior statements to finish, that might significantly degrade the performance. Which I why the issue could be handled by informing the user if a statement waits or not, then she can guard against the risk of unfinished code before a statement begins when that is needed. That’s my theory anyway, but I would hope more knowledgeable people than I weigh in on the subject.

I really don’t know what to do

Well, you could start by sharing what the actual code is that you have written.

The first thing the closedatabase statement does is check whether the database is open. This is very straightforward code that is used by dozens of Panorama statements. At the time that error occurs, the closedatabase statement really hasn’t done anything yet. Whatever problem is causing this error is almost certainly in the code before the closedatabase statement.

I would also try putting a wait 0 statement

There is only one reason to ever use a wait 0 statement. It needs to be used if you are currently running atomic code and need to perform an operation that cannot be performed in atomic code. If you don’t know or don’t remember what atomic code is, please see this help page. There was also a video session from the spring of 2021 where I spoke about this topic for an hour.

seen more use of and recommendation of the Wait statement than I like

You haven’t seen that from any official ProVUE source. If you closely study the documentation for how the run loop works, you’ll understand exactly when this statement is needed. Note that using wait 0 is exactly the same as setting up a timer that runs once, except that wait 0 requires a lot less typing, and also allows you to keep your local variables.

I think I have seen earlier communications from Jim that some statements have built into them a requirement that other code finish before they begin.

No, you apparently misunderstood my discussion of atomic mode. Panorama statements always run sequentially, you never have to worry that a statement will start before the previous statement finishes. Any delay needed is automatically taken care of in Panorama’s Objective-C code. For example the save command will delay until the file I/o is completed, and any command that updates the screen will delay until the screen display is complete. This is all taken care of for you and you have no need to be aware of it.

Note that the wait 0 statement isn’t actually a “delay.” Instead, it is a mode shift. If used in atomic mode, it tells Panorama to run the rest of the code in non-atomic mode (i.e. using the run loop). If you use this statement when already in non-atomic mode it will still run the rest of the code in non-atomic mode, so in that case it basically does nothing.

On the other hand, if you force every statement to wait for prior statements to finish

This is exactly what Panorama does. As Robert has alluded to, any other course would lead to madness.


I think this entire topic has gotten hijacked and taken in a false direction. Assuming that you are not running atomic code (which you must not be, since you are switching windows) I don’t think using wait 0 will have any effect on this problem. It won’t hurt and is easy to try, but I will be very surprised if it had any affect.


One other note – the closedatabase is intended to close a database that is not currently the active database. It looks like Tickers is the current database. Have you tried simply using the closefile statement? Or if it’s not the active database, you could use setactivedatabase first.

Here’s an example:

I added the window Tickers and delay statements in the hope that they would help but it didn’t. I’ve tried longer delays but they don’t help. One annoying aspect is that this same error message comes up for various files intermittently - I’m ready for bed now and I wouldn’t be surprised if the error didn’t manifest in the morning.

I think you could replace the closedatabase lines with just closefile.

closefile
closefile

Also, line 349, window “Tickers”, is probably not necessary.

I must add my own frustrations. I’m relatively new to PX, but with Michael’s help I’ve been getting up to (some) speed with my coding in PX. The code above is something Michael and I have been working on. With that specific code, not only do I get the “not open” error, but when I close the still-open data sheet, Panorama crashes. I’ve even tried rebooting my Mac and restarting the process, but the error still exists.

Now, I have at times gotten lucky and had an error fixed (thanks again to Michael) only to go back to earlier code and making a minor change and having a similar error on a different open-that’s-not-open database that wasn’t an error before. And no, that minor change was not insidious.

I tried the suggestions: adding delay, wait, closefile and message. Obviously there’s something else at work in this code, but I can’t find it.

But surely it doesn’t disrupt the procedure if applied to the active database? Or does it? The Help file doesn’t say anything about that. The big advantage of closedatabase is that when you come back to modify your code after a long absence, you know precisely which database is being closed. The procedure in question has almost 900 lines of code and manipulates a dozen or more databases so it’s good to know which part of the jungle you’re in.

But those lines are AFTER the lookup( failure so they’re irrelevant.

I know. It was a desperation attempt to cope with aberrant behaviour by Panorama X.

I forgot to mention last night that, after the lookup( fail, the Tickers database was frozen and I had to quit (not force quit).

At the risk of boring you, I should also point out that just prior to the failure documented above, an almost identical error occurred at about line 720 and, prior to that, the procedure ran without fail. All tests were with identical data under identical conditions and I always quit before running a new trial. This is the really frustrating aspect.

You probably know that I have also had about 50 to 100 crashes along the path to this point.

I have been a dedicated and supportive Panorama user since Panorama 1 and you know how appreciative I am of the work you have put into its development so I’m reluctant to sound off too much but this peculiarity has cost me many days of frustrating toil with no end in sight. I also know that you have no idea where the solution lies either.

And, in anticipation of the suggestion that something is wrong with the Tickers database, I should point out that I’ve recreated it several times from scratch.

Some progress and perhaps some information:

I couldn’t get the lookup( to work so I replaced it with a record-by-record process and I’ve progressed as far as line 888 by dint of the insertion of about 25 message statements, some of them for every iteration of a loop.

Here’s the response to an info("databasename") message - it explains to some extent why the open database isn’t open - it doesn’t have a name. It has on occasion been referred to in an error message as “Database Null”:

Screen Shot 2022-01-29 at 4.19.57 pm

I’ve finally got the procedure to run to the end (still riddled with message statements), but I’m left with an open Tickers database which is frozen, forcing me to quit.

En route to where I am now, I had this interesting situation:

Screen Shot 2022-01-29 at 12.21.40 pm

Logical I suppose if one of the two Tickers databases doesn’t have a name in Panorama X. But should macOS allow two files with the same name? Is that perhaps part of the problem?

Tickers has many fields and loads of data so I’m not prepared to rebuild it brick by brick but I did export it as a text file, dumped the original and imported the text file to a new database. Didn’t make a scrap of difference. Also quit every other application with equal success. Any suggestions? Please, pretty please?

55 crashes in January, all in the last 8 days.

Fifty of these crashes have no Panorama code in the stack trace, only Apple code. Only five have any Panorama code in the log. A stack trace with no Panorama code in it has zero diagnostic value. Usually only a small percentage of stack traces have no Panorama code. This usually means that some code went way off the reservation, but didn’t crash immediately. It’s kind of like the perfect crime, leaving no evidence behind. (Occasionally it means there is a bug in Apple code – it does happen.)

Update: Looks like there are another half dozen or so crashes since I last updated the crash report database earlier today. All of these are only Apple code.

The closedatabase statement has a completely different internal path than the closefile statement. If you’re worried about which database you’re about to close, you can always just use the window or setactivedatabase statement just before the closefile statement.

Actually, the closedatabase statement is a recent addition, so it’s not nearly as battle tested over years as closefile. And it was designed for closing other databases, not the current database, I’m not sure if I ever even tested it for closing the current database.

I have a radical suggestion for something relatively quick to try – remove ALL closedatabase and closefile statements from your code. You can just manually close the databases at the end. Perhaps that’s not an acceptable long term solution, but it will identify if closing databases is the cause of the problem. I assume the databases aren’t so large that they can’t all be open at the same time.

You never mentioned a problem with lookup before.


It really feels like you are attacking this problem piecemeal. You’re never going to fix a 900 line program that way.

First of all, do you really have a task that requires 900 lines of code to run as a continuous block? In my entire career I’m pretty sure I’ve never written a block of code anywhere near that large. Figure out how to break the task into separate parts. Get part 1 working in a way that you can then skip to part 2 and debug that without having to run part 1 every time, then continue for part 3, 4, etc. It’s a lot easier to get separate small components working than to get one huge component working. Panorama X contains almost 200,000 lines of Objective-C code, and 60,000 lines of Panorama code, but there are very few subroutines over 50 lines, and only a handful over 100 lines.

Secondly, you’ve never mentioned using the most powerful tool that Panorama X now has for debugging, the Debug Instrumentation system. Using this system is kind of like building a machine out of clear plastic so that you can actually see all the moving parts as they are moving. If you do a careful job of adding instrumentation to your code, the source of an inscrutable problem will often jump out at you. I would really recommend that you carefully watch the video session on this topic, then take the time to add good instrumentation to your code. To add good instrumentation you’ll need to carefully think about your code, and sometimes just that thought process can expose issues.


One last kind of wild thing you could try – downgrading back to Panorama X 10.2 b24. Though the changes between b24 and b25 appear minor, there was actually a huge change in the tooling used to build Panorama X. Up through b24, Panorama was built with Xcode 8, but b25 was built with Xcode 12, which is 4 years newer. This is a big change. I recently discovered at least one crashing bug which was caused by this change (and which I haven’t been able to track down yet). Your crashes do not fit the signature of this bug, but perhaps there is another new problem I’m unaware of so far. If you don’t still have a copy of b24, you can use the Check for Updates window to download it, there are instructions for downloading older versions here.

One last tip – be sure to take breaks!

Is it possible that the Apple crashes are related to the existence of two files with the same name, as mentioned above?

I’ll try that although many of the Panorama X freezes and error messages have occurred at window and setactivedatabase statements - almost all related to the Tickers database.

As noted above, I get freezes and error messages triggered by a range of statements. There just didn’t seem to be any point in reporting all of them given that they all appeared to have the same issue - the non-existence of the Tickers database.

This is an excellent suggestion which I’ve had in mind because it’s what solved a similar problem with a different procedure in the the same database. And this procedure is modular, with nine discrete components.

However, inserting stop statements to halt the procedure at selected points, I’ve tried running just the first module (no fails) then the first two in sequence, at which stage I get a fail (defined as a freeze or error message) in the first module. Then I can sometimes run them again with no problem. But maybe breaking the procedure into several independent procedures will help.

I’ve never used a debugger but I suspect it’s now time to do so.

An interesting suggestion but, if it worked, I’d be stuck at that level of development, never to experience the joys of higher versions. Actually, as I write, I see that Pierre is trying that.

Thanks Jim. I’ll keep trying. And I do take breaks.