I am working on a process that archives data from a group of hosted feature layers in ArcGIS Online to a matching group of feature classes and tables in SDE and then deletes the archived data from the hosted feature layers. So far, so good except for one related table (an error log) whose relationship class has the same name. The FME writer fails because, apparently, it's trying to write to the relationship class instead of the table. Renaming the relationship class is a no go because I'm told other things will break if I do. How can I get FME to ignore the relationship class and go straight to the table?
I am sorry to tell you, but FME won't be able to solve this for you. It is technically impossible to have a feature class and a relationship class with the same name in the same database.
The solution will either be to write that specific feature class to a different database or to delete the relationship class. The consequences of the latter are depending on the type of relationship. If it is attributed or it is of a composite type, it can have consequences. If not, you can delete the relationship class and create a new one with another name.
A general tip: I always start the name of my relationship classes with rel_, this way the problem described above will never arise.
I am sorry to tell you, but FME won't be able to solve this for you. It is technically impossible to have a feature class and a relationship class with the same name in the same database.
The solution will either be to write that specific feature class to a different database or to delete the relationship class. The consequences of the latter are depending on the type of relationship. If it is attributed or it is of a composite type, it can have consequences. If not, you can delete the relationship class and create a new one with another name.
A general tip: I always start the name of my relationship classes with rel_, this way the problem described above will never arise.
Thank you. I had a suspicion that was the case. We have many relationship classes that mostly follow a similar naming convention as what you recommended. This one is the only exception and an entirely different team was responsible for this. It hasn't been a problem until now. I expect I'm going to have to pull this one out of the FME and do it in Python. Oh well, worth a try.
Hi @jstewart433. I'm sorry you ran into this! As @lars_de_vries mentions, FME doesn't currently support writing to tables/feature classes that have the same name as relationship classes.
I found a ticket in our system related to this (internal reference FMEENGINE-9057). I'll add your details to that ticket and we'll provide any updates here on this post.