>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!

Hidy Rox,

Whether or not what I'm about write is the cause, it should contain enough "geek speak" to satisfy.

Reason 1: VFP is inherently faster than FPW (each running in the operating environment it was designed for; FPW in 16 bit, VFP in 32).

Reason 2: Since FPW is not native 32 bit, it additionally has to be processed through what's known as a "thunking layer" to be able to be processed. This additional step, causes it to slow down even more, causing the problem you've experienced. Since VFP doesn't go through this (and is faster anyway), the result is that the error goes away.

That's about as "geeky" as I can get. :-)