SQL Server 2000の：無効な列名 'bar' に

Question

私はちょうど状態3、レベル16、メッセージ207次のクエリは、エラー

を返すSQL Serverで2000

を奇妙なバグを見つけたと思います、7行
無効な列名 'bar' に

私はSQL Server 2005でまったく同じクエリを実行した場合、それが動作します。また、私がselect #weirdness.*の場合にも機能します。プロシージャで使用できるいくつかの回避策がありますか？私はgoが助けていることを知っていますが、手続きで使用することはできません。ところで、SQL Server 2000を取り除くつもりですが、時間がかかります。

select 1 as foo 
into #weirdness; 

alter table #weirdness add bar int identity; 

--select #weirdness.* --works 
select #weirdness.bar --fails 
from #weirdness; 

システム：

のMicrosoft SQL Server 2000の - Windows上で8.00.2066（インテルX86）2012年5月11日午前18時41分14秒
著作権（C）1988年から2003年、米国Microsoft CorporationのStandard Edition NT 5.2（ビルド3790：サービスパック2）

Answer 1

これは私が今考えている回避策です。

可能であれば、SQL Server 2005以降を使用してください。

可能分割の場合、複数のバッチにスクリプト（手順では不可能）：

select 1 as foo 
into #weirdness; 

alter table #weirdness add bar int identity; 

go --split into multiple batches 

--select #weirdness.* --works 
select #weirdness.bar --fails 
from #weirdness; 

は最初のテーブルを作成します。

create table #weirdness (
    foo bit 
, bar int identity 
); 

insert into #weirdness(foo) 
select 1 as foo; 

select #weirdness.bar 
from #weirdness; 

Answer 2

これはバグではありません、それは文書化された動作です。サイズについて

select 1 as foo into #weirdness; 
go 
alter table #weirdness add bar int; 
select #weirdness.bar 
from #weirdness; 

「バー」が存在しないと不平を言うと、SQL Server 2005でもこれが失敗することがわかります。

なぜ失敗するのですか？ 、のでthe documentationごとに、あなたがそれを行うには許可されていない：

テーブルを変更することはできませんし、新しい列は 同じバッチで参照します。

なぜ作成し、テーブルを変更してから、我々はSQL Server 2005の内の1つのバッチでそれを行う場合には、それにもかかわらず、仕事の参照ではなく、SQL Server 2000のでしょうか？これは文の再コンパイルと関連しており、これも上記と2005年の新機能です。

SQL Server 2005では、#weirdnessがバッチの先頭に存在しないため、SQL Serverはそれを参照するステートメント。 select .. intoが実行され、それを参照するすべてのステートメントが再コンパイル用にマークされます。これらのステートメントはコンパイルされ、1つずつ実行されます。 #weirdness.barを参照するまでに、作成されてコンパイルが成功します。

SQL Server 2000では、バッチの先頭に#weirdnessが存在しないため、SQL Serverはそれを参照するステートメントをコンパイルしません。 select .. intoが実行され、バッチ全体が再コンパイル用にマークされます。しかし、alter tableが実行されておらず、バッチが停止しているので、select #weirdness.barのコンパイルは失敗します。

したがって、ドキュメントは実際には「テーブルは変更できません。同じバッチで新しいカラムが参照されます。ただし、バッチが開始されたときにテーブルが存在しない場合を除き、 SQL Server 2005以降のものですが、それに頼るのはおそらくそれほど熱い考えではありません。なぜ彼らはそれをよりシンプルに保ったのか分かります。