Problem updating tableview broken data sources.

[MathewCoyle]

I have several mxds with broken data sources to SDE after a database move. I am running a script to update the broken data sources and keep getting an error on broken links to table views. All other layers update correctly.

Here is the error I get

Runtime error <type 'exceptions.ValueError'>: StandaloneTableObject: Unexpected error

Here's the relevant code where I am getting the error.

brokenlist = arcpy.mapping.ListBrokenDataSources(mxd)
for lyr in brokenlist:
    if ".sde" in lyr.dataSource:
        try:
            lyr.replaceDataSource(new_datasource, "SDE_WORKSPACE", lyr.name)

Has anyone encountered this or know a work around?

Edit: I've tried it with and without the lyr.name specified.

[MichaelVolz]

Mathew:

I do not have an answer for your question, but I am interested in the performance of your script.

I have written a replacedatasource script for SDE layers that loops through a directory searching for mxds and then resourcing the SDE layers.  Unfortunately, the script eventually uses all the computer's RAM and it just hangs so I have to kill it in Task Manager.

Would you know if the memory on your python script keeps increasing?  Your script might not have frozen because you did not process enough mxd files in your batch.

Any insight on your script and system would be greatly appreciated.  Thanks.

[MathewCoyle]

I have actually run into that issue, but it was more to do with encountering a "corrupt" MXD (I put corrupt in quotes since MXD Doctor found no corrupted items, but once I ran a fix with MXD Doctor it worked fine, so I would call that corrupted). I am not sure what was wrong with it since it opened with ArcMap fine, just with broken links. Running through MXD Doctor showed a bunch of strange modules that were removed when I ran a fix and it processed fine after that. I've mostly seen this behaviour from some v10 .mxd files that were converted from prior version .mxt files, but that may be anecdotal. Not sure if this would be related to your situation or not. When I batched through I fixed about 500 mxds that ran fine once the "corrupted" ones were fixed or removed.

[MichaelVolz]

Mathew:

Can you share your code of batching through 500 mxds?  The reason I ask is because maybe this is the cause of the memory issue I am having with replacing SDE connections.  This phenonmenon happens everytime where I get through a certain amount of mxds before python freezes up.

This same problem did not occur if I batch converted sources to file geodatabases or personal geodatabases.

[MathewCoyle]

Here's the script I used. Are you freezing on the same mxd every time? How many are you converting?

[MichaelVolz]

Mathew:

I freeze on different mxds depending upon the subdirectory that I choose to convert the SDE datasources for, so it is not the same file every time.

Eventually I will need to convert up to 3 thousand mxds with each mxd having from 1 SDE connection to 40 or 50 SDE connections.  This process will need to be done when my organization migrates from Oracle Client 10g to Oracle Client 11x, as this information is embedded in the direct connection string for every SDE connection.  This is why this information is important to me.

[MichaelVolz]

Mathew:

I have a few more questions about how you run your script, since I have an almost identical script that hangs up after a short time.

Does your script strictly run against v10 mxds?  Or can it run against previous versions of ArcGIS mxds?

Does your script strictly run against SDE v10?  Or can it run against previous versions of ArcSDE connections?

Your feedback to this question is greatly appreciated.  Thanks.

[MathewCoyle]

It did run on a mix of 9.3.1 and 10 mxds. Converting them all to 10 in the process. It was only run on a v10 SDE instance though, as that was what we migrated to in our upgrade. All the broken links were to a 9.3.1 SDE. I don't have any 9.3.1 SDE instances left to test this on unfortunately, that may be your problem, though I don't know why that would be an issue.

[MichaelVolz]

Mathew:

I have a incident logged with ESRI about this issue and the ESRI tech duplicated the same phenomenon on his system so he created a NIM for this bug.  This is why I am surprised you are able to run your script on so many mxds.

Would you be able (and willing) to run your script on a batch of mxds and see if the pythonwin.exe or python.exe process in Task Manager keeps increasing in mem usage as that is what happens on my system?

I'm thinking that you might have a much more powerful system where you just never reached the mem usage threshold to lock up your python process.

Your help and feedback is greatly appreciated.

[MathewCoyle]

Sure I'll try re running it again. I ran it over night and didn't have much logging on as it was really just a test, but everything worked so I never bothered with checking if there were any issues other than if all the mxds could be opened and had the correct new SDE isntance. I have made my python process large address aware so that may have helped.