SDE features have broken link in outside application, but are fine within ArcMap MXD.

[ZacharyPierce]

Hello all,

When connecting to an sde connection in ArcMap I have no issues. I can add features and see everything fine. There is no broken source links.

We have software that uses Arc MXD's, and when I open the MXD's in this software the sde features have broken links. All other features ( Shapefile and GDB Feature classes) are fine.  When I try to add the sde layers from within this software I get this error:

!!Couldn't connect to the database.  Please validate the integrity of the database and/or your network connection and try again.!!

Has anyone ever experienced this before? I have tested on other machines and the sde connections are fine. This seems to be an isolated problem to this computer.  Could the SDE DB connection be locked to ArcCatalog and ArcMap only? What other computer security/settings should I look for that could be different than other machines on that network?

**  Using Oracle, direct connect, user: sde  pass: xxx.    Are there any security settings within Arc or on the computer in general that could block a connection like this?

Thanks

[MichaelVolz]

Are you using tnsnames to identify the Oracle database you are connecting to?

Check that the Oracle Client on this machine is setup correctly.

[ZacharyPierce]

I believe on this machine it is set up to use LDAP first, then TNSNames.

Both TNSnames and LDAP have this DB service called the same.

So the "Instance" for the connection is just "xxxtest"  which points to the database.

And like I said, this works fine when in catalog and arcmap.

[ZacharyPierce]

But there is another machine that uses LDAP, has the same SDE connection setup, and that works fine.

[MichaelVolz]

What is the name of the problematic software that you are using?

[ZacharyPierce]

Its a proprietary software for our company, so nothing others would have no knowledge of.

So I was just doing some side digging if any one else experienced similar issues with other software that uses MXD's / SDE connections.

[VinceAngelo]

You probably should be talking to the maintainers of the outside application
(which may not support Direct Connect).

Then again, you really shouldn't be using the 'sde' user login for any MXD. 
Best practice includes:

• Using a strong (12+ character, etc), closely held password for the

'SDE' user

• Creating one or more additional tablespaces for spatial data


• Using one or more users other than 'SDE' to own spatial data (with

DEFAULT TABLESPACE other than SDE)

• Managing access to tables by other users through database roles

(create roles, grant access to tables to roles, grant access to roles
to users)

• Not using the data owner to publish services (a publishing user with

minimal permissions is best)

- V

[MichaelVolz]

Has SDE data ever worked in this software before?  I ask because I'm wondering if you are performing this test after upgrading your SDE database.

[ZacharyPierce]

Has SDE data ever worked in this software before?  I ask because I'm wondering if you are performing this test after upgrading your SDE database.

Yes.

It works on all other instances of the software. The ONLY machine we are having issues with is this one. Hundreds of other SDE connections have been successful elsewhere using the software, as well as 2 other machines on this network.

[ZacharyPierce]

If the other machine works I might think about looking for differences between the client machines.  Did one of the machines get upgraded to a different version or ArcGIS, are they the exact same build and have same patches?  something with the .NET framework from a windows update, etc...

That is what is scheduled for today; to compare both.

Thanks everyone for your input.   Thanks ESRI Support V