Tentative d'insertion d'une valeur non unique dans un index unique. Tentative d'insertion d'une valeur non unique dans un index unique Supprimer les index non uniques dans le fichier 1s 8

Vous êtes tombé sur un message contenant les lignes :
Fournisseur Microsoft OLE DB pour serveur SQL: CREATE UNIQUE INDEX terminé car une clé en double a été trouvée pour l'ID d'index
ou
Impossible d'insérer une ligne de clé en double dans l'objet
ou
Tentative d'insertion d'une valeur non unique dans un index unique.

Options de solutions :

1. Dans le studio de gestion SQL Server, nous détruisons physiquement le mauvais index (dans mon cas, il s'agissait d'un index sur la table des totaux du registre comptable). En 1C, nous distribuerons les documents défectueux. En mode test et correction, cochez les cases de réindexation des tableaux + recalcul des totaux. 1C recrée l'index sans erreur. Nous réalisons des documents précédemment échoués.

2. 1) À l'aide de Management Studio 2005, j'ai généré un script de création pour créer un index, qui était bogué, et je l'ai enregistré dans un fichier.
2) J'ai tué manuellement l'index de la table _AccumRgTn19455
3) Lancer une requête comme
Code SQL S_elect count (*) index_fields
DE AccumRgTn19455
GROUP BY champ_index
AVOIR compte (*) > 1
Une fois l'index tué, j'ai affiché 15 enregistrements en double, bien qu'avant l'exécution de l'étape 2, la requête n'ait rien renvoyé.
4) J'ai parcouru tous les enregistrements et nettoyé manuellement les doublons. En fait, j'ai également utilisé le traitement "Structure du rapport" pour comprendre à quoi j'avais affaire. Il s'est avéré que la table _AccumRgTn19455 stocke le registre d'accumulation "Sortie de produit (comptabilité fiscale)". J'étais encore en train de fouiller avec des requêtes SQL, j'ai identifié 15 documents non uniques, et après avoir terminé toutes les actions, j'ai vérifié dans 1C que ces documents étaient traités normalement, sans erreurs. Bien sûr, cela ne vaut pas la peine de nettoyer les tables au hasard : il est important de comprendre ce qui est nettoyé et comment cela peut s'avérer.
5) Lancement d'une demande de création d'index, qui a été enregistrée dans un fichier.
6) J'ai basculé la base de données en mode mono-utilisateur et exécuté dbcc checkdb - cette fois, aucune erreur n'a été émise.
7) Déplacement de la base en mode mono-utilisateur.
Ça y est... le problème est vaincu. Eh bien, en 1C, j'ai lancé "Test et correction", tout s'est bien passé là aussi, j'ai arrêté de jurer sur un index non unique.

3. Si la non-unicité réside dans les dates avec des valeurs nulles, alors le problème est résolu en créant une base avec un paramètre de décalage égal à 2000.

1. Si le problème est le chargement de la base de données, alors :
1.1. Si vous téléchargez (utilisez le fichier dt) dans la base de données MS SQL Server, lors de la création de la base de données, avant de télécharger, spécifiez le décalage de date - 2000.
Si la base a déjà été créée avec l'offset 0, créez-en une nouvelle à partir de 2000.

1.2. S'il est possible de travailler avec la base de données dans la version du fichier, effectuez les tests et corrections, ainsi que la configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Recherche de liens invalides.

1.3. S'il n'y a pas de version de fichier, essayez de charger de DT vers une version client/serveur avec DB2 (qui est moins exigeante sur l'unicité), puis faites Test and Fix, et aussi Configuration - Vérifier la configuration - Vérifier l'intégrité logique de la configuration + Rechercher invalide les références.

1.4. Pour isoler le problème, vous pouvez déterminer les données de l'objet dont le chargement a échoué. Pour cela, vous devez activer le traçage au démarrage dans l'utilitaire Profiler ou activer l'enregistrement dans le journal des événements technologiques DBMSSQL et EXCP.

2. Si le problème de non unicité se manifeste lors du travail des utilisateurs :

2.1. Trouvez la demande de problème en utilisant la méthode du paragraphe 1.4.

2.1.2. Parfois une erreur se produit lors de l'exécution des requêtes, par exemple :

Cette erreur est due au fait que dans le module de registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "RegisterRecalculs", la requête ne contient pas le mot de service "DIVERS".
Code 1C v 8.x C'est-à-dire devrait être:
Demande = Nouvelle demande (
"CHOIX DIVERS
| Basic.PhysFace,
. . . . .
Dans les dernières versions ZUP et UPP publiées, l'erreur ne se produit pas, car il y a "DIVERS".

2.2. Après avoir trouvé l'index problématique du paragraphe précédent, vous devez trouver une entrée non unique.
2.2.1. Script Fish pour définir des enregistrements non uniques à l'aide de SQL :
Code SQL S_select COUNT (*) Compteur,<перечисление всех полей соответствующего индекса>de<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AVOIR Compteur> 1

2.2.2 Exemple. L'index dans l'erreur s'appelle "_Document140_VT1385_IntKeyIndNG".
Liste des champs du tableau :
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Avant d'effectuer la procédure ci-dessous, sauvegarde Base de données.
Exécuter dans l'analyseur de requêtes MS SQL Server :
Code SQL S_elect count (*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
regrouper par _Document140_IDRRef, _KeyField
ayant compte (*)> 1
Utilisez-le pour connaître les valeurs des colonnes _Document140_IDRRef, _KeyField, les enregistrements en double (id, clé).

Sur demande:
S_choisir le code SQL *
de _Document140_VT1385
ou _Document140_IDRRef = id2 et _KeyField = key2 ou ...
regardez les valeurs des autres colonnes d'enregistrements en double.
Si les deux entrées ont des valeurs significatives et que les valeurs sont différentes, corrigez la valeur _KeyField pour qu'elle soit unique. Pour cela, définissez la valeur maximale occupée _KeyField (keymax) :
Code SQL S_elect max (_KeyField)
de _Document140_VT1385
où _Document140_IDRRef = id1
Remplacez la valeur _KeyField dans l'une des entrées en double par la bonne :
Code de mise à jour SQL _Document140_VT1385
définir _KeyField = keymax + 1
Ici _LineNo1386 = - condition supplémentaire, qui vous permet de sélectionner l'une des deux entrées en double.

Si l'une (ou les deux) des entrées en double présente des valeur incorrecte, alors vous devez le supprimer :
Suppression du code SQL de _Document140_VT1385
où _Document140_IDRRef = id1 et _LineNo1386 = lineno1
Si les enregistrements en double ont les mêmes valeurs dans toutes les colonnes, vous devez en laisser un :
SQL S_select distinct *
dans # tmp1
de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

Supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

I_insert dans _Document140_VT1385
S_elect # tmp1

D_rop table # tmp1

La procédure décrite doit être exécutée pour chaque paire d'enregistrements en double.

2.2.3. Deuxième exemple :
Code SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Référence8_
GROUP BY _IDRRef, _Description
AVOIR (COMPTE (*)> 1)

2.3.4 Un exemple de définition d'enregistrements non uniques à l'aide de la requête 1C : Entreprise :
Code 1C v 8.x SELECT Référence.Lien
Référence FROM Référence AS Référence
CHARGER PAR Référence.Lien
AVOIR QUANTITÉ (*)> 1

Vous êtes tombé sur un message contenant les lignes :
Fournisseur Microsoft OLE DB pour SQL Server : CREATE UNIQUE INDEX terminé car une clé en double a été trouvée pour l'ID d'index
ou
Impossible d'insérer une ligne de clé en double dans l'objet
ou
Tentative d'insertion d'une valeur non unique dans un index unique.

Options de solutions :

1. Dans le studio de gestion SQL Server, nous détruisons physiquement le mauvais index (dans mon cas, il s'agissait d'un index sur la table des totaux du registre comptable). En 1C, nous distribuerons les documents défectueux. En mode test et correction, cochez les cases de réindexation des tableaux + recalcul des totaux. 1C recrée l'index sans erreur. Nous réalisons des documents précédemment échoués.

2. 1) À l'aide de Management Studio 2005, j'ai généré un script de création pour créer un index, qui était bogué, et je l'ai enregistré dans un fichier.
2) J'ai tué manuellement l'index de la table _AccumRgTn19455
3) Lancer une requête comme
Code SQL S_elect count (*) index_fields
DE AccumRgTn19455
GROUP BY champ_index
AVOIR compte (*) > 1
Une fois l'index tué, j'ai affiché 15 enregistrements en double, bien qu'avant l'exécution de l'étape 2, la requête n'ait rien renvoyé.
4) J'ai parcouru tous les enregistrements et nettoyé manuellement les doublons. En fait, j'ai également utilisé le traitement "Structure du rapport" pour comprendre à quoi j'avais affaire. Il s'est avéré que la table _AccumRgTn19455 stocke le registre d'accumulation "Sortie de produit (comptabilité fiscale)". J'étais encore en train de fouiller avec des requêtes SQL, j'ai identifié 15 documents non uniques, et après avoir terminé toutes les actions, j'ai vérifié dans 1C que ces documents étaient traités normalement, sans erreurs. Bien sûr, cela ne vaut pas la peine de nettoyer les tables au hasard : il est important de comprendre ce qui est nettoyé et comment cela peut s'avérer.
5) Lancement d'une demande de création d'index, qui a été enregistrée dans un fichier.
6) J'ai basculé la base de données en mode mono-utilisateur et exécuté dbcc checkdb - cette fois, aucune erreur n'a été émise.
7) Déplacement de la base en mode mono-utilisateur.
Ça y est... le problème est vaincu. Eh bien, en 1C, j'ai lancé "Test et correction", tout s'est bien passé là aussi, j'ai arrêté de jurer sur un index non unique.

3. Si la non-unicité réside dans les dates avec des valeurs nulles, alors le problème est résolu en créant une base avec un paramètre de décalage égal à 2000.

1. Si le problème est le chargement de la base de données, alors :
1.1. Si vous téléchargez (utilisez le fichier dt) dans la base de données MS SQL Server, lors de la création de la base de données, avant de télécharger, spécifiez le décalage de date - 2000.
Si la base a déjà été créée avec l'offset 0, créez-en une nouvelle à partir de 2000.

1.2. S'il est possible de travailler avec la base de données dans la version du fichier, effectuez les tests et corrections, ainsi que la configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Recherche de liens invalides.

1.3. S'il n'y a pas de version de fichier, essayez de charger de DT vers une version client/serveur avec DB2 (qui est moins exigeante sur l'unicité), puis faites Test and Fix, et aussi Configuration - Vérifier la configuration - Vérifier l'intégrité logique de la configuration + Rechercher invalide les références.

1.4. Pour isoler le problème, vous pouvez déterminer les données de l'objet dont le chargement a échoué. Pour cela, vous devez activer le traçage au démarrage dans l'utilitaire Profiler ou activer l'enregistrement dans le journal des événements technologiques DBMSSQL et EXCP.

2. Si le problème de non unicité se manifeste lors du travail des utilisateurs :

2.1. Trouvez la demande de problème en utilisant la méthode du paragraphe 1.4.

2.1.2. Parfois une erreur se produit lors de l'exécution des requêtes, par exemple :

Cette erreur est due au fait que dans le module de registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "RegisterRecalculs", la requête ne contient pas le mot de service "DIVERS".
Code 1C v 8.x C'est-à-dire devrait être:
Demande = Nouvelle demande (
"CHOIX DIVERS
| Basic.PhysFace,
. . . . .
Dans les dernières versions ZUP et UPP publiées, l'erreur ne se produit pas, car il y a "DIVERS".

2.2. Après avoir trouvé l'index problématique du paragraphe précédent, vous devez trouver une entrée non unique.
2.2.1. Script Fish pour définir des enregistrements non uniques à l'aide de SQL :
Code SQL S_select COUNT (*) Compteur,<перечисление всех полей соответствующего индекса>de<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AVOIR Compteur> 1

2.2.2 Exemple. L'index dans l'erreur s'appelle "_Document140_VT1385_IntKeyIndNG".
Liste des champs du tableau :
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Sauvegardez votre base de données avant de suivre la procédure ci-dessous.
Exécuter dans l'analyseur de requêtes MS SQL Server :
Code SQL S_elect count (*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
regrouper par _Document140_IDRRef, _KeyField
ayant compte (*)> 1
Utilisez-le pour connaître les valeurs des colonnes _Document140_IDRRef, _KeyField, les enregistrements en double (id, clé).

Sur demande:
S_choisir le code SQL *
de _Document140_VT1385
ou _Document140_IDRRef = id2 et _KeyField = key2 ou ...
regardez les valeurs des autres colonnes d'enregistrements en double.
Si les deux entrées ont des valeurs significatives et que les valeurs sont différentes, corrigez la valeur _KeyField pour qu'elle soit unique. Pour cela, définissez la valeur maximale occupée _KeyField (keymax) :
Code SQL S_elect max (_KeyField)
de _Document140_VT1385
où _Document140_IDRRef = id1
Remplacez la valeur _KeyField dans l'une des entrées en double par la bonne :
Code de mise à jour SQL _Document140_VT1385
définir _KeyField = keymax + 1
Ici _LineNo1386 = est une condition supplémentaire qui vous permet de sélectionner l'une des deux entrées en double.

Si l'une (ou les deux) des entrées en double a une valeur manifestement incorrecte, elle doit être supprimée :
Suppression du code SQL de _Document140_VT1385
où _Document140_IDRRef = id1 et _LineNo1386 = lineno1
Si les enregistrements en double ont les mêmes valeurs dans toutes les colonnes, vous devez en laisser un :
SQL S_select distinct *
dans # tmp1
de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

Supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

I_insert dans _Document140_VT1385
S_elect # tmp1

D_rop table # tmp1

La procédure décrite doit être exécutée pour chaque paire d'enregistrements en double.

2.2.3. Deuxième exemple :
Code SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Référence8_
GROUP BY _IDRRef, _Description
AVOIR (COMPTE (*)> 1)

2.3.4 Un exemple de définition d'enregistrements non uniques à l'aide de la requête 1C : Entreprise :
Code 1C v 8.x SELECT Référence.Lien
Référence FROM Référence AS Référence
CHARGER PAR Référence.Lien
AVOIR QUANTITÉ (*)> 1

Cet article décrira ce qu'il faut faire si, lorsque vous travaillez avec 1C: Enterprise 8.1, vous rencontrez un message contenant les lignes :

Impossible d'insérer une ligne de clé en double dans l'objet

Tentative d'insertion d'une valeur non unique dans un index unique.

Qu'est-ce qu'un indice ?

Les index sont une structure qui permet d'accéder rapidement aux lignes d'un tableau en fonction des valeurs d'une ou plusieurs de ses colonnes.
Un index contient des clés créées à partir d'une ou plusieurs colonnes d'une table ou d'une vue, et des pointeurs qui correspondent à l'emplacement de stockage des données.
Les index réduisent la quantité de données qui doivent être lues pour renvoyer un jeu de résultats.

Bien qu'un index soit associé à une colonne (ou des colonnes) spécifique dans une table, il s'agit toujours d'un objet de base de données à part entière.

Les index des tables de la base de données 1C : Enterprise sont créés implicitement lors de la création des objets de configuration, ainsi qu'avec certains paramètres des objets de configuration.

La nature physique des index dans MS SQL Server 2005.

Les données physiques sont stockées sur des pages de 8 Ko... Immédiatement après sa création, alors que la table n'a pas d'index, la table ressemble à un tas de données. Les enregistrements n'ont pas d'ordre de stockage spécifique.
Lorsque vous souhaitez accéder aux données, SQL Server produira analyse de tableau(numérisation du tableau). SQL Server analyse la table entière pour trouver les enregistrements qu'il recherche.
Ceci explique les fonctions de base des index :
- augmenter la vitesse d'accès aux données,
- prise en charge de l'unicité des données.

Malgré leurs avantages, les indices présentent également un certain nombre d'inconvénients. Le premier est les indices occuper espace supplémentaire sur disque et en mémoire vive... Chaque fois que vous créez un index, vous stockez les clés par ordre décroissant ou croissant, qui peuvent être superposées. Et plus la clé est grande/longue, plus grande taille indice. Le deuxième inconvénient est les opérations ralentissent insertion, mise à jour et suppression d'enregistrements.
Plusieurs types d'index sont implémentés dans MS SQL Server 2005 :

  • index non clusterisés ;
  • index clusterisés (ou clusterisés) ;
  • index uniques;
  • index avec colonnes incluses
  • vues indexées
  • texte intégral

Indice unique

L'unicité des valeurs dans la colonne indexée est garantie par des index uniques. Si elles sont présentes, le serveur ne permettra pas d'insérer une nouvelle valeur ou de modifier une valeur existante de sorte qu'à la suite de cette opération, deux valeurs identiques apparaissent dans la colonne.
Un index unique est une sorte de module complémentaire et peut être implémenté pour les index clusterisés et non clusterisés. Une table peut avoir un index cluster unique et de nombreux index non cluster uniques.
Les index uniques ne doivent être définis qu'en cas d'absolue nécessité. Pour garantir l'intégrité des données sur une colonne, vous pouvez définir une contrainte d'intégrité UNIQUE ou PRIMARY KEY plutôt que de recourir à des index uniques. Les utiliser uniquement pour garantir l'intégrité des données est un gaspillage d'espace dans la base de données. De plus, du temps CPU est consacré à leur maintenance.

1C : Enterprise 8.1 à partir de la version 8.1 utilise activement des index uniques en cluster. Cela signifie que lors de la conversion à partir de la version 8.0 ou du passage à partir de la version 8.1.7, vous pouvez obtenir une erreur d'index non unique.

Si les dates avec des valeurs nulles ne sont pas uniques, le problème est résolu en créant une base avec un paramètre de décalage de 2000.

Que faire?

1. Si le problème est le chargement de la base de données, alors :

1.1. Si vous téléchargez (utilisez le fichier dt) dans la base de données MS SQL Server, lors de la création de la base de données, avant de télécharger, spécifiez le décalage de date - 2000.

Si la base a déjà été créée avec l'offset 0, créez-en une nouvelle à partir de 2000.

1.2. S'il est possible de travailler avec la base de données dans la version du fichier, effectuez alors des tests et des corrections, ainsi que la configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Recherche de liens invalides.

1.3. S'il n'y a pas de version de fichier, essayez de charger de DT vers une version client/serveur avec DB2 (qui est moins exigeante sur l'unicité), puis faites Test and Fix, et aussi Configuration - Vérifier la configuration - Vérifier l'intégrité logique de la configuration + Rechercher invalide les références.

1.4. Pour isoler le problème, vous pouvez déterminer les données de l'objet dont le chargement a échoué. Pour cela, vous devez activer le traçage au démarrage dans l'utilitaire Profiler ou activer l'enregistrement dans le journal des événements technologiques DBMSSQL et EXCP.

1.5. Si un nœud est disponible (plans d'échange), alors effectuez un échange. Vous pouvez également effectuer le paragraphe 2.3.5 avant l'échange.

2. Si le problème de non unicité se manifeste lors du travail des utilisateurs :

2.1. Trouvez la demande de problème en utilisant la méthode du paragraphe 1.4.

2.1.2. Parfois une erreur se produit lors de l'exécution des requêtes, par exemple :

Cette erreur est due au fait que dans le module de registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "RegisterRecalculs" dans la demande, il n'y a pas de mot de service "DIVERS".

Celles. devrait être:

Demande = Nouvelle demande (
CHOISISSEZ DIVERS
| Basic.PhysFace,

Dans les dernières versions ZUP et UPP publiées, l'erreur ne se produit pas, car il y a "DIVERS".

2.2. Après avoir trouvé l'index problématique du paragraphe précédent, vous devez trouver une entrée non unique.

2.2.1. Script Fish pour définir des enregistrements non uniques à l'aide de SQL :
SELECTIONNER COMPTE (*) Compteur,<перечисление всех полей соответствующего индекса>de<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AVOIR Compteur> 1

2.2.2 Exemple. L'index dans l'erreur est nommé "_Document140_VT1385_IntKeyIndNG".

Liste des champs du tableau :

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld13RR1393_R13F

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_Ref_RFRld2226

Sauvegardez votre base de données avant de suivre la procédure ci-dessous.
Exécuter dans l'analyseur de requêtes MS SQL Server :

sélectionnez le nombre (*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
regrouper par _Document140_IDRRef, _KeyField
ayant compte (*)> 1

Utilisez-le pour connaître les valeurs des colonnes _Document140_IDRRef, _KeyField, les enregistrements en double (id, clé).

Sur demande:

sélectionnez *
de _Document140_VT1385
ou _Document140_IDRRef = id2 et _KeyField = key2 ou ...

regardez les valeurs des autres colonnes d'enregistrements en double.

Si les deux entrées ont des valeurs significatives et que les valeurs sont différentes, corrigez la valeur _KeyField pour qu'elle soit unique. Pour ce faire, définissez la valeur maximale occupée _KeyField (keymax) :

sélectionnez max (_KeyField)
de _Document140_VT1385
où _Document140_IDRRef = id1

Remplacez la valeur _KeyField dans l'une des entrées en double par la bonne :

mettre à jour _Document140_VT1385
définir _KeyField = keymax + 1

Ici _LineNo1386 = est une condition supplémentaire qui vous permet de sélectionner l'une des deux entrées en double.

Si l'une (ou les deux) des entrées en double a une valeur manifestement incorrecte, elle doit être supprimée :


où _Document140_IDRRef = id1 et _LineNo1386 = lineno1

Si les enregistrements en double ont les mêmes valeurs dans toutes les colonnes, vous devez en laisser un :

sélectionner distinct *
dans # tmp1
de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

insérer dans _Document140_VT1385
sélectionnez # tmp1

supprimer la table # tmp1

La procédure décrite doit être exécutée pour chaque paire d'enregistrements en double.

2.2.3. Deuxième exemple :

SELECTIONNER LE COMPTE (*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Référence8_
GROUP BY _IDRRef, _Description
AVOIR (COMPTE (*)> 1)

2.3.4 Un exemple de définition d'enregistrements non uniques à l'aide de la requête 1C : Entreprise :

ou pour la comptabilité

SÉLECTIONNER
Sous-requête.Période,
Sous-requête.Registrateur,
<измерения>,
SUM (Sous-requête.Nombre d'enregistrements) AS Nombre d'enregistrements
DE
(SÉLECTIONNER
Période d'autosuffisance AS Période
Registraire autonome AS Registrar,
<измерения>,
1 AS Nombre d'enregistrements
DE
Registre de la comptabilité.

CHARGER PAR
Sous-requête.Période,
Sous-requête.Registrateur,
<измерения>

AYANT
SOMME (Sous-requête.Nombre d'enregistrements)> 1

2.3.5 Rendre l'index subdat non unique. Scriptez l'index à l'aide de Management Studio.

2.3.6 Un cas particulier lors de l'échange dans la RDB. L'erreur tombe sur les tableaux "auxiliaires" associés au calcul des totaux ou des dimensions. Par exemple:

Une erreur s'est produite lors de l'appel de la méthode de contexte (Write) : Tentative d'insertion d'une valeur non unique dans un index unique :
Fournisseur Microsoft OLE DB pour SQL Server : impossible d'insérer une ligne de clé en double dans l'objet « dbo._AccntRegED10319 » avec l'index unique « _Accnt10319_ByPeriod_TRNRN ».
HRESULT = 80040E2F, SQLSrvr : état d'erreur = 1, gravité = E, natif = 2601, ligne = 1

Dans ce cas, avant le chargement, désactivez l'utilisation des totaux, chargez le message, activez l'utilisation des totaux et recalculez.

Vous êtes tombé sur un message contenant les lignes :
Fournisseur Microsoft OLE DB pour SQL Server : CREATE UNIQUE INDEX terminé car une clé en double a été trouvée pour l'ID d'index
ou
Impossible d'insérer une ligne de clé en double dans l'objet
ou
Tentative d'insertion d'une valeur non unique dans un index unique.

Options de solutions :

1. Dans le studio de gestion SQL Server, nous détruisons physiquement le mauvais index (dans mon cas, il s'agissait d'un index sur la table des totaux du registre comptable). En 1C, nous distribuerons les documents défectueux. En mode test et correction, cochez les cases de réindexation des tableaux + recalcul des totaux. 1C recrée l'index sans erreur. Nous réalisons des documents précédemment échoués.

2. 1) À l'aide de Management Studio 2005, j'ai généré un script de création pour créer un index, qui était bogué, et je l'ai enregistré dans un fichier.
2) J'ai tué manuellement l'index de la table _AccumRgTn19455
3) Lancer une requête comme
Code SQL S_elect count (*) index_fields
EN OM AccumRgTn19455
GROUP BY champ_index
AVOIR compte (*) > 1
Une fois l'index tué, j'ai affiché 15 enregistrements en double, bien qu'avant l'exécution de l'étape 2, la requête n'ait rien renvoyé.
4) J'ai parcouru tous les enregistrements et nettoyé manuellement les doublons. En fait, j'ai également utilisé le traitement "Structure du rapport" pour comprendre à quoi j'avais affaire. Il s'est avéré que la table _AccumRgTn19455 stocke le registre d'accumulation "Sortie de produit (comptabilité fiscale)". J'étais encore en train de fouiller avec des requêtes SQL, j'ai identifié 15 documents non uniques, et après avoir terminé toutes les actions, j'ai vérifié dans 1C que ces documents étaient traités normalement, sans erreurs. Bien sûr, cela ne vaut pas la peine de nettoyer les tables au hasard : il est important de comprendre ce qui est nettoyé et comment cela peut s'avérer.
5) Lancement d'une demande de création d'index, qui a été enregistrée dans un fichier.
6) J'ai basculé la base de données en mode mono-utilisateur et exécuté dbcc checkdb - cette fois, aucune erreur n'a été émise.
7) Déplacement de la base en mode mono-utilisateur.
Ça y est... le problème est vaincu. Eh bien, en 1C, j'ai lancé "Test et correction", tout s'est bien passé là aussi, j'ai arrêté de jurer sur un index non unique.

3. Si la non-unicité réside dans les dates avec des valeurs nulles, alors le problème est résolu en créant une base avec un paramètre de décalage égal à 2000.

1. Si le problème est le chargement de la base de données, alors :
1.1. Si vous téléchargez (utilisez le fichier dt) dans la base de données MS SQL Server, lors de la création de la base de données, avant de télécharger, spécifiez le décalage de date - 2000.
Si la base a déjà été créée avec l'offset 0, créez-en une nouvelle à partir de 2000.

1.2. S'il est possible de travailler avec la base de données dans la version du fichier, effectuez les tests et corrections, ainsi que la configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Recherche de liens invalides.

1.3. S'il n'y a pas de version de fichier, essayez de charger de DT vers une version client/serveur avec DB2 (qui est moins exigeante sur l'unicité), puis faites Test and Fix, et aussi Configuration - Vérifier la configuration - Vérifier l'intégrité logique de la configuration + Rechercher invalide les références.

1.4. Pour isoler le problème, vous pouvez déterminer les données de l'objet dont le chargement a échoué. Pour cela, vous devez activer le traçage au démarrage dans l'utilitaire Profiler ou activer l'enregistrement dans le journal des événements technologiques DBMSSQL et EXCP.

2. Si le problème de non unicité se manifeste lors du travail des utilisateurs :

2.1. Trouvez la demande de problème en utilisant la méthode du paragraphe 1.4.

2.1.2. Parfois une erreur se produit lors de l'exécution des requêtes, par exemple :

Cette erreur est due au fait que dans le module de registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "RegisterRecalculs", la requête ne contient pas le mot de service "DIVERS".
Code 1C v 8.x C'est-à-dire devrait être:
Demande = Nouvelle demande (
"CHOIX DIVERS
| Basic.PhysFace,
. . . . .
Dans les dernières versions ZUP et UPP publiées, l'erreur ne se produit pas, car il y a "DIVERS".

2.2. Après avoir trouvé l'index problématique du point précédent, vous devez trouver une entrée non unique.
2.2.1. Script Fish pour définir des enregistrements non uniques à l'aide de SQL :
Code SQL S_select COUNT (*) Compteur,<перечисление всех полей соответствующего индекса>de<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AVOIR Compteur> 1

2.2.2 Exemple. L'index dans l'erreur s'appelle "_Document140_VT1385_IntKeyIndNG".
Liste des champs du tableau :
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Sauvegardez votre base de données avant de suivre la procédure ci-dessous.
Exécutez l'analyseur de requêtes MS SQL Server :
Code SQL S_elect count (*), _Document140_IDRRef, _KeyField
du _Document140_VT1385
regrouper par _Document140_IDRRef, _KeyField
ayant compte (*)> 1
Utilisez-le pour connaître les valeurs des colonnes _Document140_IDRRef, _KeyField, les enregistrements en double (id, clé).

Sur demande:
S_choisir le code SQL *
du _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1 ou _Document140_IDRRef = id2 et _KeyField = key2 ou ...
regardez les valeurs des autres colonnes d'enregistrements en double.
Si les deux entrées ont des valeurs significatives et que les valeurs sont différentes, corrigez la valeur _KeyField pour qu'elle soit unique. Pour cela, définissez la valeur maximale occupée _KeyField (keymax) :
Code SQL S_elect max (_KeyField)
du _Document140_VT1385
où _Document140_IDRRef = id1
Remplacez la valeur _KeyField dans l'une des entrées en double par la bonne :
Mise à jour SQL _Document140_VT1385
définir _KeyField = keymax + 1

Ici _LineNo1386 = est une condition supplémentaire qui vous permet de sélectionner l'une des deux entrées en double.

Si l'une (ou les deux) des entrées en double a une valeur manifestement incorrecte, elle doit être supprimée :
Suppression du code SQL de _Document140_VT1385
où _Document140_IDRRef = id1 et _LineNo1386 = lineno1
Si les enregistrements en double ont les mêmes valeurs dans toutes les colonnes, vous devez en laisser un :
SQL S_select distinct *
dans # tmp1
de _Document140_VT1385

Supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = key1

I_insert dans _Document140_VT1385
S_elect # tmp1

D_rop table # tmp1

La procédure décrite doit être exécutée pour chaque paire d'enregistrements en double.

2.2.3. Deuxième exemple :
Code SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Référence8_
GROUP BY _IDRRef, _Description
AVOIR (COMPTE (*)> 1)

2.3.4 Un exemple de définition d'enregistrements non uniques à l'aide de la requête 1C : Entreprise :
Code 1C v 8.x SELECT Référence.Lien
Référence FROM Référence AS Référence
CHARGER PAR Référence.Lien
AVOIR QUANTITÉ (*)> 1

Informations extraites du site