Imported related data between FM files

[AJB_UMASS]

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?

[AJB_UMASS]

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?

[AJB_UMASS]

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?

[sbg2]

Set it up as two imports in 1 script:

Import Parent:

ID

Name

Import Child:

ID

Color

[sbg2]

Set it up as two imports in 1 script:

Import Parent:

ID

Name

Import Child:

ID

Color

[sbg2]

Set it up as two imports in 1 script:

Import Parent:

ID

Name

Import Child:

ID

Color

[Fenton]

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

[Fenton]

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

[Fenton]

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

[AJB_UMASS]

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?

[AJB_UMASS]

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?

[AJB_UMASS]

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?

[Fenton]

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.

[Fenton]

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.

[Fenton]

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.

[sbg2]

"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.

[sbg2]

"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.

[sbg2]

"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