Update Joins with data updates

[MarkLecher2]

Updating mxd documets that drive web services in and enterprise environment can be hard to manage sometimes.  At 10, updating of data sources became easier with the use of pyton.  However, if the mxd is built using stand alone tables joined to layers, those joins do not and cannot be easily updated when data sources change.  This is especially troublesome for users in a multi-tiered environment where the mxds and services need to move from test to staging to production with data source updates at each move.  Now, the joins do not get updated with the data source change and the mxd needs to be manually updated (join removed and recreated) which requires work and introduces the chance of errors being introduced in the change.

[ChrisFox]

Thank you for posting the idea. One thought I had was if you replaced the data source through python could you then recreate the join as well using the Add Join tool? This might help automate the process of changing data sources and recreating the join.

[JurajKrumpolec]

What if ArcGIS did it automatically, without any user intervention? No python, no programming, just a simple click and the application does it by itself. Updates everything what is needed when the data sources change - joins, symbology, definition query, labels etc. I know, I know, it would be probably too much comfort for the user when it is possible to do it manually, one by one, like everything else in ESRI's applications 😞
No intelligence, no intuitiveness, no interactivity, just pure unconsciousness.

[ChrisFox]

@mlecher If I am understanding you correctly you are wanting to update an mxd's layer and joined tables with new data sources as you move from staging to production for example. The findAndReplaceWorkspacePaths should accomplish this. For example let's say all my layer's data sources and tables are in the workspace, "C:\mytest\testing.gdb" and I want to update the source to E:\Production\Production.gdb. I could use the following lines of code to make the change in Python.

import arcpy
mxd = arcpy.mapping.MapDocument(r"C:\myMXD.mxd")
mxd.findAndReplaceWorkspacePaths(r"C:\mytest\testing.gdb", r"E:\Production\Production.gdb")
mxd.save()
del mxd

Not only would the layers update to the new data source, but the stand-alone tables joined to those layers would update to the new data source. If you have tried this and are not getting the same results could you verify you are at service pack 1. If I am not understanding your workflow correctly could you write back with more details on your specific scenario.

[DavidKnudsen]

Our big problem with this is that it is rare for tables to be in the same workspace as the feature classes to which they are joined. This is almost inherent in the usefulness of joins: if the tables were in the same workspace, wouldn't that probably imply that you "owned" or maintained the tables as well as the feature classes? In that case, you would probably just permanently extend the feature classes with the table attributes and delete the tables.

But in fact, usually we are joining because we own and maintain the feature classes but do not own and maintain the tables to which we are joining. (Simple example: a feature class of bike lanes, related by a key to a road feature class maintained by a separate agency.)

The original announcement of the arcpy.mapping module explicitly noted that joined tables in different workspaces from the feature class on the left of the join would not be changed by the functions of the module. I can't find any note about this in the current documentation. Is this something that was addressed in Service Pack 1?

[ChrisFox]

So if I understand you correctly you have a join to a table in a different workspace then the feature class and you want to change the path of the feature class for a layer in the map document but keep the path to the joined table? If this is the case I am finding that this is the behavior at 10 service pack 1. I haven't tested at 10 without service pack 1 and I did a search for known-issues and didn't find any specific to this scenario, but it may be possible it was resolved at service pack 1. Are you finding that the join is being removed when you do this?

[DavidKnudsen]

@Chris_Fox Sorry I missed your reply. I think in the case I was talking about, both the location of the feature class and the location of the table change. For example

\\old_server\share\internally_owned_data.fgdb\featureclass and
\\old_server\share\externally_supplied_data.mdb\table

both move to a new server, remaining in separate workspaces:

\\new_server\share\internally_owned_data.fgdb\featureclass and
\\new_server\share\externally_supplied_data.mdb\table.

This thread is old now, but my recollection is that the only way the source of a table on the right side of a join could be updated was if it shared the tablespace of the featureclass it was joined to; it would be updated at the same time that the source of the featureclass was fixed. Otherwise there was no direct way to access and change the source of a joined table. I don't know if my interpretation of the documentation was correct on that score and if it still holds, if so.

[Anonymous User]

I see this is a bit old. Is there a newer thread related to this topic?

I am trying to find a find a simple method to update a feature class created from a joined table. The table will updated periodically, and I want to capture that without creating a new feature class every time. Ultimately, it will be used to create a hosted feature class used in dashboards, web apps, etc. Are there any standard workflows for this?