Regarding question 1:

Since I have to transfer about a hundred relationship classes containing several millions records, a method that doesn't involve loading the associated FCs and joining per FeatureMerger would be much faster and could be automated more easily.

Regarding question 2:

I didn't consider that for N:M-relationships, a message would only deal with DELETEs, but not UPDATEs or INSERTs (as the Information which objects are associated is lacking). Since I have the relationships in an own FC, which is updated as well when the FCs containing the associated objects are updated, writing incremential updates into the relationship class will probably do the Job. Thus, question 2 is actually the same as question 1 :)

Hello @andr_. You should be able to simply rename the FID to be the geodb_rel_origin/destination_oid/geodb_oid. The article needs to be modified because ObjectID should really say Primary key - or whichever attribute you used as the Primary key when setting up the relationship. If you still have troubles please do send support your workspace and sample source data, along with the relationship feature class you have set up in ArcGIS.

Hello @CandaceAtSafe

Thanks for your answer. I tried it quickly. It seems that FME still needs to read the associated Feature classes so that it can check whether the Features mentioned in the association really exist. So even if the Primary key-attribute is another one, the Basic mechanic doesn't Change. My Goal is to write the data from the original table containing the associations into the relationship class without having to read the associated feature classes as well (that means to avoid the existance-check of FME). Is there any way to do that?

I also stumbled upon another issue when I tried to write incremential update to an archived relationship class (by using the cumbersome way discribed above) :-)

According to this FME tutorial, it should be possible to send UPDATE-commands when an attributed relationship class is used (and the writer is in "edit session-" and Update-mode). INSERT- and DELETE-commands work, but as soon a INSERT occurs (fme_db_operation-attribute set to the corresponding values), the following error appears:

2147211178': Cannot reset foreign key values for an existing relationship row.

This implies that UPDATES fail nevertheless, right?

Greetings,

André

Hello @andr_ - I have sent you an email. It seems we need to investigate this a bit more in support.

FME may only be used to UPDATE the attributes in an attributed relationship, not the RID, foreign and primary keys. If this is desirable, a DELETE and INSERT operation must be performed.

With the SDE Geodatabase writer, when writing data into an attributed relationship or M:N (attributed or not), if the features which participate in the relationship class already exist in the database and only the relationship table needs to be populated, you still must READ the features which participate in the relationship to get their OBJECTID's but you don't have to WRITE these features back. The OBJECTID's read from the origin and destination relationship features will need to be renamed to the geodb_rel_origin_oid and geodb_rel_destination_oid respectively in order for the relationship table to be populated. At this time there isn't a way to insert existing relationship values into a relationship table with SDE Geodatabase (ie: take from one legacy relationship table and insert those values into a new relationship table) without reading the features that participate in the relationship to get the OBJECTID.