> Are each of your users using a "personal" Firebird database or are they all connecting to a centralised one?
>
> In the latter case, do you really want any user starting up the recovery utility and trashing the database for everyone else?

My natural tendency is to include more information than is necessary (ask my wife). Given that, my description was intentionally brief, obviously too brief.
The previous application used a single, common Access DB. That product has been commercially distributed for over 15 years, to offices that range in size from a single user to 20 or more. Some installations even use Terminal Services to access the DB from multiple remote offices that bring the number of simultaneous users to well over 20. You are correct in that Access is corruption prone, and it creates huge volumes of network traffic. These last two are my main motivation to switch to Firebird.

In the 15+ years we have used MS Access, we have had literally no issues with our wrapper of the MS Access Repair & Compact utility. It is just a simple matter to instruct the user to close all instances when an exclusive open of the DB fails. In a manner similar to Helen's recommendation, we assure a "free" database, and make a copy that we work with. By making a "smart" GUI, even the most IT-illiterate folks have had success repairing damaged databases.

> Equally, it's best to know exactly what the problem is before you attempt to recover the database - you don't want, for example, someone using the utility to restore yesterday's backup, when all that may be needed is a restart, or a sweep, for example.

In my mind, backup and restore is a different matter than doing a repair (via gfix). If I understand correctly, implementing a fix via backup and restore is only done if gfix is unable to effect a repair. This is where my lack of experience with Firebird shows.

>
> You have already said that your users have little or no IT experience - why on Earth do you wish to let them (all) suddenly become Database Administrators?

That is certainly not my intent. I wouldn't dream of turning them loose with command-line tools. My hope is to provide a user interface that would not permit them to cause damage. I have also found it valuable to distribute tools that I can use via remote access, that greatly reduces the time I spend on tech support. Again, My inexperience with Firebird is why I posed the question in the first place (I'm not new to IT, just Firebird).

>
> Remember, data is the most important possession a company can have, in an insurance company that data is probably even more important. There are probably laws in all/most countries requiring companies to protect personal (and other) data - so you really don't want IT "illiterate" users messing about in the database.

See my above comments about wrappers and "smart" interfaces.

>
> And finally, for now anyway, Helen's book is excellent, however, the chapter to which you refer doesn't cover all known database problems. I've had one where there was a message in the log that said something along the lines of "wrong page type detected, expected 8 found 0" - there are others.

Well, that frightens the heck out of me. I can only hope that this forum can help me overcome being a novice Firebirder.

> Your database *needs* a proper DBA.

I agree. I wish that were possible. Unfortunately, in an agent's office, the business owner is often the janitor, and the receptionist, and the window washer, and of course, the DBA. That's where I have learned to design very creative user interfaces.

> Just my £0.02 for a Monday morning.
>
> Good luck.

Thank you, Norman. I appreciate your comments. Every bit I get is a great help.

Cheers.