@timboberoosky I don't think you need the actual OBJECTID. I think you can set temporary values for geodb_oid and FME should sort out the actual objectid's. You just need to ensure that the geodb_oid's values are the same on both sides of the relationship so they can be linked.
@timboberoosky I don't think you need the actual OBJECTID. I think you can set temporary values for geodb_oid and FME should sort out the actual objectid's. You just need to ensure that the geodb_oid's values are the same on both sides of the relationship so they can be linked.
Thanks @Mark Stoakes
I must still be missing something then. I simplified my workspace just to see if I could get the relationships working, and I'm constantly getting the error "Missing required attribute 'geodb_rel_destination_oid' for writing relationship. Please specify this attribute on all relationship features to be written". However, I have both my geodb_rel_origin_oid and geodb_rel_destination_oid attributes set on appropriate features, as can be seen on the Table Preview of the features being written to the relationship class - see below. Note that I'm breaking up 1 source feature into 2 streams, writing 1 to the origin feature class and the other to the destination table, and I created IDs for each using Counter transformers. Is there something I'm obviously missing? The datasets are large so I didn't want to upload them, but could try to do so if that would help.
Thanks again.
@timboberoosky If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.
But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)
@timboberoosky If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.
But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)
Thanks @Mark Stoakes . Re-routed the workflow and wrote only one record to the relationship class and everything worked perfectly. Attaching screenshot below for reference. Thanks again!
@timboberoosky If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.
But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)
Hi again @Mark Stoakes
I'm not sure if this deserves a new thread, and sorry for the lengthy explanation but it's a related a follow up where I'm adding some complexity to this relationship workflow. So, I'm wondering if it's possible to write to multiple relationship classes using the same feature as both primary and foreign keys for one and the other. So, the 1 Transformer source feature is creating 3 destination features: 1 Transformer feature, 1 TransformerUnit feature and 1 SurfaceStructure feature. The transformer feature in the example above is the primary key (geodb_rel_origin_oid) for one relationship (Transformer_TransformUnit that we already solved) as well as the foreign key (geodb_rel_destination_oid) for another relationship I've introduced (SurfStruct_Transformer). I could duplicate the stream to create the geodb_rel_origin_oid for the SurfaceStructure side of the SurfStruct_Transformer relationship, but the Transformer feature is already the geodb_rel_origin_oid for the other Transformer_TransformUnit relationship and needs to be the geodb_rel_destination_oid for the SurfStruct_Transformer relationship.
Does this make sense? I've tried to build what I mean in the screenshot below, but unsurprisingly it throws an error not being able to find the relationship feature from Transformer for the SurfStruct_Transformer relationship (I tried to exemplify this by making the geodb_rel_origin_oid and geodb_rel_destination_oid - both set by the count transformer not be the same number, i.e. starting 1 counter at 1 and the other counter at 2).
Also unsurprisingly, if I rename the geodb_rel_origin_oid and geodb_rel_destination_oid BOTH to geodb_oid on the Transformer feature being written, I get an "invalid foreign key value" error.
Any thoughts or help on this type of intermingled relationship writing would be greatly appreciated!
Thanks
@timboberoosky I thin I was successful in creating two related tables for a single feature class. I've attached my workspace - FME 2021.2.
But... in your image, it looks like you have reversed your relationship to that SurfaceStructure is the origin (parent). That would mean you'd have to have a origin (foreign key on the Transformer feature class for the SurfaceStructure. I think that might be harder to do.
If you want to modify the attached File geodb template to match the relationships you have then I can take another look.
