0

私は C++ アプリケーション (SQL 2000 データベースに対して Windows 2000 サーバーで実行されている VS2003 でコンパイルされたもの) を持っています。

私のロギングは、データベース接続（SQL Serverドライバーを使用するODBC）が正常に機能することを示しています（データベースの読み取りと更新）、例外がスローされた後（キャッチ/ログに記録されますが、実際の詳細はありません）、接続はデータベースからデータを読み取ることができますが、データベースを更新できなくなりました。

そのため、スレッドが次の行を読み取って処理し、ソケットから別のサーバーにデータを送信し、処理済みのレコードを更新して BOOM しようとしていることがわかります。

失敗したクエリから返される唯一のエラー情報は次のとおりです。

[Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared.  [37000]

通常、クエリが失敗した理由が表示される場所のような空白が続きます (構文が正しくない、テーブルが見つからないなど、何でもありますが、今回は何もありません)。

このコードは何万ものレコードを処理し、数か月間実行される可能性があり、このスレッドの直後 (常に最初の被害者のように見え、最も忙しく、最初に攻撃される可能性があります) が他のすべての接続を窒息させ始め、同じ問題があるようです -読み取りは許可されていますが、更新によってこの例外がスローされます。

前回、タスク マネージャーをざっと見たところ (すぐにバウンスするので、長く調べることはできません)、アプリは典型的な 5 ～ 6 メガの RAM を使用しており、他のリソースは正常に見えました。

他のアプリケーションがデータベースを使用しており、この間エラーはありません。

クエリが有効な場合に、この報告されたエラー結果が得られる場所をオンラインで見つけることができません...

ヘルプ！

4

2 に答える 2

0

エラーから、「[Microsoft] [ODBCSQLServerドライバー][SQLServer]ステートメントを準備できませんでした。[37000]」ODBCドライバーがステートメントを準備しようとしていると思います。これは私たちに多くの不安定な問題を引き起こしました。

ODBCデータソースの定義で、[準備されたSQLの一時ストアドプロシージャを作成する...]オプションのチェックを外し、これでエラーが修正されるかどうかを確認します。

于 2009-06-10T20:41:23.653 に答える
0

null が許可されていない場合、 update ステートメントがそのフィールドまたは null に対して大きすぎるデータを書き込んでいる可能性はありますか?

おそらく、更新をファイルに記録して、問題がデータ駆動型かどうかを判断できます。

SQL Server の ODBC ドライバーが ADO​​ を使用しているかどうかはわかりませんが、ADO の更新コードと挿入コードにリークがあり、徐々にすべてのメモリを消費するのではないかと思います。ほぼ同じ数のレコードの後に​​一貫してクラッシュが発生する場合は、調査することをお勧めします。

于 2009-06-11T03:12:10.243 に答える