Hello,

I started my current "database" years ago. Way before FileMaker could have multiple files in one file. Anyway, all of a sudden I'm jealous of the current organization and I can't help but wonder - is there a way to combine multiple database files in one? At present about 8 or 9 files make up my database. I'd love to combine them into one with multiple tables. Most are already related but some are not. Any advice?

Thank you

Automatic message

This topic has been moved from "Database Schema & Business Logic → Relationships" to "Brain Food → Upgrading & Migration".

What you are describing is called migration, here is a link to some white papers that will help get you started http://help.filemaker.com/app/answers/detail/a_id/5385/~/upgrading-to-filemaker-9%3A-migrating-from-filemaker-pro-6-or-earlier-solutions

Lee

Thanks for moving the thread and the link. I looked at the PDF and didn't find any instructions telling me how to effectively merge multi-file databases into one...is this possible?

There is no "automatic" way to merge files. Basically you need to copy and paste the tables, layouts and scripts, and stitch it all back together again.

Yes it's tedious, and often a lot of work. Which is why a lot of older FMP 6 solutions were completely re-written for FMP 7+ rather than be converted and merged, because it's about the same magnitude of work.

Another option is to NOT merge them, or not merge them all. FileMaker doesn't care what file a table "lives" in. You may find certain files should be together because of context and you may find it easier than expected. When you say some files are not related, I assume you mean related in a DB meaning of the word. If so, perhaps these are not meant to be merged with the others. The solution I made for my business has seven files. One of the main disadvantages is seven relationship graphs, but it's fast and works well all the same.

Edit: Oops, just reread your post. Each file is single table! This makes the merge to one file much simpler, but still manual. I'd go for it. Moving layouts isn't that difficult. The calls will need to be re-referenced since at this point the only table they can refer to is the one they're in . . .

Read the migration documents for FM 6->7 because the ORDER that you do things in can greatly decrease the amount of work required. For example, if scripts are pasted before layouts and fields are created then all the references to layouts and fields in the scripts will be broken. However, you want to paste the objects on the layouts AFTER the scripts are done so that the buttons on the layouts won't be broken.

I forget the optimum order because it's been a while since I've done a migration. :)