I'm beta testing the new FGDB 'preserve GlobalID' parameter in 2023 build 23215. It does not seem to be preserving the values. In the test dataset I've attached, the GlobalIDs are used for relating the attachments table to the feature. Is there something else that needs to be done to ensure the values are preserved, besides setting the parameter to Yes?
Solved
Beta testing FGDB GlobalID preservation
+30- Influencer
Best answer by natalieatsafe
@dustin Hi, thanks for your question. Could you please provide some screenshots of what you are seeing on your end? Are you receiving any translation errors with the workspace that you provided?
The reason I ask is because I tried to run your workspace as-is in my FME 2023.0 beta build 23215, and I received errors suggesting an issue with the destination FGDB.
Upon further inspection, it looks like the schema in the dest.fgdb does not match the schema in the source.fgdb. Once I exported the XML workspace document from the source FGDB, applied it to a new, empty destination FGDB, and directed the process to write to the new destination FGDB, I received an output Storm feature class with global IDs preserved.
Additionally, it looks like the relationship class used in testing is a non-attributed relationship class. When working with non-attributed relationship classes in FME, you can only insert or delete features; you cannot update features (i.e. change attribute names). As well, feature classes which participate in the relationship, as well as the relationship class itself should all be written by the same writer, not separate writers.
We do have some useful documentation on working with Esri relationship classes, available here. You'll also find a couple of hands-on exercises linked to that document that work through writing these relationship classes.
Please let me know if you're seeing something different on your end with your FME, and we can look into it further.
+11- Safer
- Best Answer
@dustin Hi, thanks for your question. Could you please provide some screenshots of what you are seeing on your end? Are you receiving any translation errors with the workspace that you provided?
The reason I ask is because I tried to run your workspace as-is in my FME 2023.0 beta build 23215, and I received errors suggesting an issue with the destination FGDB.
Upon further inspection, it looks like the schema in the dest.fgdb does not match the schema in the source.fgdb. Once I exported the XML workspace document from the source FGDB, applied it to a new, empty destination FGDB, and directed the process to write to the new destination FGDB, I received an output Storm feature class with global IDs preserved.
Additionally, it looks like the relationship class used in testing is a non-attributed relationship class. When working with non-attributed relationship classes in FME, you can only insert or delete features; you cannot update features (i.e. change attribute names). As well, feature classes which participate in the relationship, as well as the relationship class itself should all be written by the same writer, not separate writers.
We do have some useful documentation on working with Esri relationship classes, available here. You'll also find a couple of hands-on exercises linked to that document that work through writing these relationship classes.
Please let me know if you're seeing something different on your end with your FME, and we can look into it further.
+30- Influencer
natalieatsafe wrote:
@dustin Hi, thanks for your question. Could you please provide some screenshots of what you are seeing on your end? Are you receiving any translation errors with the workspace that you provided?
The reason I ask is because I tried to run your workspace as-is in my FME 2023.0 beta build 23215, and I received errors suggesting an issue with the destination FGDB.
Upon further inspection, it looks like the schema in the dest.fgdb does not match the schema in the source.fgdb. Once I exported the XML workspace document from the source FGDB, applied it to a new, empty destination FGDB, and directed the process to write to the new destination FGDB, I received an output Storm feature class with global IDs preserved.
Additionally, it looks like the relationship class used in testing is a non-attributed relationship class. When working with non-attributed relationship classes in FME, you can only insert or delete features; you cannot update features (i.e. change attribute names). As well, feature classes which participate in the relationship, as well as the relationship class itself should all be written by the same writer, not separate writers.
We do have some useful documentation on working with Esri relationship classes, available here. You'll also find a couple of hands-on exercises linked to that document that work through writing these relationship classes.
Please let me know if you're seeing something different on your end with your FME, and we can look into it further.
@natalieatsafe I guess I misunderstood the purpose of the Preserve GlobalIDs parameter. I assumed that if a value was passed to an attribute with type of globalid, then the value would be retained once written regardless of schema input. In my sample workspace, the goal is to take the source data, map the schema to the destination gdb, and write it out retaining the attachments (keeping in mind, this is an extremely trimmed down version due to proprietary info).
If data has to remain in the same schema for this parameter to work, it seems this goes against FMEs basic functionality of being able to manipulate schemas and data. I feel like the descriptive text of this parameter needs to expand on its limitations, if this is the case.
+11- Safer
@dustin Your understanding of the Preserve GlobalIDs parameter sounds correct. If you've added Global IDs to your source feature classes, and then you write these out with Preserve GlobalIDs set to yes, then the Global IDs should be maintained for features written to you target FGDB. I've tested this with simpler FGDB schemas (no relationships!), with success. It seems that, when you introduce a relationship class into the equation (and attachments to boot!) the process is not quite as simple potentially due to how Global IDs are used in relationship classes. This will take some looking at on my end, and I'm going to enlist the help of a colleague to do some testing. If we do work out a process that would work for your needs, we'll update this thread.
In the meantime, I would suggest having a look at our documentation on working with Esri relationship classes in FME. There are some tips therein which may point to another method of approaching this. Here are a couple that you could start with, in addition to the article I linked in my previous post:
Writing Geodatabase Relationship Classes
Writing ArcGIS Geodatabase Attachments
If you do find a workflow which does achieve your end-goal, please don't hesitate to share it here! I'm sure other users would be interested in seeing your workflow.
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.