SQL Serverで整数が暗黙的にアスタリスクに変換されるのを防ぐにはどうすればよいですか?


8

テーブルアカウントがあるとします。1つのフィールドがあります。 acct_type varchar(2)

Insert into account(acct_type) values(888)

出力:

+-----------+
| acct_type |
+-----------+
| *         |
+-----------+

挿入ステートメントのトリガー時にエラーがスローされることを期待しています。なぜそれ*はテーブルに値を格納しているのですか?


@SMor:または、テーブルが正しく定義されていません。アプリケーションがそこに数字(整数)を格納したい場合は、多分列は以下のように定義する必要があるintegerのではなくvarchar
a_horse_with_no_name

回答:


11

以下のためvarcharのデータ型切り捨てintとしてキャストされる*代わりに、(3桁がに収まらないとして、この場合にエラーをスローしますvarchar(2))。

これは起こりません nvarchar

この動作を変更する方法はありません。下位互換性のために保持されています。これが実際の問題である場合は、列の値*がそうではないというチェック制約を追加できますが、これが本当に価値がある状況は想像できません。

解決策は、それを行わないことです。挿入する必要がある場合INTは、-9 to 99最初に範囲内にあることを確認してください。または、暗黙の変換に依存するのではなく、常に文字列列を宛先とする値を引用符で囲みます。


ありがとうマーティン!..varcharに整数値を防ぐためにチェック制約をどのように置くことができますか...構文を書くのを手伝ってくれませんか?
Ankush

ALTER TABLE account ADD CONSTRAINT CK_NoStar_acct_type CHECK (acct_type <> '*')しかし、ほぼ間違いなくこれを行う必要はありません。char/varchar野生の列には長さ10以下のトンがあり、これは理論的に可能であり、それがなくてもうまくいく。もちろん*、それがどのよう*に到着したかを区別する方法がないので、チェック制約はの明示的な挿入もブロックします
Martin Smith

1
マーティンに感謝します!! これで、これの構文と副作用について開発者に適切に説明できます
Ankush

4
私は本当の質問は次のとおりだと思います:彼らが整数値を格納したいのなら、なぜこれはvarchar最初からaなのでしょうか?
a_horse_with_no_name

@a_horse_with_no_name OPについて質問がある場合は、回答ではなく質問に記入してください。ここでは通知されません。「888」はvarchar(2)とにかく有効な値ではありませんが、この列に整数を格納することだけを意図していることを示す質問には何もありません。推測できるのは、少なくとも1回は試行した結果、黙って失敗するのではなくエラーが発生するという予期しない結果が得られたことです。
マーティンスミス

-2

varcharは文字列型を受け入れます。''記号の間に値を挿入できます。のように見えますがInsert into account(acct_type) values('888') 、最大長が2であるため、エラーが表示されます。icrease varcharの長さまたは最大値の長さは2でなければなりませんInsert into account(acct_type) values('88')


あなたの答えは質問とは別の方向に進みます、Samiはエラーが発生せず、挿入された値「*」を示します。SMorが与えたコメントは、問題の方にありそうです。
マーク
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.