ArcGIS Python SearchCursorファイルのロック？

11

シェイプファイルのフィールドから値を取得してユーザーに返すスクリプトがあります。

arcpy.SearchCursorが呼び出されると、ArcMap 10.0がファイルをロックし、スクリプトの実行が終了した後も削除されないようです。ロックを解除するには、ArcMapを閉じる必要があります。スクリプトでは、SearchCursorオブジェクトと行オブジェクトを使用した後に削除します。

スクリプトを機能させる方法は、以降の実行でワークスペースフォルダーを削除しようとしますが、ロックのためにできないことです...もちろん、ArcMapを閉じるまでです。

このロックを解除するためのアドバイスはありますか？

— ジャスティン
ソース

4

問題は次のようになった後に解決されました。

rows = arcpy.UpdateCursor(fc)   
delete = rows.deleteRow  
for row in rows:  
    delete(row)  
del row  
del rows

に

rows = arcpy.UpdateCursor(fc)
for row in rows:
    rows.deleteRow(row)
del row
del rows

— b.bacia
ソース

3

Pythonスクリプトで作成されたファイルジオデータベースおよびフィーチャクラスのロックを解除できません。を参照してください。同じ問題のように見えます。フィーチャクラスを明示的に削除することで、以前に回避しました。これがすべての場合に機能するかどうかはわかりません。

import arcpy

fcPath = 'c:/temp/features.shp'
idFld = 'OBJECTID'
cur = arcpy.SearchCursor(fcPath)
for row in cur:
    id = row.getValue(idFld)
    row = None
cur = None
r = arcpy.Delete_management(fcPath)

print r.getOutput(0)

ガベージコレクションの強制も同様に機能する可能性がありますが、私の予想では、これはarcpyまたはArcMapの内部動作と関係があるということです。

import gc
gc.collect()

— ターレン
ソース

カーソルの各反復後に行参照を削除する必要があるため、これを編集しました。そうしないと、ループ外の呼び出しが不要になります。これは、私が同じ問題を抱えていたときにそれを回避する唯一の方法として投票したものでもあります。

— 毛深い

@ヘアリーOK、でもミュートポイントだと思います。Python は、新しい行オブジェクトが行変数に割り当てられると、反復ごとに前の行オブジェクトへの参照を減らします。ループの後、最後の行の割り当てが単純にクリーンアップされます。それをループ内に移動すると、作業が重複します。いずれの場合でも、arcpyまたはArcMapが行オブジェクトへの参照を内部的に保持していない限り、ガベージコレクターはメモリの割り当てを解除する必要があります。row = None

— ターレン

反対することに同意しても大丈夫、または論点である。arcpyのガベージコレクションに欠陥があることは知っています。実際にオフにすると、かなり速くなります。行で何も設定されていない行に関しては、その方がうまく機能することを知っています。何も設定しないことは不要だと言う人もいますが、そうではありません。スクリプトの開始時にガベージコレクションをオフにして、時間差を測定してください。私はまた、行ない=何もない、デルの行を使用していますが、それはまた別のdicussionです：試し輸入GCのgc.disable（）

— 多毛

@ Hairy、GCを無効にすることは私にはありませんでした。試してみます。

— ターレン

フィーチャクラスが必要なため、これは機能しません。また、後で別のフィーチャクラスでUpdateCursorを取得し、これもロックされます。最終的には、鏡と手品を使って必要な場所に行きました。どれくらい長く続くかわからない。ありがとう。

— ジャスティン

1

ArcMap内からArcPyスクリプトを実行する必要がありますか？作成したインターフェイスまたはツールボックスの一部でない限り、Pythonコンソール、IDLE、EclipseなどからArcMapの外部で実行できます（実行しているマシンに適切なライセンスがある場合）。この場合、小さなPythonコードを記述してArcPyスクリプトをサブプロセスとして生成し、サブプロセスが閉じたときにロックを解除する必要があります。

ArcGISのロックは面倒です。マシンをシャットダウンした後でもロックが保持される状況がありましたが、これは非常に大きな痛みです（通常、ロックを片付ける前にArcがクラッシュした場合）。最後の手段として、これが発生した場合は、Windowsエクスプローラを使用して.LOCKファイルを見つけ、手動で削除します。これは、ArcMapまたはPythonプロセスからアクセスされている場合は機能しないため、比較的安全です...しかし、これは実際にはGet-Out-of-Jailカードであり、良い習慣ではありません:)

— MappaGnosis
ソース

1

行オブジェクトとカーソルオブジェクトの両方を適切に削除して（例del row, rows：）、ロックが残っている場合、arcpyではなくArcMap自体がまだ参照している可能性があります。

シェープファイルは、コンテンツウィンドウ内のレイヤーによって参照されていますか、それともスクリプトツールによってTOCに追加されていますか？

後者の場合は、ArcMapの[ジオプロセシング]-> [ジオプロセシングオプション]で[ 表示にジオプロセシング操作の結果を追加]を無効にしてみてください。

追加の提案：これを一時/中間データセットとして実行していて、機能の数があまり多くない場合in_memoryは、シェープファイルの代わりにワークスペースを使用してロックの問題を完全に回避し、同様に素晴らしい潜在的なパフォーマンスの向上を取得してください。

スクリプトを終了する前に、削除（データ管理）を使用してin_memoryワークスペースまたはそこに作成した特定のデータセットを必ず削除してください。そうしないと、アプリケーションが終了するまでメモリに残ります。

最後に、シェープファイルのロック動作は10.0で変更され、コンテンツウィンドウからレイヤーを削除するときにロックファイルを削除しないことで、より厳密になることにも注意してください。この記事と関連する質問も参照してください。

— 238
ソース

これは間違いなくArcMapです。カーソルを呼び出すと、以前のカーソルロックが解除されると思います。fcでSearchCursorを呼び出し、次に別のfcでUpdateCursorを呼び出すと、前のロックがなくなります。ブラックボックススタイルを殺すロックを処理するためだけに削除する必要のないファイルで、3番目のダミーカーソルを呼び出すことができます。ありがとう。

— ジャスティン