I have an older "contacts" database that I want to update using the template from Filemaker Pro 19. Unfortunately, importing the data from the old DB to the new DB is impossible due to how they structured the database. The "new" way is better, using related fields, so that one could have, say unlimited phone number fields, as opposed to a pre-determined amount. The problem is the import window only shows fields for the current layout to import into, and not any related fields connected to that layout. So, phone numbers, addresses, etc. all wont import.

My idea was to just copy said layout to the old DB, so the data would still be there. Then map the fields to their corresponding fields on the new layout, and where necessary, recreate the underlying relational structure, and then possibly script a move of the data to its new location.

There is no "Import Layout from DB" command, or anything like it. I guess they supposed that the likelihood of exact field matches was slim, which is true, but that doesn't mean this still wouldn't be useful. Doing a copy and paste had, shall we say, less than spectacular results.

Short of just using the new DB layout as an example, and recreating it BY HAND, field by field, I am at a loss.

Seems to me that a the program got smarter (and indeed it did), the templates, while showing up the new features, actually became less capable, throwing more work on us. At present it would seem easier to create my DB, rather than start with a template that the current feature set is going to make hard for me to convert to.

9 hours ago, Joseph M said:

My idea was to just copy said layout to the old DB, so the data would still be there.

I am struggling to see how this would help. I am also a bit confused: it seems to me you are mixing questions of data with layout issues.

If you want to restructure your data from a single Contacts table with multiple phone fields to a parent/child structure with multiple related records in the Phones table, I would suggest you:

1. Make sure you have a unique ContactID in the source Contacts table;
2. Import the contact data fields (without any of the phone fields) into the target Contacts table;
3. For each phone field, import the field, along with the ContactID field, into the target Phones table. If necessary, follow each import with populating the Type field in the target table.

 

Edited January 22, 20214 yr by comment