3

すべての注文を一覧表示するデータベーステーブルがあります。毎週末にcronが実行され、顧客ごとに請求書が生成されます。コードは各顧客をループし、最近の注文を取得し、PDFを作成してから、注文テーブルを更新して、各注文に対する請求書IDを記録します。

最終的な更新クエリは次のとおりです。

予約の更新setinvoiced= '12345' where username ='test-username' and invoiced ='';

したがって、以前に請求されていないtest-usernameのすべての注文について、invoicedを12345に設定します。

注文がPDFに追加されているが、請求されているという事実を反映するように更新されていないという問題が発生しました。

更新クエリを手動で実行し始めましたが、奇妙なシナリオに遭遇しました。

顧客は60の注文があるかもしれません。

クエリを1回実行すると、1つの注文が更新されます。もう一度実行して1つの注文を更新し、プロセスを繰り返します。更新される注文の数が1から3の間であるたびに、1つのクエリで60が更新されません。最終的に「影響を受ける行が0」になるまでクエリを繰り返し実行する必要があります。そうすれば、すべての行が更新されたことを確認できます。

クエリにLIMITXXを含めていないので、すべての注文を一度に更新できない理由はありません。繰り返し実行するクエリは毎回同じです。

誰か賢い提案はありますか？！

4

1 に答える 1

3

InnoDBを使用していると思います。実行しているコードの種類を開示していません。

しかし、トランザクションに関連する問題が発生しているに違いありません。プログラムがインタラクティブセッションとは異なる動作をする場合、それは多くの場合トランザクションの問題です。

ここを参照してください：http： //dev.mysql.com/doc/refman/5.5/en/commit.html

ステートメントのCOMMIT;直後にコマンドを発行すると、状況はより良く機能しますか？UPDATE

言語バインディングには、コマンドを発行する独自の好ましい方法がある場合があることに注意してくださいCOMMIT;。

この問題を処理する別の方法は、SQLコマンドを発行することです。

 SET autocommit = 1

接続を確立した直後。これにより、データを変更するすべてのSQLコマンドが自動的にCOMMIT操作を実行します。

于 2013-03-19T17:57:42.903 に答える