テキストと画像からvarchar（max）とvarbinary（max）への移行

8

いくつかのimageおよびtext列を含むSQL Serverデータベースがあり、それらを非推奨でない対応するvarbinary(max)とに移行することから発生する可能性のある潜在的な問題を調査していますvarchar(max)。

アプリケーションコードの変更は別として、私の主な関心事は、これに関連する潜在的な「問題」です。たとえば、古いデータ型ではサポートされているが、新しいデータ型ではサポートされていない機能はありますか？

新しい型は少なくとも古い型と同じくらい大きいので、切り捨てによるデータの損失は少なくとも問題にはならないようです。

sql-server database-design blob

— 合流
ソース

11

注：これらの新しいデータ型は、非推奨の型と同じサイズをサポートします。たとえば、2GBのデータ（つまり、Unicodeやその他の要因に応じて文字数が異なります）。

確かに一つのことは、あなたのような組み込み関数のインスタンスのために、既存のアプリケーション・コード、ストアドプロシージャ、関数などのすべてを解析しなければならないですUPDATETEXT、READTEXT、TEXTPTR、WRITETEXT、TEXTSIZEそして@@TEXTSIZEおそらく変更する必要がありますすべてが- 。SQL Serverに保存されているものを次の方法で特定できます。

SELECT s.name, o.name
  FROM sys.sql_modules AS m
  INNER JOIN sys.objects AS o
  ON m.[object_id] = o.[object_id]
  INNER JOIN sys.schemas AS s
  ON o.[schema_id] = s.[schema_id]
  WHERE UPPER(m.definition) LIKE N'%UPDATETEXT%'
     OR UPPER(m.definition) LIKE N'%WRITETEXT%'
     OR UPPER(m.definition) LIKE N'%READTEXT%'
     OR UPPER(m.definition) LIKE N'%TEXTPTR%'
     OR UPPER(m.definition) LIKE N'%TEXTSIZE%';

これにより誤検知（コメント内にある、またはエンティティ名に自然に発生するなど）が発生する可能性があり、一部が欠落する可能性があることに注意してください（たとえば、コマンドはパラメーター/動的SQLを使用して構築できます）。アプリケーションのコードベースやソースコントロールを検索して、同じインスタンスを探す必要があります。

また、これらのタイプのパラメーターを受け入れるまたは出力するすべてのモジュールを見つけてください。

SELECT DISTINCT s.name, o.name
  FROM sys.parameters AS p
  INNER JOIN sys.objects AS o
  ON p.[object_id] = o.[object_id]
  INNER JOIN sys.schemas AS s
  ON o.[schema_id] = s.[schema_id]
  WHERE system_type_id IN (34,35,99);

また、これらのデータ型に固有の制限のために、ジョブやその他のメンテナンスルーチンに、現在これらのテーブルを回避したり、別の方法で処理したりするロジックがある可能性があることも考慮する必要があります。新しいタイプ（特に最新バージョンのSQL Server）に移行すると、これらの制限の多くがなくなります。

最後に、上記の構文以外に、古いタイプがサポートする新しいタイプがサポートしない単一の機能を考えることはできません。

— アーロン・バートランド
ソース

2

問題なくこれを実行しました。データを更新または挿入するすべての場所で、それが従来の挿入/更新であり、WRITETEXTまたはUPDATETEXTを使用していないことを確認してください。
それ以外は、すべて正常に動作するはずです。

— ヴィック・アンブルソ
ソース