Migrazione da testo e immagine a varchar (max) e varbinary (max)

Ho un database SQL Server che contiene un numero di imagee textcolonne e sto studiando potenziali problemi che potrebbero derivare dalla loro migrazione alle loro controparti non deprecate varbinary(max)e varchar(max).

A parte le modifiche al codice dell'applicazione, la mia principale preoccupazione sono i potenziali "problemi" associati a questo. Ad esempio, esiste una funzionalità supportata dai tipi di dati meno recenti ma non in quelli nuovi?

La perdita di dati dovuta almeno al troncamento non sembra essere un problema poiché i nuovi tipi sono grandi almeno quanto quelli vecchi.

Solo una nota: questi nuovi tipi di dati supportano le stesse dimensioni dei tipi obsoleti che sostituiscono, ad esempio 2 GB di dati (il che significa un numero diverso di caratteri a seconda di Unicode e altri fattori).

Una cosa di sicuro è che si dovrebbe analizzare tutto il codice esistente applicazione, stored procedure, funzioni, ecc per le istanze di built-in come UPDATETEXT, READTEXT, TEXTPTR, WRITETEXT, TEXTSIZEe @@TEXTSIZE- ognuno dei quali dovrà probabilmente essere cambiato. È possibile identificare quelli memorizzati in SQL Server in questo modo:

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

Si noti che ciò potrebbe produrre falsi positivi (ad esempio, quei termini potrebbero essere in un commento o naturalmente presenti in un nome di entità) e potrebbero mancarne alcuni (ad esempio, i comandi potrebbero essere costruiti utilizzando parametri / SQL dinamico). Sei da solo per cercare la base di codice dell'applicazione e / o il controllo del codice sorgente per istanze della stessa.

Assicurati inoltre di trovare tutti i moduli che accettano o emettono parametri di questi tipi:

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

Potresti anche considerare che potresti avere una logica nei lavori e in altre routine di manutenzione che attualmente evitano queste tabelle o le trattano in modo diverso a causa delle limitazioni inerenti a questi tipi di dati. Quando si passa ai tipi più recenti (e in particolare alle versioni più moderne di SQL Server), molte di queste limitazioni scompaiono.

Infine, oltre alla sintassi sopra, non riesco a pensare a una singola funzionalità supportata dai vecchi tipi che i nuovi tipi non supportano.

Ci siamo passati senza problemi. Ovunque si stia aggiornando o inserendo dati, assicurarsi che si tratti di un inserimento / aggiornamento tradizionale e che non si stia utilizzando WRITETEXT o UPDATETEXT.
A parte questo, tutto dovrebbe funzionare bene.