Arrgghh, a DP department that doesn't know how a database works, just advise them that no further works will be done until an Order Number is supplied.
It is blindingly obvious that there is an outside process at work here, you aren't doing low level writes to the app files, are you.
If they won't supply an order, just advise the client not to call, i.e. give them the flick. Some clients aren't worth the hassle.

Hope this helps.

>As mentioned previously, the problem was eventually traced to program files somehow getting damaged. The software would work fine immediately after installation. If we exit the software, then wait 3~4 hours before running the program again, the program would abort in various places. If we re-copy various program files (the ones I suspected as being damaged -- basically the modules that correspond to the section of the code being executed when the crash occurs), everything would work fine -- until another 3~4 hours later when some other random part of the program would get damaged (and obviously we wouldn't know about it until we try to run some operation).
>
>I have indeed suggested that they check to see if there was anything like data compression being performed on "idle" files, or if there was some sort of antivirus software that was being used. Each time they would respond by showing me "proof" of the problem -- one or more DBFs would grow in size whenever various operations were performed. Each time I'd have to explain that this was normal -- especially after adding data. One of the files they would always point to was the audit trail, and repeatedly I'd have to explain that this file is indeed normal to grow -- it's keeping track of operations being performed within the system. Each time I'd also have to remind them that if these files were indeed the cause of the problem, not reverting the files should've caused the problem to occur again.