3

「タイムアウトの期限が切れました」というエラーが発生しているストアド プロシージャがあります。

関連するコードは ADO/VB6 です。

ストアド プロシージャ自体は問題ありません。クエリ ウィンドウで実行でき、1 秒もかかりません。

接続などを取得するために使用されるコードもモジュール化されており、巨大なアプリケーション全体で使用されています。1 つの特定のデータベースでタイムアウトが発生するのは、この 1 つの場所だけです。

エラーは、VB6 コードをデバッグで実行するかどうかに関係なく、何百回も試行するたびに再現可能であり、突然すべてが魔法のように再び機能し始めます。その後、しばらくすると同じ問題が再び発生します。

ここにどれだけのコードを記述すればよいかわかりませんが、複雑なことは何もありません。それは基本的にです。

Set adoCommandObject.ActiveConnection = ...{open ADODB.Connection object}
Set rs = CreateObject("ADODB.Recordset")
Call rs.Open(adoCommandObject, , adOpenForwardOnly, adLockReadOnly)'Timeout occurs here

私はプロファイラーで見てきましたが、sp の実行前後に "SET NO_BROWSETABLE ON" / "SET NO_BROWSETABLE OFF" ステートメントが発生することがあります。

私はネットを検索しましたが、これに関する満足のいくヘルプを見つけることができませんでした。この時点で、私は喜んで何でも試してみます (残念ながら、.NET での書き換えはオプションではありません!)

4

2 に答える 2

3

あなたはこれを考えすぎていると思います。不快感はありませんが、MSSQLを使用している場合は、誰かがクエリウィンドウを開いたままにして、データベースを拘束するのと同じくらい簡単です。これは簡単にテストできます。私は以前に同じ問題を抱えていました。タイムアウトが発生しない前にストアドプロシージャを実行しました。通常はすぐに実行されますが、夜間は実行されずに実行されます。別の従業員を見つけるためだけに、クエリウィンドウを開いたままにしました。彼らのウィンドウを閉じて、それがついに実行されます。これをチェックしてください、あなたはテーブルロックがあなたのアプリケーションに何ができるかに驚くでしょう。

問題が断続的であるとあなたが言ったので、私はこれを言います。それは行き来します。テーブルロックの疑いがあります。それを実行しているアプリケーションであるか、DBにクエリを実行している別のユーザーによって実行されているかどうか。別のユーザーでない場合は、アプリケーションが使用されるたびに、アプリケーションがDBへの接続を閉じていることを確認してください。

于 2009-06-24T14:49:53.767 に答える
0
  • 接続またはコマンドのタイムアウトを誤って非常に小さな値に設定するコードが潜んでいる可能性があります。
  • サーバーが何か他のことをしている場合や統計が古くなっている場合など、手順の実行に時間がかかることがあります。
  • プロファイラーを使用してタイムアウトのケースをキャプチャできますか? その場合、proc の実行に実際に時間がかかりますか?

here で説明されているように、SET NO_BROWSETABLE ON は、選択でFOR BROWSEを使用するのと似ています。そのレコード セットを更新する必要があると思われる場合、ado によって自動生成されると思います。これらの発行を停止するように設定できる Recordset のプロパティがおそらくありますが、それが問題である可能性は低いと思われます。

于 2009-05-22T18:15:03.983 に答える