replaceDataSource gives unexpected error on coverage data source

[curtvprice]

This is an arcpy.mapping question.

I'm having getting replaceDataSource to fix paths to coverages.

print ds print "%s, %s, %s" % tuple([ENV.workspace, covName, covNameNew]) lyr.replaceDataSource(ENV.workspace, "ARCINFO_WORKSPACE", covNameNew)

The coverage abbot_pop does not exist, but cou_pop does.

This prints:

E:\tools\arcgis\atool\arc\sample\samptest\abbot_pop\point
e:\tools\arcgis\atool\arc\sample\samptest, abbot_pop, cou_pop
Layer: Unexpected error

I tried cou_pop/point (it's a point coverage) and that didn't work either. Any ideas?

[JeffBarrette · Accepted solution]

I could reproduce the issue.  The problem is that the lyr.datasetName is, for example, "polygon" and NOT "coverageName\polygon" and lyr.workspacePath does NOT include the coverage name so the missing piece to changing the dataSource is the literal coverage name.

I tried an intermediate step.  I  converted the "to" coverage to a tempory shapefile and successfully redirected the "from" coverage dataSource to the shapefile but I was still unable to go from shapefile back to the "to" coverage.  When I specify the literal coverage name as the "dataset_name", I don't get an error but nothing happens.  If I enter "polygon" as the dataset_name it remaps to the first coverage in the workspace.

The only work around I see is to change the workspace type.  I will enter a bug into our system and try to address this for the next SP.

Sorry for the inconvenience,
Jeff

[curtvprice]

I could reproduce the issue.  

I appreciate you checking it out. If you can post or send me the NIM# I'll make sure I get a "vote" in on getting it fixed.

An interface approach that makes sense to me and not break what's there already would be to allow the data source to include feature dataset "in-gdb path"  in the argument, i.e. "covername/polygon". If you just provide a feature class name, it would continue to do what it does now and look through all feature classes until it found a match.

Seems this problem was created back in 1999 when the ArcGIS developers designed how coverage feature classes are represented in ArcGIS paths. The form "covername\covername_polygon" is more verbose, but would have preserved unique feature class names in the arcinfo workspace.

[JeffBarrette]

Curtis, here is the number you asked for:  NIM080006.  It is too late for 10.0 SP5 and 10.1 final.  The current plan is for 10.1 SP1.

Jeff