FileMaker doesn't distinguish whether or not related tables are from the same file or not. Of course you already know about external file references. If you have plans to expand the functionality of your system it could make sense to consolidate to one file. Having one relationship graph and having all scripts in the same file come to mind. Having the Advanced version makes this easier to accomplish. However, if there's no real reason to do it I wouldn't bother. You're not likely to achieve speed gains for example.
Import records with the new table option for the target table can pull an entire table into your database from another file. Additional table occurrences and any relationships have to be manually recreated.
Scripts may be imported from one file into another via Manage | Scripts.
Layout objects an be copied/pasted all in one big group, though the layout parts and their sizes have to be set first and the layout's table occurrence name should be identical to that specified for the original table and table occurrences can be renamed temporarily to get that name match. The fields and names of the target layout's table also have to match exactly or there is addiitonal manual fixes that have to be employed.
But great attention to detail must be paid to get it all from one file to another with a minimal number of items to be fixed after pasting. See this thread for more on the subject: Importing Layouts
The database design report can be invaluable in tracking down stuff that "broke" during the import of scripts or the pasting of layout objects.
There is a utility, FMMigrator, that claims to make this much easier to do.
The custom values of a value list can be copied/pasted from one file to another though other value lists cannot be.
Great answers! I am due to start connecting Filemaker to an online MySQL database...on the one hand I don't want to give myself extra work right now. On the other I don't want to land myself in future mess if I don't bite the bullet now.
Please note that I am really not disagreeing with Rick in any way. The many steps and the careful attention to detail needed to merge two FileMaker databases pretty much illustrate the point he was making.
You'll need to look at your own skills and the complexity of your database design and decide for yourself whether the "merge" is worth the time and effort or not.
Home > Using FileMaker Pro > FileMaker Pro basics > Converting files from FileMaker Pro 11 and earlier > Converting multiple files at once
How To Merge FileMaker Files
Home > Using FileMaker Pro Advanced > Customizing files with FileMaker Pro Advanced > Copying or importing table schemas (FileMaker Pro Advanced)
Older article about consolidation Updated on November 16, 2011 Useful for list of elements to consider.
Upgrading FileMaker Pro, Part 2 - File Consolidation