Second Auxiliary Database Sometimes Does not open

If I follow these steps, I get this error message,


and the second of two databases listed as auxiliary databases does not open.

Start PanX, 10.2.0.b9 (3435) by click the dock icon for a shared database (in my case, “Navigator”
Use a Navigator procedure to open a second (non-shared) database named “BP”
BP has two auxiliary shared databases, “SD Matters” and “Timekeepers”. Both have .Initialize procedures.
Result: SD Matters opens but Timekeepers does not. I repeated this several times.

To my surprise, I change the order of the Auxiliary databases, both databases opened normally (not secret) and their .Initialize procedures ran. The Auxiliary function seems to have stopped working as intended. [Added note: Sorry. I forgot to mark them as open with no windows after putting them back in place.]

I am in the process of downloading another copy of b9, but it’s moving dreadfully slow. (8 kb/sec-a bad dialup modem). I’m stopping that and will try again later.

2:20 pm EDT: Downloading working normally again.

If changing the order back causes the problem to occur again, please open the Instrumentation panel and choose the Launch with Shared Database option by clicking on the star, then we can see what is going on.

Am I correctly reading this added note as cancelling the previous sentence?

The problems with aux databases opening went away after I re-installed b9.

The issue of opening normally rather than secret was corrected by correcting the settings; i.e. that was my mistake not a software problem.

So they are working as expected now.

That is unexpected. But good news, I guess.

You haven’t made any other reports in over a week. My fingers are crossed that no news is good news?

Yes, good news. None of the beta testers reported any problems since installing b9. (until a few minutes after I made this post!)

More good bad news, to channel John Lewis. One person uses BP in the firm. That person has now reported the failure of the second aux db to open, but only if BP is opened for the first time. If you close BP then reopen it, both aux dbs open secretly as they are supposed to do. The problem has disappeared from my computer since reinstalling b9, but I wonder if you want to run some diagnostics on her computer before we reinstall b9?
The same user has another (shared db) that opens the same two aux dbs. I cannot get the same failure to occur with that one.

That’s up to you. The diagnostics would be creating a log as I outlined yesterday.

I can’t imagine why re-installing the software would make any difference to something like this.

I definitely want to know what is happening, so if the diagnostics can help, when I would like to turn on the correct thing. Can you give me directions on what to turn on?

Oh, I thought I did, but maybe that was only in my head! Enable this favorite and then try to duplicate the problem.

The failure has not occurred after several attempts after turning on the instrumentation. If it recurs later, I’ll try again.

I got your log. Are you sure you selected the Launch with Shared Database instrumentation? From the log, it appears that you selected the Shared Database Open & Close option.

In any case, the log doesn’t include the auxiliary database information. Let’s skip the star menu, you can set up the necessary instrumentation with this link, hopefully you can make the problem occur again.

panoramax://zlog?_DatabaseLib=INITIALIZEDATABASE,OPENAUXILIARY&_EnterpriseClientLib=CLIENTCLOSESHAREDDATABASE,CLIENTLOGOFF,CLIENTLOGON,CLIENTOPENSHAREDDATABASE,CLIENTQUERY,CLIENTSYNC,CONNECTTOSERVER&_ProvueLib=debugLogPreferencePanel&_UtilityLib=WAIT&Objective-C%20Classes=DatabaseDocument,ResumeAfterDatabaseTimerTask,ResumeAfterTaskStatement

Once you make a log, you can verify the settings because they are recorded at the top of the log. Here’s what your settings say, you can see that they are quite different from the link I send you above.

==== DEBUG LOG COVERAGE =========================================================
_EnterpriseClientLib=CLIENTCLOSESHAREDDATABASE,CLIENTLOGOFF,CLIENTLOGON,CLIENTOPENSHAREDDATABASE&_EnterpriseServerLib=_serverCLOSESHAREDDATABASE,_serverLOGOFF,_serverLOGON,_serverOPENSHAREDDATABASE

Your log coverage should look like this:

==== DEBUG LOG COVERAGE =========================================================
_DatabaseLib=INITIALIZEDATABASE,OPENAUXILIARY&_EnterpriseClientLib=CLIENTCLOSESHAREDDATABASE,CLIENTLOGOFF,CLIENTLOGON,CLIENTOPENSHAREDDATABASE,CLIENTQUERY,CLIENTSYNC,CONNECTTOSERVER&_ProvueLib=debugLogPreferencePanel&_UtilityLib=WAIT&Objective-C%20Classes=DatabaseDocument,ResumeAfterDatabaseTimerTask,ResumeAfterTaskStatement

Hi Jim,

I clicked the link you provided and the notification confirmed the instrumentation coverage was updated.

The same failure did occur. Timekeeper did not open.

Here’s the log, TGC Panorama X Instrumentation Log 082020.txt.

Tom

(Attachment TGC Panorama X Instrumentation Log 082020.txt is missing)

Hi Jim, I resent this to the correct email address. Tom

At the end of your log, you closed the files, right? That didn’t happen automatically as part of the opening sequence, I assume.

In this case I think you didn’t try it, but what if you then open Timekeeper normally? Does that work?

It appears that the problem is occurring in code that doesn’t have coverage enabled. Here’s a new coverage link I would like you to try.

panoramax://zlog?_DatabaseLib=INITIALIZEDATABASE,OPENAUXILIARY&_EnterpriseClientLib=CLIENTCLOSESHAREDDATABASE,CLIENTLOGOFF,CLIENTLOGON,CLIENTOPENSHAREDDATABASE,CLIENTQUERY,CLIENTSYNC,CONNECTTOSERVER,DOWNLOADDATABASEFROMSERVER,DOWNLOADDATAFROMSERVER,DOWNLOADPARTIALDATABASE&_ProvueLib=debugLogPreferencePanel&_UtilityLib=WAIT&Objective-C%20Classes=DatabaseDocument,ResumeAfterDatabaseTimerTask,ResumeAfterTaskStatement

Even without this information, I think I see the area of the problem – it’s another secret database issue. Looks like it will occur if the aux database is secret, AND if it needs to be synchronized. I’m a bit puzzled you are not seeing an error alert pop up. If you can get it to happen again with this new coverage link that would be helpful I think.

I’d still like to see the additional log if possible, but based on the log you already sent I think I see that this problem could occur just in the combination of a non-shared main database with shared auxiliary databases that are opened without windows. Any other combination should work.

Yes, I closed the DB after the failure had occurred. Yes, one can open Timekeepers and I think everything works normally.

I am going to try your new coverage now.