SDEWorkspaceFactory returning wrong workspace

[AndrewBoyle1]

I'm trying to write an ArcCatalog 10.1 Add-in where you select a folder in ArcCatalog and click a button that kicks off a process that searches through the directory for layer files and switches the connection information if it meets certain requirements.  I'm running into an issue using the SDEWorkspaceFactory class in the following code where I try to change the connection information:

Type factoryType = Type.GetTypeFromProgID("esriDataSourcesGDB.SdeWorkspaceFactory"); IWorkspaceFactory2 workspaceFactory = (IWorkspaceFactory2)Activator.CreateInstance(factoryType); IWorkspace workspace = workspaceFactory.Open(connectionPropertySet, ArcCatalog.Application.hWnd); IFeatureWorkspace featureWorkspace = (ESRI.ArcGIS.Geodatabase.IFeatureWorkspace)workspace; IFeatureClass featureClass = featureWorkspace.OpenFeatureClass(datasetName.Name); if (featureClass == null) {     return false; } featureLayer.FeatureClass = featureClass;

The issue is that I supply workspaceFactory.Open with the following connection properties.

SERVER: *myServer*
INSTANCE: *instance2*
USER: *user*
PASSWORD: *password*
AUTHENTICATION_MODE: *authentication mode*
VERSION: *version*

The workspace I get back does not always have matching connection properties.  Instead it has...

SERVER: *myServer*
INSTANCE: *instance1*
USER: *user*
PASSWORD: *password*
AUTHENTICATION_MODE: *authentication mode*
VERSION: *version*
IS_GEODATABASE: *is geodatabase*
CONNPROP-REV: *connprop-rev*

Since it returns the wrong instance, the call featureWorkspace.OpenFeatureClass(datasetName.Name) throws an exeption since the feature we are looking for does not exist in the specified instance.  All the other connection properties are fine.

I'll note that this is not a consistent problem.  Sometimes I pass *instance1* and get *instance2* or vice versa and sometimes I get the correct instance.  Usually, running the tool a couple times switches all the files.

The tool is written in C# using ArcObjects 10.1 and .NET Framework 3.5

[JeffMatson]

Connections are a little different at 10.1, are you trying to connect using the actual server name, or an alias set up for the instance?

Also you might try checking if a feature class exists before opening it, and then handling that situation before the exception is thrown.

I'm trying to write an ArcCatalog 10.1 Add-in where you select a folder in ArcCatalog and click a button that kicks off a process that searches through the directory for layer files and switches the connection information if it meets certain requirements.  I'm running into an issue using the SDEWorkspaceFactory class in the following code where I try to change the connection information:

Type factoryType = Type.GetTypeFromProgID("esriDataSourcesGDB.SdeWorkspaceFactory");
IWorkspaceFactory2 workspaceFactory = (IWorkspaceFactory2)Activator.CreateInstance(factoryType);
IWorkspace workspace = workspaceFactory.Open(connectionPropertySet, ArcCatalog.Application.hWnd);
IFeatureWorkspace featureWorkspace = (ESRI.ArcGIS.Geodatabase.IFeatureWorkspace)workspace;
IFeatureClass featureClass = featureWorkspace.OpenFeatureClass(datasetName.Name);
if (featureClass == null)
{
    return false;
}
featureLayer.FeatureClass = featureClass;

The issue is that I supply workspaceFactory.Open with the following connection properties.

SERVER: *myServer*
INSTANCE: *instance2*
USER: *user*
PASSWORD: *password*
AUTHENTICATION_MODE: *authentication mode*
VERSION: *version*

The workspace I get back does not always have matching connection properties.  Instead it has...

SERVER: *myServer*
INSTANCE: *instance1*
USER: *user*
PASSWORD: *password*
AUTHENTICATION_MODE: *authentication mode*
VERSION: *version*
IS_GEODATABASE: *is geodatabase*
CONNPROP-REV: *connprop-rev*

Since it returns the wrong instance, the call featureWorkspace.OpenFeatureClass(datasetName.Name) throws an exeption since the feature we are looking for does not exist in the specified instance.  All the other connection properties are fine.

I'll note that this is not a consistent problem.  Sometimes I pass *instance1* and get *instance2* or vice versa and sometimes I get the correct instance.  Usually, running the tool a couple times switches all the files.

The tool is written in C# using ArcObjects 10.1 and .NET Framework 3.5

[AndrewBoyle1]

Connections are a little different at 10.1, are you trying to connect using the actual server name, or an alias set up for the instance?

Also you might try checking if a feature class exists before opening it, and then handling that situation before the exception is thrown.

I was worried it might be something like that.  I am using an alias for the SERVER value but it's not unique to a specific instance.  Also, I knew I forgot to mention something; the layers I'm getting the connection information from were created in ArcGIS 9.3.

You're right; I should be checking it that way.  I'll be sure to change the code.  Thanks!

[JeffMatson · Accepted solution]

I was worried it might be something like that.  I am using an alias for the SERVER value but it's not unique to a specific instance.  Also, I knew I forgot to mention something; the layers I'm getting the connection information from were created in ArcGIS 9.3.

That makes sense, we've found (so far) that using any "old" connection properties will create this problem as soon as we try to connect to another instance on the same server (via code, arcToolbox, arcCatalog, etc.).  The old instance is referenced no matter what, until everything is closed out and re-opened, and then you can only open one connection before the same problem occurs.

Luckily our SDE admin folks were on the ball and had "new" connection files ready to go.  After deleting all the old connection files and replacing them with the new aliased connection files, everything works, including programmatically updating .lyr files (created in 10.0) to point to the new aliased connection instances.  Hopefully it works for your 9.3 .lyr files too.

[AndrewBoyle1]

That makes sense, we've found (so far) that using any "old" connection properties will create this problem as soon as we try to connect to another instance on the same server (via code, arcToolbox, arcCatalog, etc.).  The old instance is referenced no matter what, until everything is closed out and re-opened, and then you can only open one connection before the same problem occurs.

That seems to be the issue.  Since I have been having other issues with using 10.1 connections in 9.3 layers (the file loads in ArcGIS 9.3.1 but the layer has a broken link), I ported the code to 9.3 and I did not have any issues with it. 

Thank you for all your help!