"NVARCHAR(MAX)-Kürzung tritt immer noch auf: Implizite Konvertierung verstehen"
Trotz der falschen Vorstellung, dass NVARCHAR(MAX) in modernen SQL Server-Versionen Enthält umfangreiche Daten, kann es bei Benutzern wie hier zu einer Kürzung auf 4000 Zeichen kommen Beispiel:
DECLARE @Query NVARCHAR(max); SET @Query = 'SELECT...' -- some of the query gets set here SET @Query = @Query + '...' -- more query gets added on, etc. -- later on... PRINT LEN(@Query) -- Prints out 4273, which is correct as far as I can tell PRINT @Query -- Truncates value to 4000 characters EXEC sp_executesql @Query -- totally crashes due to malformed (truncated) query
Die Grundursache: Implizite Konvertierung
Das Problem ergibt sich aus der impliziten Konvertierung. Beim Verketten von Zeichenfolgen mit Unicode-Zeichen konvertiert SQL Server das Ergebnis automatisch in NVARCHAR(4000), ohne Warnung oder Hinweis auf Kürzung. Dies tritt auch dann auf, wenn die zum Speichern des Ergebnisses deklarierte Variable NVARCHAR(MAX) ist.
Lösung: Explizite Konvertierung erzwingen
Um eine implizite Konvertierung zu verhindern und die Beibehaltung großer Mengen sicherzustellen Daten, immer mit CAST vorverketten:
SET @Query = CAST('' as nVarChar(MAX)) -- Force implicit conversion to nVarChar(MAX) + 'SELECT...' -- some of the query gets set here + '...' -- more query gets added on, etc.
Durch die Umwandlung einer leeren Zeichenfolge in NVARCHAR(MAX) wird SQL Server explizit angewiesen, die gesamte Zeichenfolge als NVARCHAR(MAX) zu verarbeiten. Dadurch wird das Kürzungsproblem beseitigt.
Weitere Überlegungen
Das obige ist der detaillierte Inhalt vonWarum kürzt NVARCHAR(MAX) meine Zeichenfolgen in SQL Server immer noch?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!