I am getting an error on one of my servervariables.
Could not get value of server variable svPennyCompInfo in on [ERROR: Could not connect to server named ]
The database is definately talking to the server. the servervariablenames() function returns a complete list and using the servervariable() function on any of the other variables returns an appropriate value.
Am I correct in assuming that it is not a connection issue but rather a corrupted variable?
Am I correct in assuming that it is not a connection issue but rather a corrupted variable?
No, that is not a correct assumption.
If you’ve quoted the error message exactly, then it contains a pretty strong clue - there is no name for the server. I’m going to assume that you’ve quoted the error message accurately.
The server variable function has two parameters, database and variable name.
value = servervariable(database,variablename)
If the database is omitted, the current database is assumed. Either way, the database must be a shared database.
What I think must be happening is that your application has a mixed of shared and single user databases. You probably left off the database name, and at the time you used this function a single user database was active. Single user databases don’t have a sever associated with them, so naturally the servervariable( function can’t connect to a server that doesn’t exist. Boom - error message.
Hmm, in fact, now I notice that your error message is also missing the server database name, which should be between the words in and on. This is another confirmation that a single user database is currently active, because single user databases don’t have an associated server database name.
Probably the simplest solution would be for you to explicitly specify the database that contains the server variable.
Now that you’ve drawn my attention to this, I can see that though the error message is accurate, it’s not nearly as informative as it could be. It would be better if the servervariable( function explicitly checked if you were using a single user database, and reported that error directly. I have revised this code so that in the future, the error message will look like this:
Could not get value of server variable svPennyCompInfo, since the single user database My Database Name cannot contain server variables.
EDIT: The serverlookuapall(, serverlookup(, servervariablenames( and servervariables( also had the same problem of a non-specific error message if used with a single user database. I have gone ahead and fixed all of them.
In the actual code, it does specify the database name. The error I posted was when I tried to access it using the formulaworkshop. So using servervariablenames() it communicates and returns a list as expected.
I get the error I posted regardless whether the server is specified or not.
The only file that is open is Penny, a shared database.
The error you are seeing means that the server is never being contacted. Panorama can’t even figure out what the name of the server is. Your problem is entirely on the client side, the server isn’t involved at all.
The only file that is open is Penny, a shared database.
That is actually not true. The Formula Workshop itself is a single user database. There are also a couple dozen library databases that are open. However, this is just a trivia fact in this case, it is not what is causing your problem.
The only possible cause of this problem is that the database name is wrong. Looking closely at your screenshot, maybe there is an extra space between the quote and the P in Penny? Thought it does also look like there is an extra space between the " and svPennyCompInfo as well, so maybe that’s just how the font looks.
Nevertheless, there MUST be an error in the database name. That’s the only possible cause of the error you are seeing. Maybe there is an invisible character in your code. Or maybe your filename has an extra space on the end - maybe it’s "Penny " not "Penny". I just double checked - it’s definitely possible to create a file with an extra space on the end, and if you don’t have the Finder settings set up to show file extensions, it would be very easy to not notice this mistake. Since Penny is specified in the Database popup menu in the formula wizard, probably the best bet is to leave off the database name in the formula, then it can’t be mistyped. But I would check for that extra space in the filename.
I have further revised the code for all of these functions to report a different error message if you misspell the database name, or specify a database that isn’t currently open (really the same thing).
So using servervariablenames() it communicates and returns a list as expected.
FYI, most of the code for servervariable( and servervariablenames( is the identical. In fact, the since the error you are getting means that the servervariable( code is aborting early, the part of these functions that is actually running IS exactly identical. So the problem has to be an invalid database parameter that you are passing. If you passed that exact same parameter to servervariablenames(, you would get the same error. But it would have to include the same misspelling, invisible character, or whatever is going in there.
regardless whether the server is specified or not.
Since your formula is correct, I think you know that the first parameter is the database name, not the server name. But just in case there’s any confusion, I’m going to be pedantic and point this out anyway. Server variables aren’t associated with a server, they are associated with a particular database on the server. Different databases will have different variables. Had you used the server name instead of the database name, that definitely would have caused this problem.
Mystery solved!
The error message “Could not get value of server variable…” was actually the value, i.e. what was stored in the variable, not an error message about trying to retrieve the value of it. So the servervariable() function was performing exactly as expected and there were no issues with the name.
We were having issues with our server at different points yesterday and apparently the procedure that updates that servervariable at some point failed because the server connection had been broken. What seems strange to me is that Panorama actually recorded the error message to the variable and in so doing deleted the data that was there, rather than simply failing. Perhaps that is not strange but it does call into question the safety of data that is stored in other servervariables. If a temporary break of the server connection can cause data in servervariables to be lost, then backing up the contents of these variables becomes critical. (Presumably restoring a backup of the server version of the database containing the variable would restore them. )
In this case, the contents were not critical.
FYI, this servervariable, svPennyCompInfo contains an array listing the users of our database system, computer name, serial number, the date they last accessed it, versions of certain single users files that are on their computer, etc. Each time a user connects to the main “Penny” database, a procedure runs to see if this user has connected before and if so updates the date last active for their record in the array. If a user is not listed in the array, that info is added. It is still a work in process as I determine what info it is necessary to track.
So because of the corrupt data there were no users listed. Checking the variable this morning showed the info on two users who connected this morning, appended to the bottom with the text of the error still on top.
What seems strange to me is that Panorama actually recorded the error message to the variable and in so doing deleted the data that was there, rather than simply failing.
Yesterday when I was working on the code for this function I noticed another problem with the function and fixed it. I didn’t mention this second fix because it was kind of a technical explanation and my post was already long. But it turns out this second problem was relevant to your problem.
The second problem was that for certain types of errors, the function was returning text with the error message, instead of an ERROR value. This means that the program would not stop, and you could not trap these errors with IF ERROR or TRY/CATCH or CATCHERROR(.
I think you’re code probably looks something like this:
let temp = servervariable("svPennyCompInfo")
letservervariable svPennyCompInfo = newInfo + sandwich(cr(),temp,"")
Now normally, if there was a problem with the servervariable( function, the code would stop right there. But because of the bug I found, it would instead add the error message into the server variable.
For now, I would suggest modifying the code like this:
let temp = servervariable("svPennyCompInfo")
if temp contains "[ERROR:"
message temp // display the error message
return
endif
letservervariable svPennyCompInfo = newInfo + sandwich(cr(),temp,"")
Or, for more completeness, you should also use if error. The current servervariable( function does return proper errors in some cases, for example if you request a variable that doesn’t exist.
let temp = servervariable("svPennyCompInfo")
if error
message info("error")
return
endif
if temp contains "[ERROR:"
message temp // display the error message
return
endif
letservervariable svPennyCompInfo = newInfo + sandwich(cr(),temp,"")
Once the next version of Panorama X comes out, you’ll be able to remove the second IF statement.
We were having issues with our server at different points yesterday and apparently the procedure that updates that servervariable at some point failed because the server connection had been broken.
Undoubtably we are getting closer to the mystery here. But your theory that the server connection had been broken doesn’t match the error message that had been returned. The way that error message is written, the connection wasn’t actually broken. That exact error message would not be produced by a broken server connection - it can ONLY be used by trying to use the servervariable( function on a single user database. For example, I was immediately able to duplicate the problem like this:
In this case the error occurs because the specified database, Panorama Help, is a single user database.
If the error was caused by an actual broken connection, the error message would be different - it would include the database name and the server name.
I need to make a general point about updating a server variable this way. This technique is not “atomic”, so if two users happened to run this code at the exact same time, one of them will be the “loser” and their change will be lost.
Panorama provides the adjustservervariable statement (and function) to solve this problem. This changes the variable value on the server instead of on the client, guaranteeing that the operation is “atomic”, so that even if two or more users request this action at the same time, the server will correctly process the requests one after the other, so that no change is lost.
adjustservervariable "svPennyCompInfo",cr()+newInfo
In this case there is another advantage - if there is an error, the whole thing will fail, not a partial failure like you have experienced. So I would definitely recommend you switch to this technique.
For a detailed discussion of this statement and of atomic transactions, see this help page: