1

I discovered SUDDENLY that in SQL Server (2000) any field type value may be treated as quoted string (in query or DML).

Question: Is it normal behavior or accidentally successful result?

Example: 
CREATE TABLE [Test_table] (
    [int_field] [int] NULL ,
    [float_field] [float] NULL ,
    [date_field] [datetime] NULL ,
    [id] [int] NOT NULL 
) ON [PRIMARY]
GO

update test_table set int_field = 100, float_field = 10.01, date_field = CAST('2013-11-10' AS DATETIME) where id = 1

update test_table set int_field = '200', float_field = '20.02', date_field = '2014-12-10' where id = '2'

select * from test_table where id in ('1', 2) -- WHY '1' DOES WORK!???

Why i need this? It exists idea to send in one Stored Procedure over 270 parameters as integral text (XML or custom serialization by delimiters or like Len1+value1+len2+value2+..) then parse and extract all desired values and use them in UPDATE statement. This SO Question.

Q2: Is there any limitations for some types? Q3: Is this reliable way or CAST anyway is recommended?

4

2 に答える 2

1

SQL Server は、ほとんどの (すべての?) ブランドの SQL と同様に、物事を正しい型に自動的にキャストしようとします。これはかなり標準的な動作です。

上記の場合、信頼できるはずです。updateandステートメントの両方で、select変換する必要がある型は (テーブルの列定義から) わかっています。

ただし、自動キャストは、より複雑なクエリの一部である場合、微妙な問題を引き起こす可能性があります。一部の種類の SQL では、次のようなステートメントで問題が発生します。

select case when foo=1 then 0 else 'a' end from table

この場合、結果の型は必ずしもすべての型の結果を受け入れることができるものではないため、「a」を割り当てようとすると失敗する可能性があります。複雑なステートメントで自動変換を使用する場合は注意してください。このような場合は明示した方がよいでしょう。

すべてを文字列として渡す場合のもう 1 つの潜在的な問題は、誤って数値以外の値を渡すとエラーが発生することです。

于 2013-02-28T12:18:21.483 に答える
1

CASTとCONVERTトピックを確認すると、便利な表が見つかります。

ここに画像の説明を入力

およびから の変換は他のすべての型でサポートされており、明示的なキャストが必要な型はごくわずかであることに注意してください。一部の型では、その型のリテラルを型指定する明白な方法がないため、文字列からの暗黙的な変換を許可することは理にかなっています。charvarchar

（しかし、ああ、フォーマットコードで明示的なケースが必要になるように変換したいのですが...）datetime

于 2013-02-28T13:34:09.423 に答える