Je suis impliqué dans un projet de migration de données. J'obtiens l'erreur suivante lorsque j'essaie d'insérer des données d'une table dans une autre table (SQL Server 2005):
Msg 8152, niveau 16, état 13, ligne 1 La
chaîne ou les données binaires seraient tronquées.
Les colonnes de données source correspondent au type de données et sont comprises dans les définitions de longueur des colonnes de la table de destination. Je ne sais donc pas ce qui pourrait causer cette erreur.
Réponses:
Vous devrez publier les définitions de table pour les tables source et de destination pour que nous puissions déterminer où se situe le problème, mais fin de compte, l'une de vos colonnes dans la table source est plus grande que vos colonnes de destination . Il se peut que vous changiez de format d'une manière dont vous n'étiez pas au courant. Le modèle de base de données à partir duquel vous vous déplacez est également important pour comprendre cela.
la source
Comme d'autres l'ont déjà dit, l'un de vos types de données de colonnes dans la table source est plus grand que vos colonnes de destination.
Une solution simple consiste simplement à désactiver l'avertissement et à autoriser la troncature. Donc, si vous recevez cette erreur mais que vous êtes sûr qu'il est acceptable que les données de votre ancienne base de données / table soient tronquées (coupées à la taille), vous pouvez simplement faire ce qui suit;
Comme ci-dessus, n'oubliez pas de réactiver les avertissements par la suite. J'espère que ça aide.
la source
Le problème est assez simple: une ou plusieurs colonnes de la requête source contiennent des données qui dépassent la longueur de sa colonne de destination. Une solution simple serait de prendre votre requête source et de l'exécuter
Max(Len( source col ))
sur chaque colonne. C'est à dire,Comparez ensuite ces longueurs aux longueurs des types de données dans votre table de destination. Au moins un, dépasse sa longueur de colonne de destination.
Si vous êtes absolument certain que cela ne devrait pas être le cas et que vous ne vous souciez pas si ce n'est pas le cas , une autre solution consiste à convertir de force les colonnes de requête source à leur longueur de destination (ce qui tronquera toutes les données trop longues):
la source
SQL Server 2019 renverra enfin un message d'erreur plus significatif.
Pour activer un nouveau comportement, vous devez utiliser
DBCC TRACEON(460)
. Nouveau texte d'erreur desys.messages
:Les données de chaîne ou binaires seraient tronquées: remplacement de la tristement célèbre erreur 8152
SQL Server 2017 CU12 prend également en charge cette fonctionnalité.
Amélioration: remplacement facultatif du message «Les données de chaîne ou binaires seraient tronquées» avec des informations étendues dans SQL Server 2017
démo db <> fiddle
la source
Une autre raison potentielle à cela est si vous avez une valeur par défaut pour une colonne qui dépasse la longueur de la colonne. Il semble que quelqu'un ait touché un gros doigt sur une colonne d'une longueur de 5 mais la valeur par défaut dépassait la longueur de 5. Cela m'a rendu fou car j'essayais de comprendre pourquoi cela ne fonctionnait sur aucun insert, même si tout ce que j'insérais était une seule colonne avec un entier de 1. Parce que la valeur par défaut sur le schéma de table avait cette valeur par défaut violant, il a tout gâché - ce qui nous amène à la leçon apprise - évitez d'avoir des tables avec des valeurs par défaut dans le schéma. :)
la source
Pour les autres, vérifiez également votre procédure stockée . Dans mon cas, dans ma procédure stockée,
CustomSearch
j'ai accidentellement déclaré une longueur insuffisante pour ma colonne, donc lorsque j'ai entré un big data, j'ai reçu cette erreur même si j'ai une grande longueur sur ma base de données. Je viens de changer la longueur de ma colonne dans ma recherche personnalisée, l'erreur disparaît. Ceci est juste pour le rappel. Merci.la source
Cela peut être une erreur difficile. Voici quelques notes tirées de https://connect.microsoft.com/SQLServer/feedback/details/339410/ recherchez le commentaire d'AmirCharania.
J'ai ajusté la réponse donnée par AmirCharania pour les données sélectionnées dans une table réelle, au lieu d'une table temporaire. Sélectionnez d'abord votre ensemble de données dans une table de développement, puis exécutez ce qui suit:
la source
Voici une réponse légèrement différente. Les noms et longueurs de vos colonnes peuvent tous correspondre, mais peut-être que vous spécifiez les colonnes dans le mauvais ordre dans votre instruction SELECT. Disons que tableX et tableY ont des colonnes avec le même nom, mais dans un ordre différent
la source
Je suis tombé sur ce problème aujourd'hui, et dans ma recherche d'une réponse à ce message d'erreur informatif minimal, j'ai également trouvé ce lien:
https://connect.microsoft.com/SQLServer/feedback/details/339410/please-fix-the-string-or-binary-data-would-be-truncated-message-to-give-the-column-name
Il semble donc que Microsoft n'a pas l'intention d'étendre le message d'erreur de sitôt.
Alors je me suis tourné vers d'autres moyens.
J'ai copié les erreurs pour exceller:
(1 ligne (s) affectée (s))
(1 ligne (s) affectée (s))
(1 ligne (s) affectée (s)) Msg 8152, niveau 16, état 14, ligne 13 La chaîne ou les données binaires seraient tronquées. La déclaration a été terminée.
(1 ligne (s) affectée (s))
a compté le nombre de lignes dans Excel, s'est rapproché du compteur d'enregistrements qui a causé le problème ... a ajusté mon code d'exportation pour imprimer le SQL à proximité ... puis a exécuté les insertions 5 à 10 sql autour du problème sql et réussi à identifier le problème, voir la chaîne qui était trop longue, augmenter la taille de cette colonne, puis le gros fichier d'importation a fonctionné sans problème.
Un peu de hack et une solution de contournement, mais quand vous êtes parti avec très peu de choix, vous faites ce que vous pouvez.
la source
Oui, je suis également confronté à ce genre de problème.
Ici, j'ai changé la longueur du fichier REMARQUES de 500 à 1000
la source
Je vais ajouter une autre cause possible de cette erreur simplement parce que personne ne l'a mentionnée et cela pourrait aider une future personne (puisque l'OP a trouvé sa réponse). Si la table dans laquelle vous insérez a des déclencheurs, il se peut que le déclencheur génère l'erreur. J'ai vu cela se produire lorsque les définitions de champ de table ont été modifiées, mais pas les tables d'audit.
la source
Oui - "une pinte dans un pot d'une demi-pinte n'ira pas". Je n'ai pas eu beaucoup de chance (pour une raison quelconque) avec les différents SP que les gens ont suggérés, MAIS tant que les deux tables sont dans la même base de données (ou vous pouvez les mettre dans la même base de données), vous pouvez utiliser INFORMATION_SCHEMA. COLUMNS pour localiser le (s) champ (s) errant (s), ainsi:
Cela vous permettra de faire défiler vers le haut et vers le bas, en comparant les longueurs de champ au fur et à mesure. Les sections commentées vous permettent de voir (une fois non commentées, évidemment) s'il y a des incompatibilités de type de données, ou montrent spécifiquement celles qui diffèrent par la longueur du champ - parce que je suis trop paresseux pour faire défiler - sachez simplement que tout dépend de la source noms de colonne correspondant à ceux de la cible.
la source
J'utilisais une chaîne vide `` lors de la création de la table, puis recevais l'erreur `` Msg 8152, la chaîne ou les données binaires seraient tronquées '' lors de la mise à jour suivante. Cela se produisait en raison de la valeur de mise à jour contenant 6 caractères et plus grande que la définition de colonne prévue. J'ai utilisé "ESPACE" pour contourner ce problème uniquement parce que je savais que je mettrais à jour en masse après la création initiale des données, c'est-à-dire que la colonne n'allait pas rester vide longtemps.
SO BIG CAVEAT ICI: Ce n'est pas une solution particulièrement astucieuse, mais utile dans le cas où vous rassemblez un ensemble de données, par exemple pour des demandes de renseignement ponctuelles où vous créez une table pour l'exploration de données, appliquez un traitement / interprétation en masse et stocker les résultats avant et après pour comparaison / extraction ultérieure. C'est un événement fréquent dans ma ligne de travail.
Vous pouvez initialement remplir en utilisant le mot-clé SPACE ie
Les mises à jour ultérieures de "nom_colonne" de 10 caractères ou moins (remplacer le cas échéant) seront alors autorisées sans provoquer d'erreur tronquée. Encore une fois, je n'utiliserais cela que dans des scénarios similaires à celui décrit dans ma mise en garde.
la source
J'ai construit une procédure stockée qui analyse une table source ou une requête avec plusieurs caractéristiques par colonne parmi lesquelles la longueur minimale (min_len) et la longueur maximale (max_len).
Je stocke cette procédure dans la base de données master afin de pouvoir l'utiliser dans chaque base de données comme ceci:
Et le résultat est:
column description constraint_type fk_table fk_column pos default null data_type length precision radix is_unique min_len max_len nulls blanks numerics distincts distinct_values remarks
id_individual NULL PRIMARY KEY NULL NULL 1 NULL NO int NULL 10 10 1 1 2 0 0 70 70 Many (70) unique,all numeric,
id_brand NULL NULL NULL NULL 2 NULL NO int NULL 10 10 0 1 1 0 0 70 2 2,3 same length,all numeric, guid NULL NULL NULL NULL 3 (newid()) NO uniqueidentifier NULL NULL NULL 1 36 36 0 0 0 70 Many (70) unique,same length,
customer_id NULL NULL NULL NULL 4 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
email NULL NULL NULL NULL 5 NULL YES varchar 100 NULL NULL 0 4 36 0 0 0 31 Many (31)
mobile NULL NULL NULL NULL 6 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
initials NULL NULL NULL NULL 7 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
title_short NULL NULL NULL NULL 8 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
title_long NULL NULL NULL NULL 9 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
firstname NULL NULL NULL NULL 10 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
lastname NULL NULL NULL NULL 11 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
address NULL NULL NULL NULL 12 NULL YES varchar 100 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
pc NULL NULL NULL NULL 13 NULL YES varchar 10 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
kixcode NULL NULL NULL NULL 14 NULL YES varchar 20 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
date_created NULL NULL NULL NULL 15 (getdate()) NO datetime NULL NULL NULL 1 19 19 0 0 0 70 Many (70) unique,same length,
created_by NULL NULL NULL NULL 16 (user_name()) NO varchar 50 NULL NULL 0 13 13 0 0 0 1 loyalz-public same length,
id_location_created NULL FOREIGN KEY location id_location 17 NULL YES int NULL 10 10 0 1 1 0 0 70 2 1,2 same length,all numeric, id_individual_type NULL FOREIGN KEY individual_type id_individual_type 18 NULL YES int NULL 10 10 0 NULL NULL 70 0 0 0 NULL all null,empty,
optin NULL NULL NULL NULL 19 NULL YES int NULL 10 10 0 1 1 39 0 31 2 0,1 same length,
la source
sp_
préfixe pour vos procédures stockées. Microsoft a réservé ce préfixe pour son propre usage (voir Attribution d'un nom aux procédures stockées ) , et vous courez le risque d'un conflit de noms dans le futur. C'est également mauvais pour les performances de vos procédures stockées . Il est préférable d'éviter simplementsp_
et d'utiliser quelque chose d'autre comme préfixe - ou pas de préfixe du tout!J'ai écrit une procédure de magasin utile pour aider à identifier et résoudre le problème de la troncature du texte (les données de chaîne ou binaires seraient tronquées) lorsque l'instruction INSERT SELECT est utilisée. Il compare les champs CHAR, VARCHAR, NCHAR ET NVARCHAR uniquement et renvoie un champ d'évaluation par champ en cas d'être la cause possible de l'erreur.
CODE DE FONCTION:
Pour l'instant ne prend en charge que les types de données CHAR, VARCHAR, NCHAR et NVARCHAR . Vous pouvez trouver la dernière version de ce code dans le lien suivant ci-dessous et nous nous entraidons pour l'améliorer. GetFieldStringTruncate.sql
https://gist.github.com/jotapardo/210e85338f87507742701aa9d41cc51d
la source
Si vous êtes sur SQL Server 2016-2017: pour résoudre ce problème, activez l'indicateur de trace 460
et assurez-vous de l'éteindre après:
la source
la source
cela peut également se produire lorsque vous ne disposez pas des autorisations adéquates
la source
J'ai eu un problème similaire. Je copiais des données d'une table à une table identique dans tout sauf le nom.
Finalement, j'ai vidé la table source dans une table temporaire à l'aide d'une instruction SELECT INTO.
J'ai comparé le schéma de la table source à la table temporaire. J'ai trouvé que l'une des colonnes était un
varchar(4000)
quand j'attendais unvarchar(250)
.MISE À JOUR: Le problème varchar (4000) peut être expliqué ici au cas où vous seriez intéressé:
Pour Nvarchar (Max), je reçois seulement 4000 caractères dans TSQL?
J'espère que cela t'aides.
la source
Cette erreur est générée lorsque la colonne d'une table met une contrainte [principalement la longueur]. . Par exemple, si le schéma de base de données pour la colonne myColumn est CHAR (2), alors lorsque votre appel depuis l'une de vos applications pour insérer une valeur, vous devez transmettre une chaîne de longueur deux.
L'erreur le dit essentiellement; La chaîne de longueur trois et plus n'est pas cohérente pour s'adapter à la restriction de longueur spécifiée par le schéma de base de données. C'est pourquoi SQL Server avertit et renvoie une erreur de perte de données / troncature.
la source
Veuillez essayer le code suivant:
la source