1 of 1 people found this helpful
Mostly all files are done in a single format ever since .fp7 was introduced.
The main reason to have two files now is to use the data separation model, where your data is stored in one file, and your interface to interact with that in another file. That gives you the advantage of being able to roll out interface "versions" without having to disturb the data file. There are other advantages and disadvantages too.
For the above specs though, I'd definitely keep it simple and stick to one file. Although when you say:
"There will be 3-5 people using the system as shared files"
How exactly are you sharing it? a 5-pack AFLT license would be best so you get FM Server to host it. You definitely do NOT want multiple people opening filemaker files at the same time straight from a drive.
1 of 1 people found this helpful
The other advantage to having multiple files is more applicable to larger systems. It allows you to organize your system into modules and this can make updating a portion of your system a bit easier.
On the downside, every individual file has it's own set of account names, passwords and privilege sets. You should password protect access to your solution and keeping matching accounts on all files so that the users don't have to keep entering a password each time the system opens another file in the background is an added chore that you won't have with a single file. If you do choose to use multiple files, try using external authentication to make the job a bit easier.
I have multiple copies of Filemaker Pro 15 for the users. I wasnt planning on hosting it on FM Server. Should I?
I'm a neophyte on FMP and am trying to keep it as simple as possible. I'm not an IT guy or developer so if there are problems, the simpler the system, the better for me.
Thank You philmodjunk! You are a wealth of information!
Is the FM documentation a good source to learn about accounts, pswds and privilege sets - or can you recommend some 3rd party training? Obviously, I have much to learn.
The supplied documentation can be a good place to start, but if you find it heavy going, then start searching for training materials on the topic.
in general, we create as many modules are necessary - but as little as possible..
If there are more developers, it's easier because each one can concentrate on one module (not two can be in the structure, not two can work on the same layout, etc.)
Modules can be handy in many ways. Scripts can 'talk' to foreign script by using multi-parameters, etc. Drawback is the user-roles/accounts
For small solutions, we prefer single file systems
Hello, I always use solutions to several files, from 2 to 10.
At least 2 because I sell FileMaker solutions in general to several customers (or I wish).
So I have to separate the user data from the data management interface. It allows you to have, for example, menus, parameters, specific languages per user without having to question the data, only the application is concerned. I can modify the application without disrupting my clients.
I do one to two updates a year.
Recovering data files also allows me to outsource processing for multiple clients by simply retrieving data at a specific time.
Some other reasons to split a solution in multiple files:
- use a file to store just the container fields (sort of variation of the data separation model), especially if you want to use the remote container feature. This makes updates to the rest of the solution a lot easier, not having to worry about the container data
- split the static data tables (especially if they are big) off into their file. This helps enormously with backup performance and backup disk space requirements because of the way FMS uses hard-linking for its backups.
Thank you all very much. I believe I'll combine to a single file. Off to learn about de-cluttering the relationships window! Thanks Again
ExecuteSQL can be one tool to use to reduce the number of needed "boxes" in your relationship graph. It can also slow performance if used incorrectly so I suggest that you study up on the function and then test carefully with realistic numbers of records in your tables after implementing any such change.