Craig

That's a pretty big table!

I'm sure you're right that design makes a huge difference to corruption. One of our biggest customers has had all its post discharge coding for funding data in VFP tables since 1995; millions of code records now, ? total database size. The only reason they're upsizing to SQL server is because we've said we don't want to support an "orphan" non-C/S version of that particular product. The product uses Database Views for everything, a habit that I'm sure has helped limit corruption.

It interfaces to the 3M encoder, by the way! < g >

When we do see corruption it is almost 100% user error or OS SNAFU. Eg: printing takes a long time because the OS is walking the entire WAN (wrongly set up) so the frustrated user flicks the computer off, corrupting partly flushed data in memory. Or Word freezes, flick. Or a room full of typists develops a habitual use of Task Manager to terminate our application- nobody is quite sure why, it is just sort of "what you do".

Recommendation: include a facility in all apps that if it terminates abnormally, users can't log back on till the sysop sets a flag. You'd be amazed what you discover.

Regards

JR