0

一時テーブルのガベージコレクションで問題が発生しているようです。

CREATE PROCEDURE dbo.SetTestTempTable(@value bit)
AS
SET NOCOUNT ON
IF OBJECT_ID('tempdb..#TestTempTable') IS NOT NULL 
    DROP TABLE #TestTempTable
SELECT @value AS Value INTO #TestTempTable

GO

EXEC dbo.SetTestTempTable 1
SELECT * FROM #TestTempTable

上記のコードはエラーを生成します

Msg 208, Level 16, State 0, Line 3
Invalid object name '#TestTempTable'.

procが終了すると#TestTempTableがガベージコレクションを取得しているためだと思います。

これを防ぐ方法はありますか？プロシージャを呼び出す前に、すべての呼び出し元が明示的に一時テーブルを作成する必要がないようにします。

更新：なぜ私はこれをしているのですか？

コンテキスト情報（基本的にはセッション変数）を保存する必要があります。これにはCONTEXT_INFOを使用していました。SQL AzureはCONTEXT_INFOをサポートしていないため、それに応じてリファクタリングしています。基本的に、私には次の機能があります。

GetMySessionVariableName（）

と手順

SetMySessionVariableName（value）

以前は、この関数とプロシージャは内部でCONTEXT_INFOを使用していましたが、これは正常に機能していました。さて、一時テーブルでは、そうではありません...私は別のアプローチについての提案を受け入れています。

4

2 に答える 2

6

ストアドプロシージャがスコープ外になると、＃tempテーブルはドロップされます（まあ、遅延ドロップされます）。したがって、ストアドプロシージャの範囲外では利用できません。プロシージャの終了後に#tempの内容を表示するには、ストアドプロシージャを実行する前に作成し、その中にデータを入力する必要があります...またはストアドプロシージャ内で選択を実行します。

更新された要件については、UserIDのキーを持つ永続テーブルを使用し、ストアドプロシージャを更新してUserIDをパラメーターとして使用しないのはなぜですか？すでにUsersテーブルがある場合は、更新されたセッション情報を1つまたは2つの列に確実に格納できます。CONTEXT_INFOまたは#tempテーブルのナンセンスは必要ありません。

于 2012-06-25T21:36:48.447 に答える
0

この問題に対して私が見つけた解決策がありましたが、私自身はそれが信頼できるとは思いませんでした。それは2つの異なる接続文字列を持つことについてでした：

  1. マスターデータベース接続文字列を使用してマスターデータベースのコンテキスト情報を最初に設定する
  2. 2つ目は、通常のアプリケーションの接続文字列です。
于 2012-07-30T13:52:26.290 に答える