0

freeodbc++ライブラリを使用して、MS SQL Server 2000 データベース (SP3? SP4?) のデータにアクセスしています。特に、非常に長く厄介なストアド プロシージャを実行しています。SQL Profiler でプロシージャの実行を監視できますが、特定の時点で処理が停止する傾向があります。エラー コードや例外はスローされません。常に最後のステートメントであるネストされたステートメントをコメントアウトすると、コメントの少し前で終了します。私は根本的に全体をコメントアウトしようとはしていません...クエリのタイムアウトを300秒に設定しています。callable ステートメントは通常、実際に SP を終了することなく、1 秒以内に戻ります。

何か案は？

UPDATE0: Query Analyzer またはその他のツールを使用して SP を実行すると、動作します。失敗するのは、ODBC接続を介しただけです。

UPDATE1:コードをコメントアウトすると、実行はさらに SP で終了します。私が実行しているタイムアウトまたはバッファ制限があると思わせます。

4

4 に答える 4

0

TRYとCATCHを使ってみましたか？ストアドプロシージャ内の関数呼び出しで、表示されないエラーがスローされる可能性があります。

BEGIN TRY
 <Your code>
END TRY
BEGIN CATCH
        DECLARE @ErrMsg nvarchar(max),
            @ErrSeverity int,
            @ErrState int
    SELECT  @ErrMsg = ERROR_MESSAGE(),
            @ErrSeverity = ERROR_SEVERITY(),
            @ErrState = ERROR_STATE()

    RAISERROR (@ErrMsg,@ErrSeverity,@ErrState);
END CATCH
于 2008-10-15T20:43:06.833 に答える
0

SPIDで何が起こっているかを確認するために、SQL Server側でプロファイリングを試しましたか？

また、私はfreeodbc ++を使用していませんが、おそらくそこにPRINTステートメントがあります。NOCOUNT ONを設定して、行数メッセージを抑制することもできます。繰り返しますが、これはfreeodbc++がこれらの「情報」メッセージにどのように反応するかに依存します。

あなたが説明するこの「フリーズ」スタイルの動作に基づくと、freeodbc++のバグのように聞こえます。SQL側でプロセスを調べて、実際にハングしているかどうか、またはライブラリが「死んだ」かどうかを確認することから始めます。

于 2008-10-15T22:21:10.770 に答える
0

クエリ アナライザーから手順を実行し、何が起こるかを確認します。プロシージャで RAISERROR() 関数を使用して、トレース情報をメッセージ ウィンドウに表示し、デバッグに役立てることができます。

于 2008-10-15T20:21:04.227 に答える
0

「::Sleep(30000);」を追加 ODBC ステートメント オブジェクトで execute を呼び出した直後 (およびステートメントを閉じるコマンドの前) は、サーバー プロセスが途中で終了するのを防ぎます。freeodbc++ のバグか、私の構成エラーに違いありません。

トラブルシューティング/デバッグのヒントをありがとう。

于 2008-10-17T12:55:54.763 に答える