Unfortunately, I've reached the same conclusion that you have - VFP's internal memory management is screwed up. We've been seeing other symptoms that also sound like memory is screwed up. We'll get random GPFs sometimes. I've gotten a "Data Type Mismatch" error; when I DISPLAY MEMORY of the array in question, most of the array looks fine, but the element referenced shows no data type nor any value.

As I mentioned early in the chain, this is a VFP app that was a strict 2.6 port - no objects, methods, etc. All of the screens are still there (DO xxx.spr) - no forms, CREATEOBJECTS, etc. The whole notion of VFP's emulation of the 2.6 READ functionality has me scared. (One time I got an error complaining about "Thisform.somethingorother" - interesting, because I don't have any forms at all).

Maybe I can get the client to switch to Dartmouth Basic.....

Don



>Hi Donald,
>
>Obviously, I don't think there was a CLEAR DLLS issued, otherwise you wouldn't see the reference with the DISPLAY STATUS. However, it could be that VFP's internal memory management may have (somehow) messed the reference up. About all I can suggest is that the functions be DECLAREd only as needed. From what I understand, there isn't a great deal of additional overhead that'll be incurred from the duplication when it happens. This will also guard against another method CLEARing the DLLS.
>
>FWIW, my own general design when working with DLLs is to DECLARE as needed when the object persists throughout the app's session. If the object is only to be used in a particular method that's not subject to any external clearing (short-lived), then I'll declare the functions in the Init method.
>
>hth,