>>>>>When behavior between VFP IDE and EXE that would suggest different settings to me. SET COLLATE, in particular, would be my first step to check because a) it causes different indexes to be used in the process and b) there have been a few bugs in the past in VFP where the binary conversion of just a few values was broken with another collate sequence than MACHINE.
>>>>>
>>>>>In this case, however, as the error is fully reproducible, I'd simply fire up Process Monitor from sysinternals.com and check what file VFP is looking for.
>>>>
>>>>So this gets really interesting. DBF("the view") is, not surprisingly, a TMP file, but what temp file it is changes regularly. I'm guessing that each time I requery, it may change files.
>>>>
>>>>The index file (testing using CDX()) starts out as the original file name with a CDX extension. But fairly late in the game (over an hour into this particular test), it suddenly changes to a temp file, and then seems to change on each (or most) requery() thereafter. The crash happens within seconds of that change, though dozens more records get processed before the failure.
>>>>
>>>>Definitely bolsters the theory that there's a problem with the index file and I'm now speculating that the problem is creating the index file.
>>>
>>>Yes - Requery() changes the name of the dbf()
>>>
>>>If not possible to get rid of the index - I'd try setting sys(3050) to a low value
>>>
>>>

>>>	=sys(3050,1, 64 * 1024 * 1024)
>>>	=sys(3050,2, 16 * 1024 * 1024)
>>>

>>
>>I'm just about through a test where I drop the tag before the Requery() and add it back after. Pretty sure I've already passed the crash point, so I think this is the solution.
>>
>>Tamar
>
>I'm not sure if this applies to your situation, but this reminded me of this comment in our commercial framework's code:
>

>		* Make sure all tags are created in the same CDX. REQUERYing causes the cursor name to change, which will
>		* cause tags created after a REQUERY to be created in a different CDX than existing tags if the "OF" clause
>		* is not used. This avoids error 1548 when the BEGIN TRANSACTION command is issued in the SaveRecord method.
>

>The code then goes on to check if there is an existing value for CDX(1), and if so, it is used in the "OF" clause of the INDEX command.

Very interesting. There's only one tag here, and no transactions, but that sure sounds like a similar situation.

Tamar