Cette erreur survient lors de la synchronisation du DataDictionary.
Description de l'erreur SQL: [Microsoft] [SQL Server Native Client 11.0] [SQL Server] Il existe déjà un objet nommé 'I_100013RECID' dans le base de données.
Instruction SQL: ALTER TABLE "DBO" .ACOCOSTCENTERATTRIBUTEVALUE_BR ADD CONSTRAINT I_100013RECID PRIMARY KEY NONCLUSTERED (RECID)
J'ai copié toute la base de données commerciale et de code et créé un nouvel AX Env. Je ne sais pas si cette erreur existe également sur l'Env source, mais je souhaite résoudre ce problème sur le nouvel Env.
Ce que j'ai déjà essayé:
Supprimé la table de SQL Server Management Studio, puis Synchronisez depuis AOT mais l'erreur persiste.
J'ai essayé de supprimer le nom de l'index de SSMS:
dbo.ACOCOSTCENTERATTRIBUTEVALUE_BR
Mais obtenir cette erreur:
Impossible de supprimer l'index "ACOCOSTCENTERATTRIBUTEVALUE_BR.I_100013RECID", parce qu'il n'existe pas ou que vous n'avez pas l'autorisation.
Mais en interrogeant les index, il affiche la table correcte:
select object_name(object_id) from sys.indexes WHERE name = 'I_100013RECID'
Sortie:
DROP INDEX I_100013RECID ON [ACOCOSTCENTERATTRIBUTEVALUE_BR]
Sur 3 index, pourquoi les 2 index ne sont-ils pas supprimés lorsque je supprime la table de SSMS ? Pourquoi un seul est supprimé? Vérifiez ci-dessous les 3 index après la synchronisation. Comment s'en débarrasser? SSMS ne me laisse pas le supprimer en disant "Le catalogue ne peut pas être modifié". Puis-je essayer de le supprimer en modifiant les paramètres des données de base? Je ne suis pas sûr de ce que toutes les tables liées à cette table sont remplies dans le catalogue.
3 Réponses :
Les noms de contrainte doivent être uniques dans la base de données: Peut-il y avoir des contraintes du même nom dans un DB?
Les contraintes uniques créent automatiquement des index: https: // www .mssqltips.com / sqlservertip / 4270 / différence-entre-les-index-uniques-du-serveur-sql-et-les-contraintes-uniques /
Cette question vous montre différentes manières d'obtenir toutes les contraintes: SQL Server 2008 - Obtenir des contraintes de table
La table ACOCostCenterAttributeValue_BR est-elle utilisée dans votre environnement? Je suppose que non, sauf si vous travaillez avec des entreprises brésiliennes.
Je vous suggère de
ConfigurationKey de la table de LedgerBasic à SysDeletedObjects63. ACOCostCenterAttributeValue_BR de la couche dans laquelle vous travaillez. Cela restaurera la version de la couche SYS de la table avec ConfigurationKey = LedgerBasic. Enfin, j'ai la solution:
Le problème était qu'il y avait 2 tables
[dbo]. [ACOCOSTCENTERATTRIBUTEVALUE_BR]
[dbo]. [dbo.ACOCOSTCENTERATTRIBUTEVALUE_BR]
J'étais en train de supprimer la table [dbo]. [ACOCOSTCENTERATTRIBUTEVALUE_BR] de ssms et de synchronisation depuis AOT, en raison de laquelle l'erreur a persisté.
J'ai laissé tomber l'autre table [dbo]. [dbo.ACOCOSTCENTERATTRIBUTEVALUE_BR] (dont je ne savais même pas qu'elle existait car les tables sont classées par ordre alphabétique et je ne regardais que la première table) de ssms, puis de nouveau synchronisées et cela a réussi.
La deuxième table avait le préfixe "dbo". en son nom. Je n'ai absolument aucune idée de la façon dont cela s'est infiltré car je n'ai même jamais touché à cette table.
C'est bizarre. Je n'ai jamais vu cela arriver. Heureux que vous ayez trouvé le problème. Il est cependant étrange qu'AX essayait toujours d'interagir avec la mauvaise table. Ce second revient-il après une synchronisation complète de la base de données?
@AlexKwitny Oui, surtout quand je n'ai jamais interagi avec cette table auparavant. Je n'ai pas encore exécuté une synchronisation complète de DataDictionary. L'erreur de synchronisation sur cette table a disparu. Je vais essayer la synchronisation et la mise à jour DD complètes.
@AlexKwitny Salut Alex, j'ai de nouveau synchronisé DD. Aucune erreur. Le tableau avec "dbo". le préfixe que j'ai laissé tomber de SSMS ne s'est pas glissé à nouveau.
La seule chose que je peux penser que cela peut causer est si vous avez restauré dans un environnement avec une version de noyau différente OU si vous vous êtes connecté avec un client AX avec une version de noyau différente. Consultez l ' Aide> À propos de sur toutes les machines avec lesquelles vous travailliez. Directement sur l'AOS que vous avez copié, celui auquel vous êtes allé et comparez-les, ainsi que sur tout client que vous avez peut-être utilisé sur un serveur de terminaux. Si l'un des numéros Aide> À propos des numéros ne correspond pas quelque part, cela peut en être la cause.
@AlexKwitny Oui, l'environnement d'origine à partir duquel j'ai copié les bases de données n'avait pas ce problème. Seules la copie et la [copie de la copie] présentaient ce problème. J'ai vérifié la version du noyau et la version de l'application. C'est exactement la même chose pour les 3 clients. Néanmoins, j'ai appris ici que: 1. Le nom de la contrainte doit être unique dans la base de données. 2. Vous ne modifierez pas "sys.tables par exemple. Sys.indexes" SQL ne vous laissera pas modifier les paramètres par défaut de toute façon. 3. «table1» et «dbo.table1» peuvent être des tables séparées. 4. Tout comme l'index, les tables peuvent également être supprimées de SSMS et synchronisées à nouveau depuis AOT. Donc un peu d'apprentissage ici :)
S'il s'agit d'un
INDEXpourquoi essayez-vous deDROPuneCONTRAINTE?@Larnu Merci. Édité. Impossible de supprimer l'index mais l'index est visible dans sys.indexes.
Quelle était la déclaration que vous avez lancée et quelle était l'erreur? N'oubliez pas, nous ne pouvons pas voir ce que vous voyez
@Larnu Mise à jour de l'instruction t-sql ainsi que de l'erreur dans la question.
Les résultats montrent que la contrainte de clé primaire existe déjà. Pour le supprimer, 'ALTER TABLE "dbo" .ACOCOSTCENTERATTRIBUTEVALUE_BR DROP CONSTRAINT I_100013RECID`;'
@DanGuzman Oui. Mais l'index n'est pas visible dans le tableau. Mais est visible dans sys.indexes. Question mise à jour avec instantané des index de table.
Avez-vous actualisé l'explorateur d'objets SSMS? Les DMV ne mentent pas.
@DanGuzman MicrosoftDynamicsAX gère également les index et les tables d'Application Server. Si je supprime une table de SSMS puis que je synchronise à partir de Microsoft Dynamics, la table réapparaîtra avec tout le schéma mais moins les données. Il y a un conflit avec le serveur d'applications et la base de données du serveur SQL.
@MYGz, je ne voulais pas suggérer que vous ne dites pas la vérité, je veux dire que la requête DMV montre ce qui se trouve réellement dans la base de données. Donc, soit SSMS doit être actualisé, soit la requête a été exécutée dans une base de données différente de celle du contexte SSMS OE. La synchronisation du dictionnaire est un problème différent.
Avez-vous essayé une compilation complète et une synchronisation DB complète?
@AlexKwitny Salut Alex, j'ai inclus des informations supplémentaires, merci de bien vouloir vérifier. J'ai exécuté la compilation complète avec la ligne de commande AXBuild.exe, puis j'ai exécuté la synchronisation complète du datadictionary. Mais l'erreur persiste. Dois-je également essayer de compiler AOT avec le clic droit? Prend près de 5 heures et plus sur le système sur lequel je travaille.
@DanGuzman Est-il possible de modifier directement les tables sys.indexes, sys.key_constraints? Il lance une erreur: «Les mises à jour ad hoc des catalogues système ne sont pas autorisées. J'utilise MSSQL 2012.
@MYGz, il ne faut jamais modifier les tables système. Ce n'est pas la solution à votre problème. Je suppose que vous avez déjà une contrainte avec sur une table différente avec le même nom. Essayez d'exécuter
SELECT OBJECT_NAME (object_id) AS TableName, * FROM sys.indexes AS I ORDER BY TableName, i.name;@DanGuzman Merci. Tout comme vous, tout le monde a suggéré de ne pas toucher les tables sys. J'ai finalement trouvé la solution avec beaucoup de discussions avec d'autres DBA.