Stopping/Blocking Direct Connections

4319
6
10-13-2014 04:09 PM
JoeBorgione
MVP Emeritus

I manage an SDE database (10.0) with a SQL Server 2008 r2 back end.  I have a few clients that prefer to use direct connects instead of the 'classic' ArcCatalog client connection.  That's cool, but how to I get rid of their sessions if I need to boot them off?  I can't seem to get sdemon -o kill -t <pid> to work for them.

Is there any way to temporarily block direct connects?  Today I sent out an email to all my users to get off the SDE, but who reads emails these days?  I guess the direct connect clients I have don't.....

That should just about do it....
0 Kudos
6 Replies
JaredStewart
New Contributor II

I don't know if this will work for direct connects or not, but it might be worth a shot.

Disconnect All Users from a Geodatabase and stop accepting connections

Or specifically from that thread: ArcGIS Help (10.2, 10.2.1, and 10.2.2)

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

Hi Joe,

It's been awhile since I used SDE 10.0, but I used to have to kick user connections all the time.  I created a couple .bat file so all I needed to add the <pid> and/or the <service/port number> ...typically default 5151 for me, although  I had several (5152, 5153, etc).   

All I needed in the .bat was:

     sdemon -o kill -i %1 -s <servername> -t %2 -p <admin password>

where the first argument (%1)   would be 5151  or the service/port number     (or hardcoded if only one service/port/DB)

and the second argument   %2  was the <pid>

This made it faster if I had multiple connections to kill.

I had several other .bat files, pretty rudimentary, to help me view the connections, shutdown the services, start it back up etc.  Shutting down the service would stop all connections, I think, but now that I think about it maybe direct connections still work.   Like I said, been a while.    Bottom line,   I would try adding  the   "-i" and the  "-s"   arguments  (if I remember correctly, it will prompt for the password).

BTW - 10.2.x (and maybe 10.1.x) are all direct connect and the tools are easier thru arccatalog.  i know that doesn't help if your on 10.0, but might give motivation to upgrade. (??).  Always make sure you have a backup first of course.

Good luck!

0 Kudos
JoeBorgione
MVP Emeritus

Thanks Rebecca-  I don't need any motivation to upgrade: the third party vendor that we use needs the motivation....

That should just about do it....
0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

good luck with that....  

0 Kudos
SusanJones
Occasional Contributor II

What version of ArcGIS Desktop are you running - version 10.1 or higher?

arcpy has included AcceptConnections, DisconnectUser and ListUsers.

I have not tested out against the ArcSDE 10.0 database, but these have been my preferences these days for managing users during scheduled system maintenance tasks.

0 Kudos
AbhishekSingh
New Contributor III

Hi Joe,

I am sure that you are aware that the number of users that are connected to the GeoDatabase can be viewed in SDE.SDE_Process_Information table. At times, when the users are disconnected abruptly it can lead to orphaned entries in this table. You can check this by looking at the time since when the connection has been made, if it is dated old it might be an orphaned entry, if it is recent you can get the Node (machine) name from where the connection has been made. This table will also allow you to check if the connection has been made by a user or if it is coming from a published service. Once you know the source of the connection, you may further act for disconnecting users by all means . Some other related tables that you may have to look at is SDE_TABLE_LOCKS and SDE_STATE_LOCKS.

Well, the above mentioned method would be the wise way to go about it. Another way (not so wise) would be to alter the parameter CONNECTIONS of the SERVER_CONFIG table. You can do this by using command line -

sdeconfig -o alter -v CONNECTIONS =1 -i <connection string or SDE service port number> -s <server_name> -D <Database Name> -u <admin_user> -p <password>

The above mentioned command will only allow 1 user to connect with the database, the 2nd connection made to the GeoDatabase would encounter an error - "Unable to connect to database. Maximum number of connection exceeded to instance."

Once you have completed with your task, don't forget to change parameter CONNECTIONS back to its original value.

-Abhishek

0 Kudos