2017-08-07 4 views
0

Aujourd'hui, je fais face à un message étrange. Je ne sais pas si elle est juste un bug:La réduction de la taille du type de données entraîne un dépassement de la taille maximale de l'index?

enter image description here

Les tables sont créés par ASP.NET Identity. Toutefois, ils utilisent nvarchar(450) pour l'ID, que je ne peux pas utiliser dans d'autres tables car l'index dépasse 900 octets. Par conséquent j'essaye de le réduire, mais comment le PK_AspNetUserRoles pourrait-il être créé en premier lieu? Est-ce juste un bug SSMS?

Répondre

0

Quelle est votre version de SSMS? À mon humble avis, c'est un bug, je ne peux pas reproduire ce problème dans 12.0.4100.1.

Vous ne pouvez pas modifier le type de colonne sans recréer l'index, l'erreur que vous pourriez recevoir pourrait être:

Msg 5074, niveau 16, état 1, ligne 4 L'indice « PK_AspNetUserRoles » dépend de la colonne ' Identifiant d'utilisateur'. Msg 4922, niveau 16, état 9, ligne 4 ALTER TABLE ALTER COLUMN UserId a échoué car un ou plusieurs objets accèdent à cette colonne.

Mais mes SSMS silencieusement a fait ce qui suit:

  • créer nouvelle table avec le même nom et le préfixe tmp ayant nvarchar (150) -column
  • insertion dans nouvelle table select * from table originale
  • baisse de table d'origine
  • nouvelle table renomme ancienne table
  • create index PK sur elle

Aucune erreur n'a été affichée

+0

Ma version est '13.0.16106.4'. Dans cette boîte de dialogue, j'ai essayé de cliquer sur Oui de toute façon, et SSMS a automatiquement changé le type de données des clés étrangères au nouveau ('nvarchar (450)' à 'nvarchar (150)') –

+0

Clés étrangères? Votre message n'a rien dit à leur sujet, l'erreur affichée concerne la clé primaire – sepupic

+0

Désolé. J'ai changé la colonne 'Id' de la table' AspNetUsers'. Et 'UserId' de' AspNetUserRoles' fait référence à 'Id', et il fait aussi partie de la clé primaire. –