Hi George,
We had a VFP5 EXE where the error information showed on a screen where users could add their own comments or read it to a programmer over the phone. We found it to be wrong about 25% of the time, most of the time when a PRG was being run.

Part of the problem turned out to be that one of our 'compile all' runs had been done without the line #s by mistake. These were returned, but some files had them in the compiled version and others didn't.

A lot of this went away with a "compile all" (sorry, but I'm suggesting it also).

Barbara



>Hiya Troops,
>
>I hope I'm not being a total dope on this one, but I've never seen it before. I was doing my usual morning checkup on my apps making sure that there weren't any errors floating around that I could address. At one facility I noticed that the error table had been generated, so I moved it from its location (it's automatically generated if it doesn't exist) and had a look.
>
>First, this is a full blown, properly installed executable.
>
>Here's the error number: 2005
>
>Here's what the help file says about 2005: Error with "name" - "property": "error" (Error 2005)
>You have attempted to set a property to an illegal value through the language.
>
>Here's what the error message, according to the error file, is: Error loading file - record number 3. Effrpt1 .Loading form or the data environment : There is not enough memory to complete this operation.
>
>Say what?? The only thing that makes sense is the last line. And why doesn't the error number and the message coincide?
>
>Now here's the line, according to the error that generated this error:
>
>DO c:\vfplocal\eff_rpts.exe
>
>Huh??? There's no line like this in the code. The exe is launched from a VBScript file via the WScript.Shell object's Run method. Further the line number is shown as zero and the error handler isn't even set until line 22 and the form not until line 47.
>
>After doing some figuring, the real line that caused this was a simple:
>
>DO FORM SDI_Rpts.scx WITH lcprocess NAME oMain LINKED
>
>I can understand part of the error message having to do with the memory. I can also (barely) understand why it reference record 3 in the message in a compiled application. What I can't understand is why the error information is so screwy. Especially that part about DO...
>
>It occurred to me that, maybe somebody futzed with the configuration file, and added a COMMAND= line to execute the program. I've pretty much discounted this. First, it isn't named config.fpw. Second, they'd have to know something about programming in Fox. Third, this is a single instance application and if the config tried to launch another instance it wouldn't even get to the line in the code I figured created the error.
>
>Anyone else seen something similar? Think I should just chalk it up as an anamoly?