SDE instance not found in services file killing a lock with 10.2 GDB Admin Window

2833
9
Jump to solution
12-27-2013 07:18 AM
Highlighted
New Contributor II
Hi,

I recently inherited an SDE database that desperately needs a compress. When I attempt, it fails because of a db lock. I attempted to kill the db lock using the 10.2 GDB Admin window and got the "SDE instance not found in services file" error. Screenshot attached.

SDE is running on a separate server:

Windows Server 2003 R2
SQL SERVER 2008 R2
ArcGIS 9.3.1 with no service packs

Is there anything I have to do to be able to kill locks from the db admin window?
1 Solution

Accepted Solutions
Highlighted
MVP Regular Contributor
Upgrading your ArcSDE service to 10.2 would ensure Esri support, and it may help / ensure proper functionality with the admin tools.  Either way, you should not mix and match versions in an unsupported or uncertified manner.  Remember, too, that if you upgrade your ArcSDE service then your GDB itself must also be upgraded from 9.3.1 to 10.2.  The ArcSDE service itself will be deprecated at 10.2.1 just FYI. 

You can use command line OR the Desktop admin tools from your screenshot to kill sessions.  I thought you said that you could kill sessions from the Desktop GUI on the server itself.  If so, you don't need to use the command line if it works.  But, if you want to use a tool of similar version (or if you don't have Desktop installed on the server), then yes you can use the 9.3.1 ArcSDE command line tools via a command prompt:

sdemon -o kill -t <{ all | pid }> [-p <ArcSDE_admin_password>] [-N]
{[-i {<service> | <port#> | <direct connection>}]
[-s <server_name>] | [-H <sde_directory>]}
[-u <user_name>] [-p <user_password>] [-D <database_name>]

View solution in original post

Reply
0 Kudos
9 Replies
Highlighted
MVP Regular Contributor
On the machine from which you are connecting with in order to attempt a connection kill, you need to enter the name of the SDE service along with a port number into your services file.  The services file is located at the following locations depending on OS:

Windows 95 - C:windows
Windows 98 - C:\windows
Windows Me - C:\windows
Windows 2000 - C:windows\system32\drivers\etc
Windows XP - C:\windows\system32\drivers\etc
Windows NT - C:\winnt\system32\drivers\etc
Windows Vista - C:\windows\system32\drivers\etc

Toward the bottom, make an entry like the following:

esri_arcsde      5152

The esri_arcsde should be replaced with the actual name of your ArcSDE service and the port number should be the same as the port it's running on.  Use a tab in between these values.  Also, be sure the services file has a blank line at the very end of it so that the ArcSDE service is not the very last line in the file.
Reply
0 Kudos
Highlighted
New Contributor II
I have checked, and the following line does appear in the services file...

esri_sde 5151/tcp

Any other options to try/check?
Reply
0 Kudos
Highlighted
MVP Regular Contributor
Are you certain that the version of your ArcSDE service matches that of your client?  Can you connect from the server itself?
Reply
0 Kudos
Highlighted
New Contributor II
Yes, I can connect to SDE from the server itself. I guess I'm not sure if the version of the ArcSDE service matches the client. The version on the server is 9.3.1 and the client is 10.2. Is that what you are referring to? I can verify that both have the correct entry in the services file.

thx
Reply
0 Kudos
Highlighted
MVP Regular Contributor
Ok, it sounds like connectivity shouldn't be an issue in terms the fact that you can connect from the server itself.  From an Esri software version standpoint, the following article suggests that 10.2 clients are not supported when connecting to 9.3.1 GDBs:

http://resources.arcgis.com/en/help/main/10.2/index.html#//002q000000n8000000

I'm not sure if this is exclusive to direct connect and EZCONNECT, or if it includes ArcSDE service connections as well. 


That being said, could you please disable Windows Firewall and any other firewall / anti-virus software temporarily on your client machine to see if you can connect?  In the meantime, go ahead and make your connection kills from the server itself for now.
Reply
0 Kudos
Highlighted
New Contributor II
The provided article was helpful. I should have spent more time in the help. Unfortunately, I can't turn off the firewall on my own PC. The security settings are managed by someone else. To kill locks on the server itself, would I use cmd line?


Based on the article, sounds like upgrading SDE to 10.2 will ensure I can use the 10.2 admin tools.
Reply
0 Kudos
Highlighted
MVP Regular Contributor
Upgrading your ArcSDE service to 10.2 would ensure Esri support, and it may help / ensure proper functionality with the admin tools.  Either way, you should not mix and match versions in an unsupported or uncertified manner.  Remember, too, that if you upgrade your ArcSDE service then your GDB itself must also be upgraded from 9.3.1 to 10.2.  The ArcSDE service itself will be deprecated at 10.2.1 just FYI. 

You can use command line OR the Desktop admin tools from your screenshot to kill sessions.  I thought you said that you could kill sessions from the Desktop GUI on the server itself.  If so, you don't need to use the command line if it works.  But, if you want to use a tool of similar version (or if you don't have Desktop installed on the server), then yes you can use the 9.3.1 ArcSDE command line tools via a command prompt:

sdemon -o kill -t <{ all | pid }> [-p <ArcSDE_admin_password>] [-N]
{[-i {<service> | <port#> | <direct connection>}]
[-s <server_name>] | [-H <sde_directory>]}
[-u <user_name>] [-p <user_password>] [-D <database_name>]

View solution in original post

Reply
0 Kudos
Highlighted
New Contributor II
Like I said, I inherited this mixed version mess. I will look into upgrading SDE to 10.2. I can't kill the locks from the GUI on the server because it is 9.3.1 There is no GUI to kill locks. I will use the provided command line to do the job.
Reply
0 Kudos
Highlighted
MVP Regular Contributor
Yep, I understand you inherited it all... I've been through similar challenges.  It looks like the error you're getting is due to the version mismatch to begin with.  The command line tools should work just fine for you to make the connection kills.  Good luck!  Please also mark helpful answers and the correct answer for others who encounter the same types of challenges.
Reply
0 Kudos