We have a new user that is having weird issues with database connections. He can create the connections and create a map, but when someone else tries to open the map there are broken links and we have to repair the datasource. If we just try to re-set the datasource, we get an error "Bad login".
In addition, I have created an ArcObjects program that connects to a geodatabase and does stuff. When this user trues to use my program, he gets an error "DBMS table not found....nameOfGDB.hisUserName.nameOfFeatureclass". This is really weird because it should be looking for "nameOfGDB.DBO.nameOfFeatureclass" (where dbo is in place of hisUserName).
I have a feeling that this is all related, but I don't know where to start. In ArcCatalog, his connection is set up the same way as everyone else's. The connection file that is in "C:\Users\ltunnell\AppData\Roaming\ESRI\Desktop10.0\ArcCatalog" looks the same (although most of it is garbled, you can see the main setup). In may ArcObjects code, I can use either a propertySet or point to this connection file and he will get THE SAME error. I am confused as to why his username is being inserted into the location where "DBO" should be.
-We are using Operating System Authentication.
-This is the only user with this problem
-We are currently using a hybrid system...although it is to change soon: Our ArcGIS Server and SDE is in version 10.0 and many of our users have upgraded ArcMap to 10.3. All of the other users started using the system under a full 10.0 system...this is the first user we have had since the hybrid way of doing things.
If this is a 10.3 issue, we still have computers that run ArcMap 10.0 so I am not opposed to completely deleting his credentials and recreating them. But, I don't want to do that if it is something else or if it is fixable in a different way.
Any ideas on what I can try??? Where I should look??
not sure I understand this correctly, but here's a try: I assume you're using MS SQL Server, otherwise there wouldn't be a DBO around. So your user sets up a database connection using OS autehtication - this seems to indicate that there is a login in your SQL Server instance (e.g. AD user or AD group) that fits your user. Now, if someone else wants to use that connection information, they, too, need to be matched to a login in the SQL Server instance - that doesn't seem to be the case, so I'd suggest you check, and may be post here, the login situation in your database instance.
I'm not aware of a functionality that magically replaces the credentials in the SDE connection with DBO (I assume that you have set up your SDE schema to be owned by DBO), but then, I'm fairly new to SQL Server...
Sorry for any confusion: Yes, we have a SQL SDE geodatabase using DBO schema. The way we are set up is that we are using Operating System Authentication, and all of our users are in a group called "GISusers". So, when Joe makes a connection to a geodatabase and adds a layer into a map, then John can open the map and does not have to re-do the database connection to see the layer...it now uses HIS login information to make the connection and displays everything.
In this case, John, Joe, and Mary are all in the "GISusers" group and a connection is made for each of them using Operating System Authentication. If John makes a map, Joe and Mary can open the map on their computers and see everything just fine. But, if Joe makes a map, John and Mary open the map on their computers and the link to the data is broken. If John or Mary try to "Set data source" in the Source tab they get an error that says "bad login". The only way to repair it is to "Repair Data Source". If Mary repairs the data source, then it will be repaired for John also. Joe will still be able to see it, too.
So, John and Mary (and everyone else in the office) can set data sources that work for everyone else, and Joe cannot. I don't know why because we have re-set the connection multiple times and we are setting it up the SAME way for everyone. Joe can make a connection to the database using ArcCatalog, and can also go into SQL directly and make a connection to the database (using Windows Authentication). No problems in making the connection...everything looks fine when looking at Joe's computer.
The ArcObjects stuff I posted may provide a little more insight just because I am actually getting an error with how the connection is being interpreted. The program that Joe is using is the same program that everyone else in the office uses with no problems. So, there is not a problem with the code, and we KNOW that everyone is connecting in THE SAME way (the code is generic for everyone) but yet Joe cannot connect to the database using the program.