Subject | Re: End user repair utility - assuming the worst-case. |
---|---|
Author | homerjones1941 |
Post date | 2011-01-17T23:16:37Z |
> ... A properly setup Firebird database doesn't crash very often so you might not actually need a recovery utility (except restoring backups and once deleting two records from a system table when an index was 'partially deleted', I don't remember having fixed a Firebird database in the 12 years I've used Firebird). On the other hand, worst-case Firebird crashes cannot be fixed or require expert recovery - i.e. Ann Harrison, IBSurgeon or possibly IB Phoenix.Twelve years with no repairs is very encouraging, thank you. My experience with Access in my office is quite similar (15 years without corruption). However, my product is distributed to hundreds of insurance agent's offices. For some of them, data corruption is pretty frequent with MS Access. Unfortunately, I can't predict or control the kind of environment those offices maintain. Some people believe that Windows can be left open 24/7 and never restarted. Some even believe a wireless network is just as reliable as one that is wired, even when the building next door does arc welding. Other offices do things "right" and have never had corruption issues.
Done properly, Access is not as bad as some people say. The big deal is that without stored procedures, all queries are client-side. That creates a lot of network traffic which can get monstrous as the number of users increases. That being said, if Terminal Services is employed, the app runs on the server so the queries are performed on the server. This greatly minimizes network traffic, and therefore data corruption. I have some installations with well over 20 simultaneous users, and they don't have problems. Admittedly, they are exceptional.
> Maybe all you need is a one page description of how to shut down the database, rename the database file, restore a backup and bring the database back online? Users who know they are illiterate will normally be able to follow a clear description, the problem users are those who are illiterate optimists believing they are experts ("Yes, I know about your recipe, but if I got this to work on an Access database, it means it has to work on any database, if not the other database is in error!").You may have a good point. I would love to avoid writing yet another Delphi program just to protect end users from themselves. You are also, very correct about the "illiterate optimists" (I love that term). Those seem to be the people that even the smartest GUI can't protect.
Your comments about Firebird's corruption resistance is encouraging. I'll certainly consider your suggestion of a one page set of instructions. Now, if I can only get them to read? :-)
As an aside, three basic rules in my software design strategy is to 1: never do anything that will make my phone ring, 2: always do things in such an obvious way as to make it unnecessary for users to dial my phone (almost the same as 1, but not quite), and 3: automate as much as I can to avoid unnecessary user interaction. These three rules are what prompted me to consider making a repair utility, but from what you say, the lack of a repair utility may not make my phone ring enough to worry about.
Svein, thank you for taking the time to give me other ideas. Heaven know I can use all of them I can get.