3

私はpyodbcを非常に短い期間使用していますが、ビューの作成を実行するファイルからSQLスクリプトを適用するという問題に直面しています。SQLファイルを適用するために私は別のスレッドからのサンプルを使用します-フォローアップ：Pythonから.sqlファイルを実行します 私のSQLスクリプトの大部分に問題はありませんが、これは問題を引き起こします：

スクリプトの一部：

insert into TMP_VIEWS select * from TMP_QUERY_SQL
go
begin
declare @SQL_CMD varchar(4000);
declare @CNT int;
set @CNT = (select count(1) from TMP_VIEWS);
while @CNT > 0
begin 
  set @SQL_CMD = (select top 1 SQL_CMD from TMP_VIEWS order by SQL_CMD);
  print 'Executing: ' + @SQL_CMD;
  EXEC(@SQL_CMD)
  delete from TMP_VIEWS where @SQL_CMD = SQL_CMD;
  set @CNT = (select count(1) from TMP_VIEWS);
end
end

ご覧のとおり、別のテーブルからテーブルに挿入されたSQLステートメントの実行を実行します。だから私がそれを適用する方法ではそれは機能しません。別のスレッドからのサンプルは、SQLファイルをGO間のブロックに分割し、それらを適用します。したがって、「TMP_VIEWSに挿入し、TMP_QUERY_SQLから*を選択します」を個別に適用してから、他の部分を適用します。pyodbcまたはドライバーは、サーバーでの挿入の完全な実行を実際には待機せず、実際の挿入が完了する前に2番目のブロックが実行されるようです。その結果、かなりランダムな量のビューが作成され、作成されていないクエリがTMP_VIEWSに残りました。自動コミットがあり、クエリの実行後にコミットを追加しようとしましたが、これは役に立ちません。役立つ唯一のこと-GO間のこのバッチの実行の間にtime.sleep（0.2）を追加します。非同期呼び出しのように見えます。誰が同じ問題に直面しているのですか、それとも私の試みで何が間違っているのでしょうか？いくつかの回避策がありますか？

ありがとう！

4

1 に答える 1

0

この特定のスクリプトの解決策が必要な場合は、次の手順を実行します。TMP_QUERY_SQL テーブルからすべての SQL ステートメントを Python リストに読み込みます。次にexcecute、リストを繰り返し処理しながら各ステートメントを呼び出し、一時 SQL テーブル TMP_VIEWS への依存を回避します。

于 2015-10-10T14:48:35.553 に答える