MS SQL Problème - Longueur du champ étant limitée

Question

J'ai une base de données MS SQL avec plusieurs tables, et un champ en particulier me cause du chagrin.

Le type de données est défini sur varchar (100), mais le champ est limité à 60 caractères.

Si j'essaie de mettre une chaîne de plus de 60 caractères dans le champ, j'obtiens une exception, "La chaîne ou les données binaires seraient tronquées". Bien que la chaîne soit plus courte que le type de données explicitement défini, elle génère toujours une exception.

Y a-t-il peut-être un paramètre de base de données qui le fait? Qu'est-ce qui peut provoquer l'écrasement du type de données explicitement défini?

Edit:
Les déclencheurs ne copient pas la valeur ou l'insérer dans une autre table et ne pas utiliser les données non plus. - (Incorrect)

Les chaînes dont la taille est inférieure à 60 caractères fonctionnent correctement.

Toutes les colonnes qui ont varchar (100) donnent le même problème, mais toutes les autres colonnes acceptent les valeurs correctes. La colonne varchar (10) fonctionne bien.

Toute ligne de cette table lève l'exception si j'essaie de mettre à jour le champ avec une chaîne de plus de 60 caractères. J'essaie d'insérer les données directement dans le champ à l'aide de SQL Server Management Studio.

Aucun bourrage n'est impliqué.

Réponse:

Il y avait une deuxième table où la colonne a été fixé à 60. Le déclencheur de mise à jour appelée une procédure stockée qui insère les données dans la table « dénormalisé ».

Merci pour toute l'aide.

Answer 1

Qu'est-ce que la fonction de métadonnées COL_LENGTH dit est la taille définie de cette colonne?

Avez-vous une contrainte de longueur par défaut sur cette colonne? En supposant que les réponses précédentes indiquent qu'il ne s'agit pas d'un problème déclencheur ou d'un problème nvarchar, et que vous pensez que la troncature est au nombre de 60, que fait cette colonne unique avec SUBSTRING de longueur 60 et 61?Cela pourrait valider ou invalider votre théorie.

Il est également possible que les paramètres de classement et/ou de codage de la base de données aient changé depuis l'insertion des données d'origine. Cela peut conduire à des particularités. Vous dites que c'est une copie de la base de données originale. Est-il assis sur une instance SQL Server différente? Si oui, les deux instances SQL Server ont-elles les mêmes paramètres de classement et d'encodage?

EDIT: L'utilisation du ANSI_PADDING setting que vous discutez est obsolète et le paramètre sera définitivement activé dans les futures versions de SQL Server. Mais le fait que vous regardez ceci suggère que la valeur que vous essayez d'insérer est rembourrée d'une certaine manière, peut-être avec des espaces vides. Cependant, ceci n'est pas cohérent avec les résultats de votre expérience SUBSTRING, qui montre une limite à 60 caractères. Je ne suis donc pas sûr que ce paramètre soit pertinent, d'autant plus qu'il est toujours activé pour une colonne nvarchar.

Est-ce qu'une chaîne de 61 caractères provoque l'exception de mise à jour? En outre, bien que vous ayez vérifié les déclencheurs de la table immédiate, existe-t-il des déclencheurs en cascade (indirects) susceptibles de provoquer cette exception?

Answer 2

Vous avez peut-être besoin de NVARCHAR (100) ou plutôt de NVARCHAR (60).

Un seul caractère dans le NVARCHAR est le double de la taille de VARCHAR. Vous utilisez NVARCHAR si vos données d'entrée est unicode

EDIT:

Sur la base de vos commentaires, il ressemble à l'aide nvarchar n'est pas nécessaire une solution au problème, et il est assez difficile de deviner ce que les questions sont avec les informations fournies jusqu'ici:

Pourriez-vous scripter votre table, avec des contraintes et des déclencheurs et publier le code, qui aiderait certainement à trouver la source du problème.