Hi, Have you guys found a solution to Disp Stat in the error routine for the files that are open in private (to forms) sessions? TIA, Marc We use pretty much the same approach. The procedure stores relevant info to a table record, including the call stack as far back as 5 levels. That gives us an idea about the flow of the execution when the error occured, which seems to be very useful in the new OO environment. Plans are to make it even more sensitive to the context, i. e. prompt the user for a data maintenance when the error referrs to an index problem like "record out of range" on ordered tables., or ignore other "innocent" errors. A feature(?) of our error trapping routine is that it always RETURNs TO MASTER where the application is initialized, and it doesn't cancel the program. That makes it less frustrating for the user. >I was curious what types of error trapping routines everyone uses. Trapping errors properly can be incredibly useful not only in developing your apps, but in maintaining them once they are in the field. > >For example, the e-trapping in my apps captures all relevant info about the error, message, module, line number and even environment settings and adds it to an error table. While developing this is a great tool for determining where and how your programs are misbehaving without having to write down the errors as they are happening. You can test all facets of your app and then look at the errors (and you know there will be some) en masse. This will save both time and effort. > >In addition, this type of e-trapping will allow you to better maintain your app in the field. I'm sure we've all had a client call us up and tell us that our supposedly bullet-proof app suddenly grew horns and begain spewing profanity at them. Normally, we could only scratch our heads and inquire as to the type of medication the client is on, but with the proper e-trapping we can just open up our error table and find out what, when and exactly how the error occured.