>Hi Fred,
>
>Me again!
>
>Here is the reply from Christof Lange on Compuserve to a simailar question.
>
> >>I get an error in VFP-SP3, but it works fine in VFP without SP3 installed.
> Further investigation reveals that SP3 seems to impose a limit of 8192
> Anyone else noticed this?<<
>
> They fixed the C5 GPF problem with FGETS() when using a value larger than
> 256. In order to fix that problem they had to reduce the maximum number of
> bytes to 8KB.
>
>
>>Anybody know why VFP6 with SP3 changes the maximum # of bytes that can be read using FGETS?
>>
>>Before SP3, you could have FGETS(fh,65000) with no problem, but now it crashes with anything larger than 8192. The reason I ask is because the SCCTEXT.PRG used by SourceSafe has the 65000 # and crashes (if you've modified it to be able to create .VCX's from .VCA files).

Thanks for the info on the change. It just seems strange because I never had it GPF with the larger number before, at least not directly so you could tell that was the cause. But I've had FoxPoo suffer with what I call "the poison dart" syndrome. An error some place in the code would screw something up, and FoxPro would stagger around for awhile, before falling over in some other totally unrelated piece of code. I'd usually spend hours looking at the code where it crashed, even though that really had absolutely nothing to do with the problem!

This change did have a negative impact on me though. I had changed the SCCTEXT.PRG to be able to create VCX's from VCA's, and whenever you'd check a VCX back into SourceSafe, it would try to re-create the VCX from the VCA file. Except now SCCTEXT would just error out, but your VCX was now trashed! Lost a couple of them before that one was figured out. Thank you very much, Microsoft, for not even mentioning such a change! Anyways, there are four (4) places in SCCTEXT.PRG that should be changed to reflect this new upper limit on FGETS, FWIW.