>I have to answer one of those "But Why???" questions with something other than "Who cares Why it happened, it's fixed now" :)
>
>I have FPW2.6 batch routines that run on my NT4.0 database server at night. These routines mostly handle feeding text files from legacy systems into dbf's, and re-create indexes for optimizing my reporting app that runs during normal business hours. The network guys recently brought it to my attention that the regularly scheduled backups (Backup Exec product) on this server never run on time. They also said the logs showed that the backups get delayed/canceled "because of an extended wait state in another application".
>
>I did some testing and sure enough, when my 2.6 batch routine is running APPEND FROM ... TYPE DELI and feeding in a textfile with 100,000+ lines, this Extended Wait State error gets logged. Not always, but 6 out of 15 tests gave error. I recompiled the code in VFP5.0a and the error went away.
>
>Because we still run alot of production FPW2.6 code on this same server, the boss wants a better answer as to "Why" this happened. (I already tried "Gremlins" but it didnt work ;)) I called tech support for Backup Exec and they basically said it wasn't a problem with their software so they didnt care. Any ideas or GeekSpeak on the differences between 16-bit and 32-bit code that might help me put this little glitch behind me? TIA!


In addition to what George said, you may want to make sure each 16-bit app runs in its own memory space.

There is a difference in how 16 bit and 32 bit apps are run. It has to so with the way they multi-task. A 16-bit app has to tell the processor that it is done running the current thread and another 16-bit app can use the CPU now. Under NT, the OS gives the 16-bit app a time slice so that 16 and 32 bit apps can multi-task. With a 32 bit app, the thread gets only as much time given it.
I don't know if this has anything to do with your problem, but it sounds geeky.