Database ID does not match the server

Several times, databases have given a message that the ID does not match the server, so it cannot be connected. I do not know the exact steps leading to this problem, but will try to note them the next time this occurs. The solution is to discard the local copy and download the database again.

Today a user received a ID-not-matching message while I was connected and watching. She closed the DB, then opened it again, and it did connect and worked properly. So it seems the message was received in error the first time.

The sharing system sets up an id for each database. Each time a database is opened, it checks to make sure the id on the client matches the id on the server. This is both a security measure and to prevent against accidental problems if two databases happened to have the same name. When the client opens a shared database to the server, it sends the id of the local database to the server, where it is checked against the server copy.

The database ID changes each time there is a new server generation. Looking at the code, I wonder if this is related to the problems you had with getting a new generation to load when a database opens. It’s in the same area of the code, and there is a comment in the code that mentions certain statements are for handling recovery if a user failed to complete the new generation process. So maybe these problems are related, or even the same problem. That would be nice from my point of view.

I’ve been toiling away with my project to add remote configurable logging. I can see that I was right to avoid it from the point of view that it has been a lot of work to implement. I’ve pretty much got it complete on the server side, now I am working on the client side. Now that I’ve got it partially working, I do wish I had invested the time to do this months ago. When I turn it on, it provides a huge amount of data and clearly will be very useful. But I still probably have a few more days to go to complete it. Hopefully we can catch this ID-not-matching problem in a log and immediately track it down. I am finding it fascinating to watch the operation of the server in realtime with all the logs turned on, it’s kind of like the old “Visible V-8” if you remember that.

In other news, we are now on day 5 of an internet outage here. Yesterday it became clear that there was no end in sight, so we switched to a different ISP. The new equipment is supposed to be delivered tomorrow. Meanwhile I am hobbling along using my iPad as a hotspot. Fortunately that is enough to run Xcode (and check email, etc.). Hopefully I’ll have full speed internet working again by the time I need to upload a beta new version.

Sounds like, regarding internet, you live in remote Afghanistan or something!

Yeah, that sucked. I stuck with DSL way to long. The cable has worked great for the last month, no outages and 10x the speed. Yeah!!

Gosh, that sounds so similar to the problem you reported yesterday, but with a different setting. The fact that re-opening it fixes the problem makes it sound like the problem is in reading the settings, rather than writing. Well, at least this gives me a pretty narrow area of code to look at, and maybe there really is one fix that will clear all of this up.