Skip to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Imported related data between FM files

Featured Replies

  • Author

This is silly - when I want to export data from a FM file, the program has absolutely no trouble letting me export fields from any tables that are related to the parent table.

Export

------

Parent::ID No.

Parent::Name

Child::Favorite Color (as related by matching ID No., let's say)

However, when I have a separate FM File that I want to directly import the data INTO, I cannot map related fields for import; if I wanted the 'Favorite Color' field, I'd have to define a local copy of it (Parent::zc.Fcolor = Child::Favorite Color), in order to define the field import order from Parent.

Import

------

Parent::ID No.

Parent::Name

Parent::zc.fcolor

Any way around this? It seems crazy that you cannot pull data from a FM table, as well as simultaneously pulling from related tables. Am I forced to dump to a temporary file, and then import into the new FM file?

This is silly - when I want to export data from a FM file, the program has absolutely no trouble letting me export fields from any tables that are related to the parent table.

Export

------

Parent::ID No.

Parent::Name

Child::Favorite Color (as related by matching ID No., let's say)

However, when I have a separate FM File that I want to directly import the data INTO, I cannot map related fields for import; if I wanted the 'Favorite Color' field, I'd have to define a local copy of it (Parent::zc.Fcolor = Child::Favorite Color), in order to define the field import order from Parent.

Import

------

Parent::ID No.

Parent::Name

Parent::zc.fcolor

Any way around this? It seems crazy that you cannot pull data from a FM table, as well as simultaneously pulling from related tables. Am I forced to dump to a temporary file, and then import into the new FM file?

  • Author

This is silly - when I want to export data from a FM file, the program has absolutely no trouble letting me export fields from any tables that are related to the parent table.

Export

------

Parent::ID No.

Parent::Name

Child::Favorite Color (as related by matching ID No., let's say)

However, when I have a separate FM File that I want to directly import the data INTO, I cannot map related fields for import; if I wanted the 'Favorite Color' field, I'd have to define a local copy of it (Parent::zc.Fcolor = Child::Favorite Color), in order to define the field import order from Parent.

Import

------

Parent::ID No.

Parent::Name

Parent::zc.fcolor

Any way around this? It seems crazy that you cannot pull data from a FM table, as well as simultaneously pulling from related tables. Am I forced to dump to a temporary file, and then import into the new FM file?

Set it up as two imports in 1 script:

Import Parent:

ID

Name

Import Child:

ID

Color

Set it up as two imports in 1 script:

Import Parent:

ID

Name

Import Child:

ID

Color

Set it up as two imports in 1 script:

Import Parent:

ID

Name

Import Child:

ID

Color

Do multiple imports, one per table. Each import is simple by itself. If it's scripted it should all happen pretty quickly.

Do multiple imports, one per table. Each import is simple by itself. If it's scripted it should all happen pretty quickly.

Do multiple imports, one per table. Each import is simple by itself. If it's scripted it should all happen pretty quickly.

  • Author

Won't this give me two separate, partially filled-in, groups of records in the new FM file?

After the first import, you'd have a bunch of records like this:

ID No. Name Fcolor

------ ---- ------

1234 Joe

2345 Sarah

And, after the second import, you'd have records like this:

ID No. Name Fcolor

------ ---- ------

1234 Red

2345 Blue

If I then wanted to have records that looked this way:

ID No. Name Fcolor

------ ---- ------

1234 Joe Red

2345 Sarah Blue

I'd have to do some massaging of the data; or am I missing something?

  • Author

Won't this give me two separate, partially filled-in, groups of records in the new FM file?

After the first import, you'd have a bunch of records like this:

ID No. Name Fcolor

------ ---- ------

1234 Joe

2345 Sarah

And, after the second import, you'd have records like this:

ID No. Name Fcolor

------ ---- ------

1234 Red

2345 Blue

If I then wanted to have records that looked this way:

ID No. Name Fcolor

------ ---- ------

1234 Joe Red

2345 Sarah Blue

I'd have to do some massaging of the data; or am I missing something?

  • Author

Won't this give me two separate, partially filled-in, groups of records in the new FM file?

After the first import, you'd have a bunch of records like this:

ID No. Name Fcolor

------ ---- ------

1234 Joe

2345 Sarah

And, after the second import, you'd have records like this:

ID No. Name Fcolor

------ ---- ------

1234 Red

2345 Blue

If I then wanted to have records that looked this way:

ID No. Name Fcolor

------ ---- ------

1234 Joe Red

2345 Sarah Blue

I'd have to do some massaging of the data; or am I missing something?

The data, if properly relational, is in its own table already, with only the parent ID in both tables. So, you import once into the parent, from the parent data, then once into the child, from the child data. The only identical data both must import is the parent ID, which is then the tie.

You don't usually Export data to move it between FileMaker files, and you would generally have the same relational structure in each file. So it's a series of table to corresponding table imports. You haven't really told us what you're doing, so it's hard to say what the perceived problem is.

The data, if properly relational, is in its own table already, with only the parent ID in both tables. So, you import once into the parent, from the parent data, then once into the child, from the child data. The only identical data both must import is the parent ID, which is then the tie.

You don't usually Export data to move it between FileMaker files, and you would generally have the same relational structure in each file. So it's a series of table to corresponding table imports. You haven't really told us what you're doing, so it's hard to say what the perceived problem is.

The data, if properly relational, is in its own table already, with only the parent ID in both tables. So, you import once into the parent, from the parent data, then once into the child, from the child data. The only identical data both must import is the parent ID, which is then the tie.

You don't usually Export data to move it between FileMaker files, and you would generally have the same relational structure in each file. So it's a series of table to corresponding table imports. You haven't really told us what you're doing, so it's hard to say what the perceived problem is.

"I'd have to do some massaging of the data; or am I missing something?"

Forgive me if you already understand relationships and how to display related data, from your previous post I get the impression you may not. Attached is a file showing the basic ways to display the related data.

You wouldnt need a field called Fcolor in the first database nor a field called Name in the second, this is why you have an ID to establish a relationship between the two tables. To show the Fcolor in the first table simply put the Child::Fcolor field on the layout. If there will be more than 1 related record in the Child table use a portal to show the related records.

"I'd have to do some massaging of the data; or am I missing something?"

Forgive me if you already understand relationships and how to display related data, from your previous post I get the impression you may not. Attached is a file showing the basic ways to display the related data.

You wouldnt need a field called Fcolor in the first database nor a field called Name in the second, this is why you have an ID to establish a relationship between the two tables. To show the Fcolor in the first table simply put the Child::Fcolor field on the layout. If there will be more than 1 related record in the Child table use a portal to show the related records.

"I'd have to do some massaging of the data; or am I missing something?"

Forgive me if you already understand relationships and how to display related data, from your previous post I get the impression you may not. Attached is a file showing the basic ways to display the related data.

You wouldnt need a field called Fcolor in the first database nor a field called Name in the second, this is why you have an ID to establish a relationship between the two tables. To show the Fcolor in the first table simply put the Child::Fcolor field on the layout. If there will be more than 1 related record in the Child table use a portal to show the related records.

Parent~Child.zip

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.