Hi George,

I get this when developing and specifically heavy debugging during which I've killed the app for whatever reasons. In time, VFP will generally give me the error message to which you get about not enough memory. I'm sure that when abnormally exiting many times, that between Windows and VFP, memory cleanup stinks so eventually, it runs out. This is of course only a guesstimate of what is happening but it does correct itself when I reboot. Also, this is more prone to happen on my celeron machine as opposed to my PII.

steve


>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?