Arcpyスクリプトを使用している場合、10.1 ではデータロックの問題がさらに問題になります。
コードによってロックが作成されている場合は、自分でクリーンアップしているわけではありません。フィーチャクラス、ワークスペース、カーソルなどへのすべての参照を解放します。ロックされているオブジェクトへの参照がなくなると、ロックが解除されます。
まあ、それはそれが動作するはずの方法ですが、めったに動作しません。通常、コードは時々動作しますが、多くの場合、さまざまな場所で不可解にクラッシュします。
問題は、ロックが「しばらく」そこに残っているだけのように見えますが、コードはロックが解除される速度よりもはるかに速く実行されます。ただし、組み込みのArcツールのいくつかは、ロックをオンデマンドで強制的にクリアするように見えます（ロックはGDB全体に一度に適用されるため、ロックにより、含まれているフィーチャクラスを操作できなくなります）。これらのツールはarcpy.Compact_management（）およびarcpy.Exists（）です。
信頼性を劇的に向上させたコード内で使用する小さな関数を次に示します（複数のGDBおよびフィーチャクラスを作成および編集するスクリプトの場合）。
def clearWSLocks(inputWS):
'''Attempts to clear locks on a workspace, returns stupid message.'''
if all([arcpy.Exists(inputWS), arcpy.Compact_management(inputWS), arcpy.Exists(inputWS)]):
return 'Workspace (%s) clear to continue...' % inputWS
else:
return '!!!!!!!! ERROR WITH WORKSPACE %s !!!!!!!!' % inputWS
ワークスペース（GDB）パスを関数に渡すだけで使用され、ワークスペース（GDBの作成）またはワークスペース内のフィーチャクラス（カーソル、フィールドの追加、計算など）のすべての操作の後に行う必要があります。 。例（ここでは、関数が上部にあるスタンドアロンスクリプトとして示されています。関数を使用するには、以下に示すように、インポートと実際のプログラムの間に関数をコピーして貼り付けます）：
import arcpy
def clearWSLocks(inputWS):
'''Attempts to clear locks on a workspace, returns stupid message.'''
if all([arcpy.Exists(inputWS), arcpy.Compact_management(inputWS), arcpy.Exists(inputWS)]):
return 'Workspace (%s) clear to continue...' % inputWS
else:
return '!!!!!!!! ERROR WITH WORKSPACE %s !!!!!!!!' % inputWS
GDBpath = 'C:/Temp/'
GDBname = 'Test.gdb'
tableName = 'SweetFC'
arcpy.CreateFileGDB_management(GDBpath, GDBname)
print(clearWSLocks(GDBpath+GDBname))
arcpy.CreateTable_management(GDBpath+GDBname, tableName)
print(clearWSLocks(GDBpath+GDBname))
# etc....