>I've mentioned this one many times. Don't use a procedure file. Make each procedure or function a seperate .PRG. Don't start each .PRG with PROCEDURE . That's just redundant and causes more performance problems. Sure you will end up with more entries in your project manager, and that might cause some performance problem using VSS, but I think the benefits outweigh the problems. While you are working, there might be a slight delay while VFP searches the directory for the file, but you will have ultimate flexability and when you finally make a .APP or .EXE the negligible performance problem will go away. Caching will also reduce this. Further, there is a performance hit just saying SET PROCEDURE TO. And there are performance hits with recompiling one large procedure file just so you can change a few lines of code. > >I've been doing it for years. I had to prove it to some VFP people once, but old habits die hard.
sounds like it makes sense - particularly for new apps, but this is a legacy upgrade and my procedure file has around 45000 lines in it and I haven't even counted how many procedures/functions it contains. I don't intend cutting and pasting that lot into standalone routines in a hurry! Aside from which, performance seems to be one of the few areas where I'm not currently experiencing problems!
