Yeah, I know that string vars can hold more than 16 MiB (I've FILETOSTRed a file of 64 MiB), but the majority of string functions can't work with greater sizes.

The Scripting object is very useful for large files, but when dealing with files < 2 GiB I prefer to use VFP native funcs, because from time to time Scripting throw OLE errors from VFP



>Fernando,
>
>>While doing a low-level routine for copying data between files for showing advance, I've descovered something interesting:
>>Documentation says that FREAD support 65536 bytes (64 KiB) max.length, but the limit in VFP 9 is really 16777184 bytes (16 MiB), iow, 256 more times!
>>And another interesting thing is that this limit is the same of the max.size of a string variable:
>>Maximum # of characters per character string or memory variable. 16,777,184
>
>Some functions in vfp work on even longer strings - but keeping strings below the documented 16MB length typically makes sense not only from security, but build/copy performance, which degrades as vfp memory handling/garbage collection will be more tasked by the loooong strings if they are concatenated.
>
>Speaking of performance: Scripting host, implemented for some tasks as a vfp biz object with an LLFF-like method interface for use cases needing to read/write files beyond the 2GB barrier often showed better performance when handling large data chunks (mostly when writing out) - so often that we use them quite often even on files not in the 2GB range. As we defined the methods as a copy of the LLFF signatures (and have a txtWriter base class implementing in LLFF for seamless switching between both access types) switching our old code was done on a morning when I was very clear headed just with cautios search&replace. Worked fine ;-)
>
>YMMV, but as you probably have lots of copy operations a thing to keep in the back of your mind ;-)
>With an object creation able to fall back to LLFF object it is easy to guarantee basic functionality even on machines NOT allowing access to scripting object, so your code does not incur more technical debt/runtime configuration specifics.
>
>regards
>
>thomas