A user today reported that she cannot successfully open a database, and get the message “Database ID does not Match”. She does not recall doing an update. She has not used the database “in a while”, so I am fairly sure, without verifying, that she has skipped some updates. I replaced her database with an up-do-date copy.
What can we do to avoid that message? Does skipping an update cause a problem?
[We have seen this message before, but not done any investigation of the issue then.]
No.
When you first upload a database to the server, an ID is generated and saved with both the client and the server. The ID always stays with the database, generation after generation.
The only time the ID should ever change would be if the database was converted back to single user, then converted back to shared and re-uploaded. At that point it would get a new ID, and all users would have to manually download it again as if it were a newly shared database. If a user had kept a copy of the old message, they would (correctly) get this error message. Since you didn’t mention converting to single user and back to sharing, I assume you haven’t done that.
Many of your reports seem to indicate that Panorama is losing or corrupting meta data associated with the database. This is really alarming to me, as keeping track of this meta data is very simple code where I would not expect problems. This is a big factor in my motivation in creating the instrumentation system I am working on, as it will allow us to keep a “breadcrumb” showing what is going on with this internal meta data.
In this case, I think you explain is the most likely one: the user had not opened the database since I converted to single user and uploaded a new database. But I will be more careful about tracking that. In this case, the database correctly updated another client.
A related question: when I get a share download link from the Server Administration database, is that link just plain text, or is the ID or some other information embedded in the link? So that could be why old links may not work?
That’s a relief!
In the future, don’t convert to single user and upload a new database if you want users that already have the database to be able to automatically update. Instead, use the new generation feature. On the other hand, sometimes you might want to break the update chain, for example if someone gets their hands on a client copy of the database that you don’t want to have it. In that case, you can convert to single user and upload a new copy, and that person won’t be able to connect to the server any more. Of course everyone else will have to manually download the file again – there’s no free lunch!
It’s just plain text. You can paste it into a text editor and see that it simply contains the name of the server and the name of the database – that’s it. (These values are URL encoded, so spaces become %20, as in any URL.)
There is no reason why a link would stop working unless the database is removed from the server, or the name of the server changed (or the server was turned off).