16640
13.09.2005, aktualisiert um 15:16:09 Uhr
22017
2
0
SQL Server Fehler Insufficient result space to convert uniqueidentifier value to char
Ursache für "Msg 8170, Level 16, State 2, Line 1
Insufficient result space to convert uniqueidentifier value to char."
Eine nicht sofort ins Auge springende Fehlerursache:
Beim Anlegen einer partitionierten View werden die einzelnen Datenabschnitte durch Eingrenzungen auf einer Spalte vom Typ 'uniqueidentifier' vorgenommen. Um mit den per T-SQL erzeugten dynamischen SQL-Statements die Eingrenzungen grob vorzunehmen, wurde naheliegenderweise diese Spalte mit den beginnenden Zeichen des UID verglichen, bspw. mit fogender WHERE-Bedingung:
where convert(varchar, UIDFeld) >= 'DDDDD' and convert(varchar, UIDFeld) < 'EEEEE' .....
Die Generierung dieser Views erfolgt ohne Fehler, aber jeder spätere Zugriff auf die View erzeugt den im Betreff genannten Fehler.
Letztlich ausgemachte Ursache ist die Konvertierung nach 'varchar'. Wenn man diesen Datentyp ersetzt durch 'char(50)', funktioniert hinterher der Zugriff auf die Daten der View fehlerfrei. Konkret auf die oben bereits verwendete WHERE-Bedingung angewendet würde diese so aussehen:
where convert(char(50), UIDFeld) >= 'DDDDD' and convert(char(50), UIDFeld) < 'EEEEE' .....
Um den Fehler zu reproduzieren, wird eine Tabelle mit einer 'uniqueidentifier'-Spalte benötigt. Wenn solches vorhanden ist, produziert dieses Beispiel hier den Fehler ([Quelltabelle] und [UIDFeld] natürlich mit den tatsächlichen Werten ersetzen):
Hier noch entsprechende Screenshots dazu, einmal mit Fehler und einmal ohne. Das alles auf MS SQL Server 2000, SP3
mit Fehler:
ohne Fehler:
dba
Insufficient result space to convert uniqueidentifier value to char."
Eine nicht sofort ins Auge springende Fehlerursache:
Beim Anlegen einer partitionierten View werden die einzelnen Datenabschnitte durch Eingrenzungen auf einer Spalte vom Typ 'uniqueidentifier' vorgenommen. Um mit den per T-SQL erzeugten dynamischen SQL-Statements die Eingrenzungen grob vorzunehmen, wurde naheliegenderweise diese Spalte mit den beginnenden Zeichen des UID verglichen, bspw. mit fogender WHERE-Bedingung:
where convert(varchar, UIDFeld) >= 'DDDDD' and convert(varchar, UIDFeld) < 'EEEEE' .....
Die Generierung dieser Views erfolgt ohne Fehler, aber jeder spätere Zugriff auf die View erzeugt den im Betreff genannten Fehler.
Letztlich ausgemachte Ursache ist die Konvertierung nach 'varchar'. Wenn man diesen Datentyp ersetzt durch 'char(50)', funktioniert hinterher der Zugriff auf die Daten der View fehlerfrei. Konkret auf die oben bereits verwendete WHERE-Bedingung angewendet würde diese so aussehen:
where convert(char(50), UIDFeld) >= 'DDDDD' and convert(char(50), UIDFeld) < 'EEEEE' .....
Um den Fehler zu reproduzieren, wird eine Tabelle mit einer 'uniqueidentifier'-Spalte benötigt. Wenn solches vorhanden ist, produziert dieses Beispiel hier den Fehler ([Quelltabelle] und [UIDFeld] natürlich mit den tatsächlichen Werten ersetzen):
create
view dbo.vw_test_8170
as
select
*
from [quelltabelle]
where
convert(varchar, [UIDFeld]) >= '88888'
go
select * from dbo.vw_test_8170Hier noch entsprechende Screenshots dazu, einmal mit Fehler und einmal ohne. Das alles auf MS SQL Server 2000, SP3
mit Fehler:
ohne Fehler:
dba
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 15972
Url: https://administrator.de/contentid/15972
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
2 Kommentare
Neuester Kommentar
Thx, dba, obwohl..
Char(40) hätte auch gereicht, aber was soll der Geiz....
Eigentlich poste ich ja nur, weil ich neulich mal einen Link zum Thema IDENTIFIER gebookmarked hatte, den ich nett fand:
http://www.konfabulieren.com/2005/06/24/own-your-very-own-128-bit-uniqu ...
Biber
Char(40) hätte auch gereicht, aber was soll der Geiz....
Eigentlich poste ich ja nur, weil ich neulich mal einen Link zum Thema IDENTIFIER gebookmarked hatte, den ich nett fand:
http://www.konfabulieren.com/2005/06/24/own-your-very-own-128-bit-uniqu ...
Biber
Ja Biber, da hast Du wohl wahr 
wobei auch 36 ausreichend ist, dann gibt's gar keine Bytverschwendung mehr. Aber Du weisst sicher, wie das ist, wenn man vor dem Hackbrett sitzt und am liebsten ein paar Stücke rausbeissen würde ...
Wenn man mal die Geschichte mit solch einem armen Unique Identifier philosophisch betrachtet ... nimm Dir eine Adresstabelle mit einigen hundert bis Millionen Records und dann spielst Du Datengott und machst ein
select newid() from [tabelle]
und für jeden existierenden Satz schickst Du jetzt solch eine einmalige, auf der ganzen Welt niemals wiederkehrende ID ins Datennirwana ... das ist schon ganz schön traurig, oder?
In diesem Sinne ... angenehme Restwoche.
dba
wobei auch 36 ausreichend ist, dann gibt's gar keine Bytverschwendung mehr. Aber Du weisst sicher, wie das ist, wenn man vor dem Hackbrett sitzt und am liebsten ein paar Stücke rausbeissen würde ...Wenn man mal die Geschichte mit solch einem armen Unique Identifier philosophisch betrachtet ... nimm Dir eine Adresstabelle mit einigen hundert bis Millionen Records und dann spielst Du Datengott und machst ein
select newid() from [tabelle]
und für jeden existierenden Satz schickst Du jetzt solch eine einmalige, auf der ganzen Welt niemals wiederkehrende ID ins Datennirwana ... das ist schon ganz schön traurig, oder?
In diesem Sinne ... angenehme Restwoche.
dba
