March 10, 200520 yr 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?
March 10, 200520 yr 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?
March 10, 200520 yr 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?
March 10, 200520 yr Set it up as two imports in 1 script: Import Parent: ID Name Import Child: ID Color
March 10, 200520 yr Set it up as two imports in 1 script: Import Parent: ID Name Import Child: ID Color
March 10, 200520 yr Set it up as two imports in 1 script: Import Parent: ID Name Import Child: ID Color
March 10, 200520 yr Do multiple imports, one per table. Each import is simple by itself. If it's scripted it should all happen pretty quickly.
March 10, 200520 yr Do multiple imports, one per table. Each import is simple by itself. If it's scripted it should all happen pretty quickly.
March 10, 200520 yr Do multiple imports, one per table. Each import is simple by itself. If it's scripted it should all happen pretty quickly.
March 10, 200520 yr 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?
March 10, 200520 yr 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?
March 10, 200520 yr 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?
March 10, 200520 yr 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.
March 10, 200520 yr 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.
March 10, 200520 yr 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.
March 10, 200520 yr "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.
March 10, 200520 yr "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.
March 10, 200520 yr "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