>Bugs in the product are just there and there is not much we can do other than avoid the known ones. This is a known bug (or not really a bug - it's vis maior) and this is the way to get around it, works for me. >When it comes to error handlers, my philosophy is that an error is an unexpec te >d situation, that is the program reached a condition that the programmer did no >t anticipate ahead of time. The only thing and error handler should do is re co >rd the error and attempt to safely shut down the system. Attempting to fix t hi >ngs while in an error condition is asking for trouble, and creating variable th >at the error handler passes back to teh calling code is also asking for troub le >. Generally spoken, you're right. In this particular situation, I catch just three or four error codes which denote the situation that an index is bad, a table is bad or a .fpt file is bad. The possible reasons for this are simply (in)advertent reset, power out, some other thing blocked the server, network cable pulled away by a passing truck, or something of the kind (95% of the cases). This is checked by the OpenIt() routine's private error handler (no global handler in this situation) and it's all just in order to make sure tables got opened; this way any routine that needs some tables to be opened doesn't need to do any checking for itself - it either gets the tables open, or the app goes into servicing mode and restarts after that. >The index was supposed to be there right, and it wasn't there right, so why w as >n;t it there and what else is also wrong for the same reason. Shutting down im >mediately and getting a support call will allow yo to diagnose and fix the ca us >e of the problem and not the symptom. The next thing which would happen in this case is that the support would tell them to run the indexing routine - which just happens automatically as it is now. This solves some 95% of these cases, and, believe me, we get only two such calls a year (and I wouldn't like to write horror stories on the impossible installations some machines here are supplied from; in one of the worst, it was "quite a good installation - the house has burned, and yet we never had to change any wires" - and it went dark if I turned the printer on _after_ the computer ;). For all the other cases, the users will get a chance to print the error log, fax it to us, get us on the phone while the error alert is still on screen (which goes into some lengths and usually covers half page), and finally, the error log will be there on the disk next time we visit them.