1

私はさまざまなテーブルを持つ MS SQL DB を持っていますが、特に 1 つのフィールドが私を悩ませています。

データ型は varchar(100) に設定されていますが、フィールドは 60 文字に制限されています。

60 文字を超える文字列をフィールドに入力しようとすると、「文字列またはバイナリ データが切り捨てられます」という例外が発生します。文字列は明示的に設定されたデータ型よりも短いですが、それでも例外がスローされます。

おそらくこれを行うDB設定はありますか？明示的に設定されたデータ型が上書きされる原因は何ですか?

編集：
トリガーは値をコピーしたり、別のテーブルに挿入したりせず、データも使用しません。- （正しくない）

60 文字未満の文字列は正常に機能します。

varchar(100) を持つすべての列で同じ問題が発生しますが、他のすべての列は正しい値を受け入れます。varchar(10) 列は正常に機能します。

60 文字を超える文字列でフィールドを更新しようとすると、このテーブルのどの行でも例外がスローされます。

SQL Server Management Studio を使用して、データをフィールドに直接挿入しようとしています。

関連するパディングはありません。

答え：

列が 60 に設定された 2 番目のテーブルがありました。更新トリガーは、データを「非正規化」テーブルに挿入するストアド プロシージャを呼び出しました。

すべての助けをありがとう。

4

2 に答える 2

2

おそらく、NVARCHAR（100）またはむしろNVARCHAR（60）が必要です。

NVARCHARの1文字は、VARCHARの2倍のサイズです。入力データがUnicodeの場合は、NVARCHARを使用します

編集：

あなたのコメントに基づくと、nvarcharを使用することは問題の解決策である必要はないようであり、これまでに提供された情報で問題が何であるかを推測するのはかなり難しいです。

制約とトリガーを使用してテーブルをスクリプト化し、コードを投稿していただければ、問題の原因を見つけるのに間違いなく役立ちます。

于 2008-12-04T11:47:12.323 に答える
1

メタデータ関数 COL_LENGTH は、その列の定義されたサイズを何と言っていますか?

その列にデフォルトの長さの制約はありますか?

以前の回答から、これはトリガーの問題でも nvarchar の問題でもなく、切り捨てが長さ 60 であると仮定すると、長さ 60 の SUBSTRING でその単一の列を更新してから 61 を更新するとどうなりますか? これにより、理論が検証または無効になる可能性があります。

または、元のデータが挿入されてから、データベースの照合やエンコードの設定が変更された可能性があります。これは、いくつかの特殊性につながる可能性があります。これは元のデータベースのコピーだとおっしゃいます。別の SQL Server インスタンスに配置されていますか? その場合、両方の SQL Server インスタンスの照合順序とエンコードの設定は同じですか?

EDIT :あなたが議論しているANSI_PADDING 設定の使用は推奨されておらず、設定は SQL Server の将来のバージョンで永続的に ON になります。しかし、これを見ているという事実は、挿入しようとしている値が何らかの方法で、おそらく末尾の空白で埋められていることを示唆しています。ただし、これは、60 文字でカットオフを示す SUBSTRING テスト結果と一致しません。したがって、特に nvarchar 列では常にオンになっているため、この設定が関連しているかどうかはわかりません。

61 文字の文字列によって更新例外が発生しますか? また、即時テーブル トリガーを確認しましたが、この例外を引き起こしている可能性のあるカスケード (間接) トリガーはありますか?

于 2008-12-04T13:10:47.770 に答える