Bob, lRet was .NULL. before the SEEK() - it was a local variable without a value assigned. The easiest workaround here is to just assign it a .F. value so if the SEEK isn't completed the program acts like the data wasn't found. The problem is the sheer volume of SEEK()s in the code :-((

And yes, the program continues after the uncompleted SEEK() - it's the code

if lRet....

that gives the error.

Thanks,
Barbara

>OK, you've got me worried. I can't think of any way to produce what you have seen.
>
>If lRet had a value other than .NULL. before the seek(), then seek() is returning a .NULL. If lRet was .NULL. before your seek, then, either there was no return value, seek() returned a .NULL., or seek() is still busy seeking and hasn't returned anything YET (does your program continue past the seek() when the problem occurs).
>
>In any case the impossible is happening. This class of problem (the ones that can't happen) are generally solved by turning your machine off and on again. What this technique solves, of course, is memory corruption. The only thing I know of that will do this is a program built in say VFP 5.0a SP3 being sent to a user just as an exe where the original setup on their machine was done with an earlier version (VFP 5.0a without the Service Pack 3 upgrade). If the problem's happening on your own machine, you can throw this idea out.
>
>To summarize, I don't know.
>
>Good luck, maybe something above will turn a light on.
>
>Bob