Pardon my ignorance here, but i just can't seem to grasp the whole mutliple file vs. one file concept. I have a purchased multiple file application in 6, but it's too complex for my needs (advertising agency, job tracking, time and expense billing) so I was hoping to use some of the available solutions from FM and modify them. But that would mean having multiple files instead of one, which I have been led to believe is the real beauty of 7. From an "expert" standpoint, is it still "OK" to have multiple files? Or should I attempt to cut and past the tables from each file into one large file? I can have relationships between different files? But do those files have to be open in order to work, so I still have to have several files open when working?

It's not because FM can now have multiple tables in one file that all solutions from now on must be one file. There are different things to keep in mind:

- performance

- update-ability

- security

- web-enabling/xDBC access

In general it's too early for best practices on this. One neat thing about FM7: there is no longer a 50-file limit of files FMP can have open. So even if your solution consisted of 60 files it would work in 7 (hard to do in 6).

FM will automatically open all files it need to have open (because of relationships etc)

You should check out the migration tech briefs on FMI's website:

http://www.filemaker.com/upgrade/techbriefs.html

The FM7 Migration Foundations and Methodologies paper lays out different strategies for migration, and discusses many issues to look out for.

My personal choices for migrating our large system has been to clean up, then convert our existing files, then consolodate using the hub and spoke idea. This involves moving supporting files into the file that is the primary interface for each module. The exception to this is those supporting files that are purged each year, and those that hold large static data sets, that don't require frequent backups.

If your databases are tightly intertwined, it may be difficult to combine files into one. In this case, you might be better off rewriting from scratch or building a new Interface file that uses the existing files as its sources.

It's perfectly OK to use multiple files; it's just that now you have other options, i.e. all in one, all separate, or some of each. Managing relationships beween files is much improved, since you can now easily modify, add or delete file references, and then use that file reference as needed (instead of always locating the actual file e.g. when you need to use it in a script). Do the files have to be open in order to work? Yes. Also, your computer has to be on.

I love the fact that you have all your tables in one file. great

The only worry I've had though is when comparing it to multi files.

Before, if one file in a relationship database corrupted, it didn't also seize the data in the other files. But now, if you have all your tables in one file and that file corrupts, that's everything right? You just have to rely on your backups - but no way of retrieving a table's worth of data from one file - all or nothing.

Tom said ... Also, your computer has to be on.

Ahhh Tom! That's where I've been messing up! I just wrote down "Computer ON." That's not in the FM manual or help.

The only thing I have against multiple files is the dread of having to add someone new - to EVERY file. It's too bad privilege sets and accounts can't be connected in some way or copy/transferred. Am I the only one that struggles with this? Or are there other ways to handle it? Each employee is an Account and I have rather complex extended privileges and lockdowns which need to effect every file.

Thanks for the interesting post everyone!

LaRetta

Check out this example file. It's not that hard to script. And it's fast, a split second to create an account in every file. Obviously Privilege Sets have to be created in each file, since they are file-specific. But once that's done, accounts are easy.

http://www.fmforums.com/threads/download.php?Number=112911

Wow. Thank you Fenton. This will same time!

Matt stated ... but no way of retrieving a table's worth of data from one file

You can always export just the data from one table - if recover lets you open it at all.

I realize the thought of everything in one file is concerning but, in reality, I feel it's an overinflated concern. If data corrupts in one table, I wouldn't want to pull or trust it's related data either. I back up every 15 minutes. Always have.

LaRetta