I'm surprised you could even build an app with a file size of over 2 gig. My understanding is that this is a hard limit imposed by the OS, and that it wasn't even possible to have a file size greater than 2 gig. SQL Server handles this by splitting up physical files when they get too large.
>Barbara,
>
> Thanks for your response. I did mention in my original post that I had tried to adjust memory buffer using sys(3050) function without success. In fact, I used very similar code to Steve's, (but without the #DEFINE's) at 80, 50 and 20% of memory. Nothing worked.
>
>It turns out that error message had nothing to do with the buffer size, rather it had to do with size of the resulting .app file. I trimmed tags from the CDX until the tables and cdx were just under the 2GB limit and successfully built an .app file of 1.98GB.
>
>The real problem for me was the almost doubling of the CDX files that resulted from the 7.0 SP1. This pushed the app from 1.6GB to over 2GB. If anybody has a way of shrinking the CDX back to pre SP1 size, please let me know!!! My experiments to date have only resulting in an even larger CDX.
>
>I don't know how this will impact your GLGDW presentation, but at least you can eliminate this as a problem that SYS(3050) can solve.
>
>
>>I don't believe this problem is related to app size. Steve Dingle also ran into this problem and was able to solve it using sys(3050). He thinks it's actually a problem with too much memory. I'm including this topic in my GLGDW presentation, so if you learn anything new about it, I'd appreciate it if you let me know. Here's the code Steve used to solve his problem:
>>
>>#DEFINE diMEM_MAX_FOREGRD 256
>>#DEFINE diMEM_FOREGRD_PRECENT .80
>> LOCAL liNewMemory,;
>> liAvailableMemory
>>
>> m.liAvailableMemory = ( VAL( SYS(1001) ) / 4 ) / (1024^2)
>>
>> m.liNewMemory = INT( m.liAvailableMemory * diMEM_FOREGRD_PRECENT )
>> IF m.liNewMemory > diMEM_MAX_FOREGRD
>> m.liNewMemory = diMEM_MAX_FOREGRD
>> ENDIF
>>
>> m.liNewMemory = m.liNewMemory * (1024^2)
>> =SYS(3050, 1, m.liNewMemory )
>>
>>Steve also suggested having a INI file setting to override whether or not you set Sys(3050) since it can really mess up the app if it's got a bad setting.
>>
>>In addition, here's some info from Christof Lange which describes what's going on:
>>
>>----------------------------------------
>>SYS(3050) specifies the maximum amount of memory VFP tries to allocate for caching. This memory is not allocated right away, therefore a (little) bigger value doesn't do any harm. There's no way to find the optimium, because that varies with the amount of physical memory available. However, if SYS(3050) is too low, VFP might start creating TMP files on disk, even though there's still enough physical memory avialable. If it's too high, Windows only offers paged memory resulting in swapping operations. Which of the two is better depends on the speed of the disks where temporary files and the swap file are located (they can be on different ones).
>>
>>The other issue is that anything that has been loaded into the cache, has to be unloaded, as well. Even though unloading is much faster than loading the cache, it still takes some time. The cache is unloaded when you deactivate the VFP application and the background SYS(3050) cache is significantly smaller than the foreground cache.
>>
>>As you know, there's an upper limit for SYS(3050) which is most noticable with 1 GB or more of RAM. I guess that this problem is caused by the automatic determination of the buffer size. It seems that SYS(3050) is doing a file mapping which requieres non-fragmented virtual memory and is limited to 2 GB for all file mappings in a process. If memory is already fragmented and/or more memory is allocated for other means, Windows might not have enough memory to create a filemapping of the calculated size or it takes away all space for further file mappings. It looks like it is changing the filemapping at runtime, so resizing a filemapping might cause the same problem.
>>-----------------------------------------------------
