I’ve had the luxury of starting with FM7 and therefore have done everything in one file and not really known any different.

Now I’m upgrading some existing FM6 solutions that are anywhere from 10 to 30 separate files.

I’m wondering if there is any logic to keeping some of the files separate, so that I can begin to build a master template for each key area, which should be able to be added or removed 'easily' , depending on future needs and re-purposing for new clients.

The other idea I had was to keep everything in one file, and simple not reference Table Occurrence that are not required for new clients.

The final idea was to move to a separation model, to allow what seems to be complete freedom for upgrading and customising, although with the highest overhead of data living in a separate file to the interface.

I do understand that ‘separation model’ threads are in a different part of the forums . . .

mav.

It's a bit of a "six or two threes" really.

I've been in FMP for 10 years from v2 and recently upgraded a 24 files system from v5 to v8.

For the purposes of economy for the client I kept all the files as they were and allowed FM7 to do all the work. I fixed the files references and some scripts and a couple of minor tweaks and it all worked. Had I gone for a single file approach my bill would easily have been 10 times what I charged as the solution had many scripts and layouts which would have needed re-creating adn as I did not create the original system I would have struggled severely with the logic in the scripts and fields

There's still nothing wrong with separate files (except for the scope of scripts) and should one file need repairing it could be done without stopping the whole system. Modular solutions become more obvious with separate files too - but it's "horses for courses" ultimately.

I’m wondering if there is any logic to keeping some of the files separate, so that I can begin to build a master template for each key area, which should be able to be added or removed 'easily' , depending on future needs and re-purposing for new clients.

There are trade-offs between single file vs. many files. For a large solution, I think grouping tables into modules is a good compromise. You can check this thread for more details:

http://fmforums.com/forum/showtopic.php?tid/169045/