Retrieving server variables in .Initialize procedure not working

[CooperT]

In shared database, statements to retrieve servervariables do not work. This error statement appears in the console

Timer _Temp_295123900 error:Server variable svfirmadmin does not exist

That’s not my timer, so I assume that is the timer that runs the Initialize procedure.

My hypothesis is that the connection between the client and server has not finished being established when the servervariable( statement is reached. If I click a button shortly after .Initialize finishes, the server variables are retrieved.

[admin]

Could you post the code? I don’t need the whole thing, just the line that accesses the server variable.

[CooperT]

if info(“globalvariables”) notcontains "gvfirmadmin"
    letglobal gvfirmadmin=servervariable("svfirmadmin")

    letglobal gvfirmbilladmin=servervariable("svfirmbilladmin")

    letglobal gvtechsupp=servervariable("svtechsupp")
    console "defined global variables"
endif

Because of this issue and the opensecret issue in .Initialize, I have removed all the opensecret statements and server variable lookups from all the .Initialize procedures. I am once again hoping for a perfect week with no crashes or other failures among Beta Testers. I don’t count minor programming issues that I caused against Panorama, so I think we are going to have a good week.

[admin]

I was just about to message you to ask how the week had gone. I was definitely hoping that no news was good news, it sounds like that is the case?

@CooperT

I have removed all the opensecret statements and server variable lookups from all the .Initialize procedures.

I had considered making this suggestion to you, I’m glad you did so on your own initiative. I think I have fixed all of the issues in regards to secret databases and sharing, but I haven’t actually tested using opensecret statements in an .Initialize procedure yet. It turns out that both updating to a new generation and synchronizing did not have any code to handle secret windows, both assumed that the database they were dealing with was visible and in the active window. I have gone thru all of the code with a fine tooth comb and I believe all asynchronous operations now correctly handle secret databases. But I haven’t finished the testing yet. I also added a pop-up window to display progress if there is no window to display the progress in. This popup window also appears if the toolbar is hidden. Making this popup window work was actually the bulk of the work, in fact it took several days. But since it’s possible this could be an operation that takes quite a long time, I thought it was important to make sure that the user always sees that something is happening, not leaving them hanging wondering if Panorama has frozen.

Another change I’ve made is that by default, Panorama no longer asks users if they want to upgrade to a new generation, it just does it. For clerical staff, I would assume there is no reason why they would ever say no or want to look at the change notes. If you do want to get this choice every time a new generation is available there is a new preference option that enables that, but the default is not to ask.

If you are now operating smoothly, I’m going to take the extra time to look into this server variable issue and a couple of other things before releasing b7. Though you can’t really tell, I’ve been pushing to get it out as fast as possible so you could try it, but it sounds like it’s probably better at this point to be thourough rather than to hurry. I’ve also got a lot else going on, WWDC is tomorrow, and my accountant is asking for tax information. Never a dull moment!

Oh by the way, while I was working on the network code I also set up a preference to adjust the network timeout when a client is accessing the server, as you requested

The default is 30 seconds but you can set it as low as 5 seconds.

Oh, and remind me I need to document all these changes!

[CooperT]

@admin

Another change I’ve made is that by default, Panorama no longer asks users if they want to upgrade to a new generation, it just does it. For clerical staff, I would assume there is no reason why they would ever say no or want to look at the change notes. If you do want to get this choice every time a new generation is available there is a new preference option that enables that, but the default is not to ask.

I agree with that. I can’t see any reason a user would ever need to decline an upgrade.

I look forward to b7 when it is ready.

Thanks for changing the connection timeout.