Jos-

Yes, it is easy enough to track. There is nothing complex about the code this occurs in. We are using VFP7 SP1 for development and clients either use VFP7 SP1 or VFP7 runtime files and SP1. In all cases this occurred with VFP 6 code recompiled in VFP7. The VFP 6 code ran without incident.
I wondered if anyone else was experiencing this.

Example 1:
Local l_csubject
if !used("table1")
use table1 in 0
endif
select * from table2 into cursor csamples readwrite
l_csubject= .t.
** C0000005
** Adding l_csubject=.f. under the local l_csubject line fixed the problem.
** that makes no sense since it should already be .f.


Example 2:
** if lazily using the following approach:
xyz="my name"
** C0000005 (this does not occur consistently)
** adding xyz="" before xyz="my name" consistently fixes this problem.




>Eleanor, can you narrow down the line(s) of code which causes the error? By using a series of wait's (or other techniques) can you find the line and post it here with some more info iro the environment?
>
>>We are seeing C0000005 errors in VFP7 on a too frequent basis.
>>
>>The errors, including C000005, are appearing in applications now running in VFP7 that ran like a champ in VFP6 (VFP6 projects recompiled in VFP7). They are also occuring in applications built from ground up in VFP7.
>>
>>The operating systems are Win98, NT, 2000.
>>
>>Most problems, so far, seem related to using a variable without first initializing it. In some cases the variable was declared local and in others it was not declared at all. FoxPro always supported these bad habits in the past.
>>
>>Is anyone else noticing this?