Whoa! Get this! After ruling out all the usual suspects, I did find something new (to me) that was causal.

Here's the scenario:

* A form's Data Environment has a mix of version 9.0 and version 2.6 .DBFs. (Gotta be this way for a while.)
* Three grids as 1 parent (version 9 DBFs) with 2 children (version 2.6 DBFs)
* Parent grid must allow/show deleted() records, children must *not* show deleted records.
* I had set the Child tables (version 2.6) in Data Environment as [alias].Filter="!DELETED()"

I removed the .Filter value and no more C5s! (Meanwhile, I'll create some other means of not displaying deleted() records in the children grids)

So, that's a new one (to me.)



>Ah.. Did you try to rebuild each index from scratch (not REINDEX)? Verify that the codepage for each table and each index is the same too.
>
>Anything funky in any index key? Calling a function, UDF, variable length keys, etc?
>
>Yes, you'll need a form, but you can put 3 grids into a single form.
>
>>Craig, if I endeavor to simply replace the BROWSEs with grids, will that require a form to place them on as well? I'm really trying not to recode/tweak much at all.
>>
>>Basically, here's the manner in which browses are used -- an incidentally, the cause of the C5.
>>
>>There a 3 browses: 1 of a 'parent' table with SET RELATION to two other 'child' tables that are displayed via BROWSE NOWAIT. The C5 is guaranteed to occur upon up/down cursor movement in the parent BROWSE.
>>
>>I've incorporated your suggestion and bucketlist of others. Things are fine if no related tables/browse are present. Once those are established.... C5!
>>
>>I'm seeing a re-write in my future. Haha
>>
>>>SET RESOURCE OFF still causes the resource file to be used/created. The only way to stop it is to put RESOURCE=OFF in Config.fpw. Don't know if that will help, but something else to try.
>>>
>>>Make sure the anti-virus is not scanning VFP files (dbf, fpt, cdx, etc)
>>>
>>>But, the problem with the BROWSE command is that it is potentially very destructive because it directly accesses the data with no buffering. I have seen high rates of corruption due to use of BROWSE. IMO, you should make a plan to replace BROWSE with a buffered grid (at a minimum). I strongly believe the grid is not a good data entry control.
>>>
>>>>Ack! Anyone had a similar experience?
>>>>
>>>>I've got an old FPW26 program that I now need to run using VFP9 SP2 runtime. Yeah baby, C0000005! And it is specifically happening on a BROWSE command. Every time.
>>>>
>>>>(XP SP3 here)
>>>>
>>>>I really don't want to tweak/re-write old fpw26 code in effort to circumvent this. I really want to see VFP9 work and not be brought to it's knees by a BROWSE command. Haha.
>>>>
>>>>Thanks for any input!
>>>>Steven-
>>>>P.S.
>>>>* I issue SET RESOURCE OFF as the 1st line of code executed.
>>>>* There are no Foxuser tables in the PRGs folder
>>>>* Happens when running PRG within VFP9 command window
>>>>* Happens when running PRG within VFP9 debugger
>>>>* Happens when running .APP within VFP9 window
>>>>* Happens when running .APP from a VFP9 "loader" .EXE
>>>>* Happens on each XP SP3 computer I've tried it on (3 for 3)