Ok I'm working on migrating my data from the last 10.1 LG.gdb to the November release and with the continued use and increase of relationship classes and attachments, which are great, I thought it might be time to ask the question of is there a better way to transfer data into standalone tables that are part of relationship classes without having to buy the data interop extension and without having to constantly delete and remake the the relationship classes? When it's features related it's real easy to set up a data loader in the editor toolbar and do it from arcinfo, and if they aren't part of a relationship class just doing a simple feature load, unfortunately neither of these methods work when it's a standalone table participating in a relationship class. Also with attachments is there a good way to migrate those so they stay associated with their individual rows or features since attachments are based on the OBJECTID field which when reloading data into the new info model will change those object ids? Is their a script or model in the works to be able to swap the data from previous release gdbs to the new ones?
You can use a full Xml model and use the latest X-Ray to "Import Using Geoprocessing" to apply the differences to a Geodatabase. I don't think this will work for attachments, but for basic relationship classes it will work if you choose the option to replace all of the relationship classes.
One other trick I have used is to make an Xml Workspace document that just has the relationships in it. Simplest thing to do is open the datasets in X-Ray/Excel and delete everything except the things you want to apply after the data load. As long as the target datasets for the relationship classes already exist in the Geodatabase the Xml Workspace Import should work. Again, you could also use Import Using Geoprocessing to do the same thing, but sometimes for repeat activities the partial Xml Workspace worked better for me (all gdb datasets supported, and faster).
You can use a full Xml model and use the latest X-Ray to "Import Using Geoprocessing" to apply the differences to a Geodatabase. I don't think this will work for attachments, but for basic relationship classes it will work if you choose the option to replace all of the relationship classes.
One other trick I have used is to make an Xml Workspace document that just has the relationships in it. Simplest thing to do is open the datasets in X-Ray/Excel and delete everything except the things you want to apply after the data load. As long as the target datasets for the relationship classes already exist in the Geodatabase the Xml Workspace Import should work. Again, you could also use Import Using Geoprocessing to do the same thing, but sometimes for repeat activities the partial Xml Workspace worked better for me (all gdb datasets supported, and faster).
