Di chuyển từ văn bản và hình ảnh sang varchar (max) và varbinary (max)

Tôi có một cơ sở dữ liệu SQL Server chứa một số cột imagevà textcột và tôi đang nghiên cứu các vấn đề tiềm ẩn có thể phát sinh từ việc di chuyển chúng sang các đối tác không được phản đối của họ varbinary(max)và varchar(max).

Ngoài những thay đổi về mã ứng dụng, mối quan tâm chính của tôi là "gotchas" tiềm năng liên quan đến điều này. Ví dụ, có chức năng nào được hỗ trợ bởi các loại dữ liệu cũ nhưng không có trong các kiểu dữ liệu mới không?

Mất dữ liệu do cắt ngắn ít nhất dường như không phải là vấn đề vì các loại mới ít nhất là lớn như các loại cũ.

Xin lưu ý: các loại dữ liệu mới này hỗ trợ cùng kích thước với các loại không dùng nữa mà chúng thay thế, ví dụ 2GB dữ liệu (có nghĩa là số lượng ký tự khác nhau tùy thuộc vào Unicode và các yếu tố khác).

Một điều chắc chắn là bạn nên phân tích tất cả các mã hiện tại của bạn ứng dụng, thủ tục lưu trữ, chức năng vv cho các trường hợp xây dựng-in như UPDATETEXT, READTEXT, TEXTPTR, WRITETEXT, TEXTSIZEvà @@TEXTSIZE- tất cả trong số đó có thể sẽ phải được thay đổi. Bạn có thể xác định những người được lưu trữ trong SQL Server theo cách này:

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%';

Lưu ý rằng điều này có thể mang lại kết quả dương tính giả (ví dụ: các thuật ngữ đó có thể nằm trong một nhận xét hoặc xuất hiện tự nhiên trong tên thực thể) và nó có thể bỏ lỡ một số (ví dụ: các lệnh có thể được xây dựng bằng tham số / SQL động). Bạn tự mình tìm kiếm cơ sở mã ứng dụng và / hoặc kiểm soát nguồn cho các trường hợp tương tự.

Ngoài ra, hãy đảm bảo bạn tìm thấy tất cả các mô-đun chấp nhận hoặc xuất các tham số của các loại này:

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);

Bạn cũng có thể muốn xem xét rằng bạn có thể có logic trong công việc và các thói quen bảo trì khác hiện đang tránh các bảng này hoặc đối xử với chúng khác nhau do những hạn chế vốn có trong các loại dữ liệu này. Khi bạn chuyển sang các loại mới hơn (và đặc biệt là trên các phiên bản SQL Server hiện đại nhất), rất nhiều hạn chế sẽ biến mất.

Cuối cùng, ngoài cú pháp ở trên, tôi không thể nghĩ ra một tính năng duy nhất mà các loại cũ hỗ trợ mà các loại mới không có.

Chúng tôi đã trải qua điều này mà không có bất kỳ vấn đề. Bất cứ nơi nào bạn đang cập nhật hoặc chèn dữ liệu, hãy đảm bảo rằng đó là cách chèn / cập nhật truyền thống và bạn không sử dụng WRITETEXT hoặc UPDATETEXT.
Ngoài ra, mọi thứ nên hoạt động tốt.