2016-11-19 1 views
0

Ich füge Daten aus einer Tabelle in eine andere, die neue Tabellenstruktur wird meist aus der alten Tabelle mit ein paar neuen Spalten abgeleitet, wenn ich meine Abfrage ich ausführe erhalten Sie den Fehler:das Einfügen von Daten aus einer Tabelle in andere Daten würde abgeschnitten werden

String or binary data would be truncated.

die Werte auf meine INSERT-Abfrage aus einer select-Anweisung kommt, die so 70.000 Zeilen zurückgibt ich weiß nicht, wie Sie herausfinden, welche Daten den Fehler verursacht, ist es eine Möglichkeit, um herauszufinden, ?

+0

Es gibt einige andere Frage auf SO: http://stackoverflow.com/questions/6388756/sql-server-string-or-binary-data-would -be-abgeschnitten. Sie können auch hier klicken: http://blogs.lessthandot.com/index.php/datamgmt/datadesign/how-to-find-was-Spalte/ – Klinger

Antwort

0

Dies ist ein leichtes Überprüfung (nur Metadaten), die Ihre Suche nach unten auf die Liste der Spalten verengen werden, die möglicherweise das Problem verursacht - als die
die Spalten, in denen die max_length in der Zieltabelle kleiner sind die max_length des Anpassungs Ausdruck in der Quellabfrage.


Erstellen Sie eine leere Tabelle basierend auf den Ergebnissen Ihrer Quellabfrage und vergleichen Sie die Metadaten.

Beispiel:

create table src (str1 varchar(11),str2 varchar(3)); 
create table trg (str1 varchar(7),str2 varchar(3));  
insert into src values ('Hi','XY'),('Hello world','XY'),('Hi','XYZ') 

insert into trg (str1,str2) select str1,str2 + 'D' from src 

Msg 8152, Level 16, State 14, Line 10
String or binary data would betruncated.

select str1,str2+'D' as str2 into tmp from src where 1=2; 

select  * 

from  (select  c.name 
         ,min(case o.name when 'tmp' then t.name end)   as tmp_type 
         ,min(case o.name when 'trg' then t.name end)   as trg_type 
         ,min(case o.name when 'tmp' then c.max_length end) as tmp_max_length 
         ,min(case o.name when 'trg' then c.max_length end) as trg_max_length 

      from     sys.objects as o 
         join  sys.columns as c 
         on   c.object_id   = o.object_id 
         join  sys.types as t 
         on   t.system_type_id = c.system_type_id 
           and t.user_type_id  = c.user_type_id 

      where  o.name in ('tmp','trg') 
        and ( c.collation_name is not null 
         or c.name in ('binary','varbinary') 
         ) 

      group by c.name 
      ) c 

where  tmp_max_length > trg_max_length 

order by c.name 
; 

+------+----------+----------+----------------+----------------+ 
| name | tmp_type | trg_type | tmp_max_length | trg_max_length | 
+------+----------+----------+----------------+----------------+ 
| str1 | varchar | varchar | 11    | 7    | 
+------+----------+----------+----------------+----------------+ 
| str2 | varchar | varchar | 4    | 3    | 
+------+----------+----------+----------------+----------------+ 
2

Ein oder mehr Spalten in der Zieltabelle haben einen Typen, der nicht breit genug, um enthalten die Daten aus der Quelltabelle ist, und die Quelltabelle Spalten Daten in ihnen haben, die breiter ist als das, was das ist Zielspalten können enthalten.

Zum Beispiel hat die Quelltabelle eine Spalte X, die vom Typ ist NVARCHAR(200) und Sie versuchen, dass in die Zieltabelle Spalt kopieren Y die NVARCHAR(100) vom Typ ist. Die Quellentabelle enthält mindestens eine Zeile mit einem Wert für X, der breiter als 100 Zeichen ist. Wenn Sie die Spalte kopieren, verlieren Sie Ihre Daten und führen zu dem gleichen Fehler, den Sie erhalten.


Was Sie tun müssen, ist entweder:

  • Ändern Sie die Spaltentypen in der Zieltabelle, die nicht breit genug
  • explizit sein, wenn Datenverlust soll, und verwenden Sie CAST ausdrücklich . ZB für das Beispiel, das ich vorher gab, CAST(X AS VARCHAR(100)).

Beispiel:

DECLARE @s TABLE(x NVARCHAR(20)); 
INSERT INTO @s(x)VALUES(N'123456789'); -- data in source column wider than what the target column can contain 

DECLARE @t TABLE(y NVARCHAR(10)); -- target column is less wide than source column 

INSERT INTO @t(y) SELECT x FROM @s; -- this statement will fail with the same error as you have 

INSERT INTO @t(y) SELECT CAST(x AS NVARCHAR(10)) FROM @s; -- this statement succeeds, only use if data loss is intended 
+0

Dies beantwortet nicht die OP-Frage. Er fragt nicht, warum er diesen Fehler erhalten hat, sondern wie er die Daten findet, die diesen Fehler verursachen. –

+0

@DuduMarkovitz Der Punkt, den ich mache, ist, dass er nicht nach den Daten suchen sollte, die den Fehler überhaupt verursachen. Er sollte seine Arbeitsweise ändern: entweder müssen die Spalten der Zieltabelle mindestens genauso breit sein wie die der Quelle oder sie müssen explizit mit Datenverlust umgehen. Denn was wird er tun, wenn er ein Skript ausführt, um die Spalte/Daten zu finden, die der Schuldige ist? –

+0

@DuduMarkovitz Versteh mich aber nicht falsch =), du hast einen Punkt. Aber wird Ihre Antwort * "herausfinden, welche Daten den Fehler verursachen" *? –

Verwandte Themen