Filemaker project structure

[Johnn]

Hey,

I'm fairly new to Filemaker and have a few question which I hope you can clarify.

I have a Filemaker solution which I use for multiple customers. This solution exist of 2 files, a layout file and a database file. Everytime a new customer comes I copy the 2 files and clear the database so they can start fresh.  The problem i have with this method is that when I change something in one solution, I have to change it in all of them one by one. This takes way to many time.

My question is : What is the best approach for this ?

Is it possible to split up all "modules" to separate file? So I have a module (separate fm file) called Invoices, Contacts , Inventory etc... and set the database structure and  scripts in the separate file. 

This way I have 1 main file which is connected to all the "modules" and all customers have their own main file connected to the "modules", this way if I change a script or database in the "module" it is changed with all customers.

Is this even possible? or is there a better way to approach this?

 

I hope you can give me some more information.

[comment]

I am afraid your description is not clear enough. What does your solution actually do for your customers? Are you the one working with it, or do your customers operate it?

 

20 minutes ago, Johnn said:

This solution exist of 2 files, a layout file and a database file.

Not sure what is the point of that either.

 

--
P.S. Please update your profile to reflect your version and OS.

 

Edited July 20, 2017 by comment

[LaRetta]

Hi John, welcome to FMForums!

It is feasible to use two files, one called the UI (which holds all the layouts and scripts) and the second file holding the data itself.  Search here for 'Separation Model' for many discussions on it.  I suppose one could use different UI modules files (an Invoice UI, a Contacts UI etc) but that seems overkill since these modules must interact via scripting and jumping from one file to another adds complexity and cost.  All modules can reside in single UI file and be displayed for different customers according to whether they have rights.

Secondly, separating customers into different data files might be necessary but only if each Customer possesses their data file legally such as customers which are actually Cities or if the size of each City's data file is in the GB size. Normally, your customers would reside in the same data tables but each record would be designated with different CustomerIDs and you would use a Customer table to hold their information.  You haven't yet indicated your FM version.  If 16, a new feature is the ability to specify the external file reference via global variable which adds great flexibility

The added bonus of separate UI is ease of design because changes can be made independently on the UI and then you simply replace the served UI.  Of course if you add fields, you'll need to track those changes and be meticulous in making those changes in same sequence in the data file but most work, after a solution is functioning, are layout/script based.

As Comment asks, it would help to have more information on your set-up and your relationship to these 'customers.'