The corruption mentioned in 258734 happens when the sum of the sizes of any SQL pass through cursor exceeds the data buffer size, either the SYS(3050,1) size when the VFP app is in the foreground, or SYS(3050,2) size when the VFP app is in the background. It is the point where the overflow occurs, and the remainder must be written to a temp file on disk, that the corruption actually occurs. Setting the SYS(3050) values lower will hasten the onset of the corruption.

258734 indeed contradicts 136694. If you wish to avoid the behavior in 258734, and your SPT cursors are large, you are better off using virtual memory rather than exceeding the buffer size and encountering the corruption. This will use the Windows swap file, but will allow larger VFP buffer sizes, so the data is not written to VFP temp files.

You should also set SYS(3050,1) and SYS(3050,2) the same so you don't flush data to buffers when you alt+tab away from your app. (By default, the forground buffers are 4x the size of the background buffers, so when you alt-tab away, the background figure is used).

If the sum of the sizes of any SPT cursors you may have open at a given time isn't too large, you should be able to avoid the problem by setting SYS(3050,1) and SYS(3050,2) large and equal. If the sum of the sizes of any open SPT cursors exceeds the buffer size even at the largest buffer sizes (i.e. SYS(1001)), there's not much you can do except limiting the total size of all open cursors below the threshold of available buffer size.

If you wish to avoid this entirely, I would recommend you use VFP7 or VFP8, where you don't have to worry about it.

For additional information, you could open up a support incident with our tech support team and we can look into your particular situation further.

>
>Sorry about posting this twice - I wanted to make sure you saw this Jim.
>
>In a KB article 136694 about memory management in VFP, it says that 'it is critical that the [page pool] memory be physical, not virtual'. The 258734 article says to set SYS(3050) to SYS(1001). If SYS(1001) returns the amount of virtual memory available, it seems that setting SYS(3050) (the page pool) to SYS(1001) (the amount of virtual memory) would be counter to the advice in KB136694. Am I missing something?
>
>Also, I saw another message from you (ID 558694) about SYS(3050), where you said that setting the buffer size to the 256KB minimum would force 'any data which exceeds the buffer size to be written to disk in either tables or temp files'. So, I thought that doing SYS(3050, 1, 262144) and SYS(3050, 2, 262144) in the bigcur.prg would force the cursor to be written to disk immediately, and thus make the CHR(0) problem go away. But, it didn't. Can you help me understand why that didn't work?
>
>I'm really nervous about changing the SYS(3050) setting in my app.
>
>Thanks for your patience,