Take the 2-minute tour ×

We have an issue where users do not close ArcGIS and layers get locked, and sometimes this affects our nightly updates for some of the layers. I know you can individually remove a lock using the ArcSDE command (which we do), but does anyone know of a way I can create a script that can be run every night to get rid of the locks?

We are running ArcSDE 9.2 and Desktop 9.3.1.


share|improve this question
What flavor/version of database - SQL Server, Oracle, etc.? –  Chad Cooper Jan 18 '12 at 12:16
add comment

3 Answers

up vote 1 down vote accepted

For this scenario I run the sdemon command from a python script using the following:

import subprocess
#Kill all ArcSDE connections
subprocess.call('sdemon -o kill -t all -u <sdeadminusername> -p <password> -N', shell=True)

#Kill all Direct Connections, (ArcGIS 10.0 only)
subprocess.call('sdemon -o kill -t all -i sde:sqlserver:SERVERNAME-u <sdeadminusername> -p <password> -D sde -N', shell=True)
share|improve this answer
'sdemon -o kill -t all -i sde:oracle11g -s SERVERNAME -u <sdeadminusername> -p <password> -D sde -N' –  Julien Jan 19 '12 at 13:47
add comment

Used to run into this problem a lot, and our DBAs had what they called "the kickout script" that they ran on the database, which in our case was SQL Server 2005/2008. Basically, you are killing all connections to the database, which boots out your users, which in turn releases the locks. We had to do this in order to run nightly updates on SDE featureclasses.

I'm not going to include any SQL here, as there are many ways to accomplish this. If you have a DBA (or know one), get with them, they should be able to help. For examples, here is a post on DBA.se for SQL Server and here is one on SO regarding Oracle. I'm including those two database flavors as they seem to be the most common out there for SDE.

You can then wrap up the SQL into a stored procedure and schedule the script to be run using something such as sqlcmd for SQL Server:

sqlcmd -S <machine_name> -E -d <database> -Q "exec <stored_procedure>"
share|improve this answer
add comment

The sdemon -o kill -t all switches will do the same thing except at the sde level.
You should try to have all connections closed prior to doing that.
It is not a bad Idea to also roll all versions up to default (if that is your model), and I normally compress the db before and after killing all state, table, and layer locks.
sdemon run alone will get you all the options including status, and info.

share|improve this answer
You're right, Brad. I'm pretty sure our DBAs did a sdemon -o kill -t all before they ran the SQL script to kick all users out at the DB level. –  Chad Cooper Jan 18 '12 at 14:32
I think if you kill all sde pids it will lose all connections. Perhaps they ran the kickout and then the sdemon? –  Brad Nesom Jan 18 '12 at 15:20
Not sure what the order was honestly, and that was at a past job. To us it was sort of a "black box" job that the DBAs ran, as we of course didn't have that level of access to production. –  Chad Cooper Jan 18 '12 at 15:55
In 9.x sdemon -o kill did not kill direct connections. That's probably why they ran the database level kick routine. –  Jeff Berry Jan 19 '12 at 1:06
Also, if you have map services running, it is necessary to stop those services as well. If you simply kill those connections, they will reestablish the connection if the map service is in use. See the answer to this question for a script to shutdown maps services. link –  Jeff Berry Jan 19 '12 at 1:22
show 1 more comment

Your Answer


