>>Attempting to compile the latest change and build a new .EXE, I received Error 1202: Program is too large. Help says there is a 65K limit on single procedure or program, but provides no way to identify which file.
>>
>>The previous build of the executable did not throw the error, despite the .EXE being 23 MB. and ADIR() showing half a dozen .PRGs and two .FXPs over 65K.
>>
>>The most likely culprit was split into two files, but the error persists. VFP 9 is available in development but cannot be used for deployment yet. I'm attempting to use this as a push to move to VFP 9, but for now, I need a VFP 6 solution to the problem.
>>
>>Chris.
>
>Hi Chris
>
>You must have made changes since the last exe to a set of programs. Those are the ones to look at first. If you use source control, you can find all recent changes. If you're not using source control... look into it. :)
>
>I know you can handle this in VFP 9 by setting PROGCACHE, but I would advise you to break the habits that led you to this point first.
>
>I've been advocating not using any procedure libraries for a long time. I recommend you stop doing ...
>
>You probably already SET PATH to find the proclib.prg. Although you might also be hard-coding the path into your program. That's not a good plan.
>

Preaching to the choir. It's an inherited codebase I'm trying to drag into the modern era. I previous posted here about source control - specifically finding the best source to control when previous versions are VB-inherited between directories with no coherent naming system.

I finally managed to hack things into enough pieces to avoid the error. What I don't understand is how it ever compiled previously...

Chris.