Table To Domain failing - Cannot get exclusive schema lock

2139
6
08-16-2010 02:05 PM
RandyKreuziger
Occasional Contributor III
I'm the only one logged into SDE right now but can't update a domain using the TableToDomain command.  It says I can't get an exclusive schema lock but with no one else on what could it be?  I just created the the SDE and no one but myself has a login so I know there is just me.
Below is the TableToDomain dialog.  ArcSDE 9.3.1 64-bit, SQL 2008 64-bit


Executing: TableToDomain "Database Connections\GIS_Common.odc\dbo.ws_FileLocation_LUT" FileLocation_Code FileLocation_Desc "Database Connections\2008 GeoScratch.sde" dFileLocation "File Location" REPLACE "Database Connections\2008 GeoScratch.sde"
Start Time: Mon Aug 16 14:20:56 2010
ERROR 000464: Cannot get exclusive schema lock.  Either being edited or in use by another application.
Failed to execute (TableToDomain).
End Time: Mon Aug 16 14:20:57 2010 (Elapsed Time: 1.00 seconds)
0 Kudos
6 Replies
AlexeyTereshenkov
Regular Contributor III
Hey

You can try restarting an ArcSDE service (if applicable) to release possible locks. Thereafter, you can always check if you got any orphaned connections to the service (if not using direct connection).

Close ArcCatalog and any other applications that could consume the sde database you are working with. Use the commands as below:

To show who is connected to an ArcSDE service:
Sdemon -o info -I users -i <servicename> -p <sdepassword>

To kill all connections to an sde service:
Sdemon -o kill -t all -i <servicename>

If you are using direct connection, it is going to be a bit harder.

To kill a direct connect to an sde database:
Ths can be done either by restarting SQL Server database engine or by using SQL Server Activity Monitor, tracing the locked processes, and killing those processes. These things are being done on the SQL Server level, because direct connection has nothing to do with sde services �?? all users connect directly to the SQL Server database engine bypassing sde.

Tell us if you succeed.

PS. Hope you did not compressed the dataset, since compressing datasets in a file geodatabase makes them read-only.
0 Kudos
RandyKreuziger
Occasional Contributor III
There are no locks on the database nor are there any orphaned gsrvrs.  But just to be safe I restarted the SDE service.  I ran the TableToDomain again and got the same error. 

So then just to make sure I had enough permissions I ran it and created a new domain.  Then I ran it a second time to try and replace the existing domain but it failed with the same error message as before.  Has anyone else seen this?

I'm using an ArcSDE 9.3.1  64-bit, SQL 2008 64-bit.
0 Kudos
AlexeyTereshenkov
Regular Contributor III
Hey

Well, if this does not help, then you can refer to this forum post, there might be some help. Someone suggested to convert file geodatabase to personal and then export the personal to file geodatabase again. It should be time consuming though.

http://forums.esri.com/Thread.asp?c=93&f=985&t=206951
0 Kudos
RandyKreuziger
Occasional Contributor III
Someone suggested to convert file geodatabase to personal and then export the personal to file geodatabase again.


I'm not using a file geodatabase.  The problem is with an ArcSDE (SQL 2008) geodatabase.  Exporting it is not an option.
0 Kudos
CherylCleghorn
Esri Contributor
Please contact Technical Support so that they can help you in troubleshooting this issue.

Thanks
Cheryl
0 Kudos
ThomasRoussell
New Contributor III

I recently had this problem and found that once the domain is assigned to a column in a feature class in my SDE, any lock on the feature class will also lock the domain. Once I disconnected all users from the feature class and closed arc catalog (in case I was also creating a lock), my python script would run without the error.

0 Kudos