>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.....
>
Hi Don,

I'm not referring to the DLL business here. These things are likely to happen when making a conversion and relying on a generic converter to do the work. Unfortunately, many of us are put into a position where that's not a matter of choice, but a matter of necessity. So we make do with what we have. When you think about the level of complexity, combined with the big differences in things like variable scope that make doing the job extremely hard.

Fortunately, I had a choice. I could continue to maintain my existing FPW 2.6 applications, and build a new framework in VFP to port them to. Certainly, it's been a lengthy transition, however, one that's been highly worthwhile. It caused me to re-examine the FPW design and correct flaws in it, and take full advantage of the features offered in VFP.

Stick with VFP. Remember nothing on the desktop can touch it when it comes to data access and manipulation.