Vous êtes tombé sur un message contenant les lignes :
Fournisseur Microsoft OLE DB pour SQL Server : CREATE UNIQUE INDEX a été interrompu car une clé en double a été trouvée pour l'ID d'index
ou
Impossible d'insérer la 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 l'index défaillant (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 tables + recalcul des totaux. 1C recrée l'index sans erreur. Nous réalisons des documents précédemment échoués.

2. 1) Avec 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) Tué manuellement l'index de la table _AccumRgTn19455
3) Lancé une requête comme
Code SQL S_elect count(*), index_fields
DE AccumRgTn19455
GROUP BY index_field
AYANT compte(*)>1
Une fois l'index supprimé, j'ai affiché 15 enregistrements en double, bien qu'avant l'étape 2, la requête ne renvoie rien.
4) J'ai parcouru tous les enregistrements et nettoyé manuellement les doublons. En fait, j'ai également utilisé le traitement "Report Structure" pour comprendre à quoi j'avais affaire en général. Il s'est avéré que la table _AccumRgTn19455 stocke le registre d'accumulation "Sortie de produit (comptabilité fiscale)". J'ai également fouillé avec des requêtes sql, identifié 15 documents non uniques, et après avoir terminé toutes les actions, j'ai vérifié en 1C que ces documents étaient traités normalement, sans erreur. Bien sûr, ce n'est pas la peine de nettoyer les tables au hasard comme ça : il est important de comprendre ce qui est nettoyé et ce que cela peut devenir.
5) Lancé une requête pour créer un index, qui a été enregistré dans un fichier.
6) Commutation de la base de données en mode mono-utilisateur et exécution de dbcc checkdb - cette fois, il n'y a pas eu d'erreurs.
7) Transféré la base en mode mono-utilisateur.
Tout ... le problème est vaincu. Bon, même en 1C j'ai lancé "Test et Correction", là aussi tout s'est bien passé, ça a arrêté de jurer sur un index non unique.

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

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

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

1.3. S'il n'y a pas de variante de fichier, essayez de charger de DT vers une variante client/serveur DB2 (qui est moins exigeante en matière d'unicité), puis exécutez Test et réparation et configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Recherche de mauvaise référence.

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

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

2.1. Trouvez la requête problématique 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 du registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "Registre des recalculs" dans la demande, il n'y a pas de mot de service "DIFFERENT".
Code 1C v 8.x C'est-à-dire devrait être:
Demande = Nouvelle demande(
"CHOISISSEZ DIFFÉRENTS
| Basique.Individuel,
. . . . .
Dans les dernières versions publiées de ZUP et UPP, l'erreur ne se produit pas, car. il est écrit "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_elect COUNT(*) Compteur,<перечисление всех полей соответствующего индекса>depuis<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AYANT Compteur > 1

2.2.2 Exemple. L'index dans l'erreur s'appelle "_Document140_VT1385_IntKeyIndNG".
Liste des champs de table :
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _ Fld1393_RR Réf _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Avant de suivre la procédure ci-dessous, faites sauvegarde Base de données.
Exécutez dans l'Analyseur de requêtes MS SQL Server :
Code SQL S_elect count(*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
grouper par _Document140_IDRRef, _KeyField
ayant count(*) > 1
Utilisez-le pour connaître les valeurs des colonnes _Document140_IDRRef, _KeyField, enregistrements en double (id, clé).

Avec une demande :
Code SQL S_select *
de _Document140_VT1385
ou _Document140_IDRRef = id2 et _KeyField = clé2 ou ...
regardez les valeurs des autres colonnes d'entrées en double.
Si les deux entrées ont des valeurs significatives et que ces valeurs sont différentes, fixez la valeur de _KeyField pour qu'elle soit unique. Pour ce faire, définissez la valeur maximale occupée de _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 :
Mise à jour du code 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 erronée, elle doit être supprimée :
Suppression du code SQL de _Document140_VT1385
où _Document140_IDRRef = id1 et _LineNo1386 = lineno1
Si des entrées en double ont mêmes valeurs dans toutes les colonnes, il faut en laisser une :
Code SQL S_elect distinct *
dans #tmp1
de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = clé1

Supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = clé1

I_nsert into _Document140_VT1385
S_elect #tmp1

Tableau D_rop #tmp1

La procédure décrite doit être effectuée pour chaque paire d'entrées 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
AYANT (COMPTER(*) > 1)

2.3.4 Exemple de définition d'enregistrements non uniques à l'aide d'une requête 1C:Enterprise :
Code 1C v 8.x CHOOSE Manuel Lien
Annuaire FROM. Annuaire AS Annuaire
PAR GROUPE
AYANT QUANTITE(*) > 1

Une erreur se produit si certains objets, attributs, subconto ont une valeur NULL dans la base de données, mais ils ne peuvent pas avoir une telle valeur. Et cette erreur n'apparaît que dans les bases de données SQL. Ceux. si une telle base de données est déchargée dans un fichier, cette erreur ne sera pas là. Parce que la base de fichiers a ses propres tables (4 au total), et SQL a les siennes. Et la base de données SQL réagit de manière critique à de telles valeurs dans ses tables.

Ce problème n'est résolu par aucun test (ni externe ni interne) dans aucune variante de base de données (SQL ou fichier) et même la procédure _1sp_DBReindex dans le gestionnaire SQL, qui semble être censée restructurer les tables en SQL.

Analysons la solution au problème en utilisant l'exemple de la transition de Accounting 3.0 PROF à CORP. Après la transition, le compte 68.01 a un nouveau sous-conto RegistrationIn Tax Authority. Et puis, dans les bases de données sur SQL, toute création dans la version PROF des documents utilisant ce compte ne sera pas recâblée. L'erreur ci-dessus apparaîtra. Parce que ce nouveau sous-conto pour les anciens documents, dans les écritures, sera écrit avec une valeur NULL (bien qu'il devrait y avoir une valeur vide, eh bien, ou d'une manière ou d'une autre l'administration fiscale).

Pour résoudre cette erreur, vous devez supprimer les valeurs NULL là où elles ne devraient pas être. Dans ce cas, dans les documents où le sous-conto RegistrationIn Tax Authority est utilisé. Vous pouvez le faire en écrivant un traitement qui remplacera NULL par une valeur vide (le traitement prêt peut être téléchargé à partir de cet article). Faites le traitement, tk. une tentative de modification manuelle de la valeur de ce sous-conto dans les écritures de pièces conduit à la même erreur.

Le traitement pour remplacer les "NULL" dans tous les sous-contacts L'enregistrementDans l'administration fiscale peut être téléchargé à partir de cet article, ci-dessous.

MAIS cela ne fonctionnera pas pour remplacer NULL dans la base de données SQL, la même erreur sera générée lors du traitement. Par conséquent, vous devez faire ceci :

1. Téléchargez une base de données SQL déjà fonctionnelle, traduite en version CORP, dans dt'snik (dans le configurateur Administration - Télécharger la base de données - sélectionnez où télécharger la base de données sous la forme d'un fichier *.dt)

2. Téléchargez les dt dans la base de fichiers (dans une base de données de fichiers inutile ou pré-préparée, propre, dans le configurateur Administration - Charger la base de données - sélectionnez les dt précédemment déchargés)

3. Effectuez le traitement dans la base de fichiers (il n'y aura pas d'erreur et tous les NULL seront correctement remplacés) (comment effectuer le traitement est décrit ci-dessous)

5. Maintenant, au contraire, déchargez les dt de la base de fichiers et chargez-les dans la base de données SQL. Désormais, lors de la publication des documents traités, il n'y aura plus d'erreurs.

Le traitement de cet article trouve tous les documents, pour la période spécifiée, dans lesquels le sous-contact RegisterIn Tax Authority apparaît dans les transactions (qui apparaît dans la version CORP), qui a une valeur NULL. Et remplace cette valeur par une valeur vide.

Dans le traitement, vous devez spécifier la période pour laquelle vous devez traiter les documents (c'est possible pour toute la période pendant laquelle les enregistrements sont conservés dans la base de données) et cliquez sur "Remplir partie tabulaire". Après cela, vous pouvez cocher les cases des documents à traiter (vous pouvez tout sélectionner) et cliquer sur le bouton "Effectuer le traitement".

En conséquence, si quelqu'un a la même erreur, mais PAS après être passé à CORP, mais par exemple après un échange, charger des données, effectuer un traitement, etc. Ensuite, il est nécessaire d'identifier où la valeur NULL a été attribuée dans un document / répertoire particulier et de supprimer cette valeur NULL de la même manière, mais par son propre traitement, mais dans l'ordre décrit ci-dessus. N'oubliez pas que NULL peut être, comme dans les écritures de documents, incl. non seulement la comptabilité, mais quelque part sous la forme d'un document / répertoire, dans certains détails, mais dans ce cas, il ne s'ouvrira probablement même pas.

De plus, si vous avez eu cette erreur lors de la publication d'un document, après avoir transféré la base de fichiers Bukh CORP vers SQL (et que la base de données était à l'origine PROF), cela signifie que les documents qui ont été créés dans la version PRO sont maintenant également dans le fichier RegistrationIn Tax Authority subcont la valeur NULL et la base de données SQL ne l'accepte pas. Et lors du chargement de la base de données en SQL, une telle erreur apparaîtra. Ici, en fait, il n'y aura pas de valeurs NULL dans la base de fichiers, mais SQL chargera exactement ces valeurs dans ses tables. Il faut donc ici forcer Base de données SQL créez ces NULL puis corrigez-les dans la base de fichiers, mais je ne vous dirai pas comment procéder.

Cet article décrira ce qu'il faut faire si, lorsque vous travaillez avec 1C:Enterprise 8.1, vous tombez sur 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'une table en fonction des valeurs d'une ou plusieurs de ses colonnes.
Un index contient des clés construites à partir d'une ou plusieurs colonnes d'une table ou d'une vue et des pointeurs qui correspondent à l'endroit où les données spécifiées sont stocké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 ou plusieurs colonnes particulières d'une table, il s'agit toujours d'un objet de base de données autonome.

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

L'essence physique des index dans MS SQL Server 2005.

Les données physiques sont stockées sur des pages de 8Ko. Immédiatement après la 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 balayage de table(balayage du tableau). SQL Server analyse la table entière pour trouver les enregistrements qu'il recherche.
A partir de là, il devient clair les fonctions de base indices :
- augmenter la vitesse d'accès aux données,
- prise en charge de l'unicité des données.

Malgré les avantages, les indices présentent également un certain nombre d'inconvénients. Le premier concerne les index. occuper lit supplémentaire sur disque et en mémoire vive. Chaque fois que vous créez un index, vous stockez les clés dans l'ordre croissant ou décroissant, qui peuvent être superposées. Et plus la clé est grande/longue, plus la taille de l'index est grande. Le deuxième inconvénient est les opérations ralentissent insérer, mettre à jour et supprimer des enregistrements.
Plusieurs types d'index sont implémentés dans l'environnement 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

Index unique

L'unicité des valeurs dans une colonne indexée est garantie par des index uniques. S'ils sont présents, le serveur ne vous permettra pas d'en insérer un nouveau ou de modifier 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 plusieurs 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 au lieu de recourir à des index uniques. Les utiliser uniquement pour assurer l'intégrité des données est un gaspillage d'espace dans la base de données. De plus, le temps CPU est également 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 8.0 ou de la migration à partir de 8.1.7, vous pouvez obtenir une erreur d'index non unique.

Si la non-unicité réside dans des 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.

Ce qu'il faut faire?

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

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

Si la base est déjà créée avec le décalage 0, créez-en une nouvelle avec 2000.

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

1.3. S'il n'y a pas de variante de fichier, essayez de charger à partir de DT vers une variante client/serveur DB2 (qui est moins pointilleux sur l'unicité), puis exécutez Test et correction, puis Configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Vérification des mauvaises références .

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

1.5. Si un nœud est disponible (plans d'échange), alors effectuez l'échange. Vous pouvez également effectuer en plus 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 requête problématique 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 du registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "Registre des recalculs" dans la demande, il n'y a pas de mot de service "DIFFERENT".

Ceux. devrait être:

Demande = Nouvelle demande(
"CHOISISSEZ DIFFÉRENTS
| Basique.Individuel,

Dans les dernières versions publiées de ZUP et UPP, l'erreur ne se produit pas, car. il dit DIFFÉRENT.

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 :
SELECT COUNT(*) Compteur,<перечисление всех полей соответствующего индекса>depuis<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AYANT Compteur > 1

2.2.2 Exemple. L'index dans l'erreur s'appelle "_Document140_VT1385_IntKeyIndNG".

Liste des champs de table :

Document140_IDRRef _KeyField _LineNo1386 _Fld1387 _Fld1388 _Fld1389 _Fld1390 _Fld1391RRef _Fld1392RRef _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRe f, _Fld222 61_RRRef

Veuillez sauvegarder votre base de données avant de suivre la procédure ci-dessous.
Exécutez dans l'Analyseur de requêtes MS SQL Server :

sélectionnez count(*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
grouper par _Document140_IDRRef, _KeyField
ayant count(*) > 1

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

Avec une demande :

sélectionner*
de _Document140_VT1385
ou _Document140_IDRRef = id2 et _KeyField = clé2 ou …

regardez les valeurs des autres colonnes d'entrées en double.

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

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

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

update_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 erronée, elle doit être supprimée :

où _Document140_IDRRef = id1 et _LineNo1386 = lineno1

Si les entrées en double ont les mêmes valeurs dans toutes les colonnes, l'une d'entre elles doit être laissée :

sélectionnez distinct *
dans #tmp1
de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = clé1

supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = clé1

insérer dans _Document140_VT1385
sélectionnez #tmp1

déposer le tableau #tmp1

La procédure décrite doit être effectuée pour chaque paire d'entrées en double.

2.2.3. Deuxième exemple :

SELECT COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Référence8_
GROUP BY _IDRRef, _Description
AYANT (COMPTER(*) > 1)

2.3.4 Exemple de définition d'enregistrements non uniques à l'aide d'une requête 1C:Enterprise :

ou pour la comptabilité

CHOISIR
Sous-requête.Période,
Sous-requête.Registrar,
<измерения>,
SUM(Sous-requête.Nombre d'enregistrements) AS Nombre d'enregistrements
DEPUIS
(CHOISIR
Autoportant.Période AS Période,
Greffier AS Greffier,
<измерения>,
1 AS Nombre d'enregistrements
DEPUIS
Registre de la comptabilité. AS autoportant autoportant) AS sous-requête

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

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

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

2.3.6 Un cas particulier dans l'échange dans le RDB. L'erreur tombe sur les tables "auxiliaires" associées au calcul des totaux ou aux analyses. Par exemple:

Erreur lors de l'appel de la méthode contextuelle (Write) : Tentative d'insertion d'une valeur non unique dans l'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, télé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 a été interrompu car une clé en double a été trouvée pour l'ID d'index
ou
Impossible d'insérer la 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 l'index défaillant (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 tables + recalcul des totaux. 1C recrée l'index sans erreur. Nous réalisons des documents précédemment échoués.

2. 1) Avec 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) Tué manuellement l'index de la table _AccumRgTn19455
3) Lancé une requête comme
Code SQL S_elect count(*), index_fields
DE OM AccumRgTn19455
GROUP BY index_field
AYANT compte(*)>1
Une fois l'index supprimé, j'ai affiché 15 enregistrements en double, bien qu'avant l'étape 2, la requête ne renvoie rien.
4) J'ai parcouru tous les enregistrements et nettoyé manuellement les doublons. En fait, j'ai également utilisé le traitement "Report Structure" pour comprendre à quoi j'avais affaire en général. Il s'est avéré que la table _AccumRgTn19455 stocke le registre d'accumulation "Sortie de produit (comptabilité fiscale)". J'ai également fouillé avec des requêtes sql, identifié 15 documents non uniques, et après avoir terminé toutes les actions, j'ai vérifié en 1C que ces documents étaient traités normalement, sans erreur. Bien sûr, ce n'est pas la peine de nettoyer les tables au hasard comme ça : il est important de comprendre ce qui est nettoyé et ce que cela peut devenir.
5) Lancé une requête pour créer un index, qui a été enregistré dans un fichier.
6) Commutation de la base de données en mode mono-utilisateur et exécution de dbcc checkdb - cette fois, il n'y a pas eu d'erreurs.
7) Transféré la base en mode mono-utilisateur.
Ça y est ... le problème est vaincu. Bon, même en 1C j'ai lancé "Test et Correction", là aussi tout s'est bien passé, ça a 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 de 2000.

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

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

1.3. S'il n'y a pas de variante de fichier, essayez de charger de DT vers une variante client/serveur DB2 (qui est moins pointilleuse sur l'unicité), puis exécutez Test et correction et Configuration - Vérification de la configuration - Vérification de l'intégrité logique de la configuration + Recherche de mauvaise référence.

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

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

2.1. Trouvez la requête problématique 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 du registre d'accumulation "Heures de travail des employés des organisations" dans la procédure "Registre des recalculs" dans la demande, il n'y a pas de mot de service "DIFFERENT".
Code 1C v 8.x C'est-à-dire devrait être:
Demande = Nouvelle demande(
"CHOISISSEZ DIFFÉRENTS
| Basique.Individuel,
. . . . .
Dans les dernières versions publiées de ZUP et UPP, l'erreur ne se produit pas, car. il est écrit "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_elect COUNT(*) Compteur,<перечисление всех полей соответствующего индекса>depuis<имя таблицы>
PAR GROUPE<перечисление всех полей соответствующего индекса>
AYANT Compteur > 1

2.2.2 Exemple. L'index dans l'erreur s'appelle "_Document140_VT1385_IntKeyIndNG".
Liste des champs de table :
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _ Fld1393_RR Réf _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Veuillez sauvegarder votre base de données avant de suivre la procédure ci-dessous.
Exécutez dans l'Analyseur de requêtes MS SQL Server :
Code SQL S_elect count(*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
grouper par _Document140_IDRRef, _KeyField
ayant count(*) > 1
Utilisez-le pour connaître les valeurs des colonnes _Document140_IDRRef, _KeyField, enregistrements en double (id, clé).

Avec une demande :
Code SQL S_select *
de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = clé1 ou _Document140_IDRRef = id2 et _KeyField = clé2 ou ...
regardez les valeurs des autres colonnes d'entrées en double.
Si les deux entrées ont des valeurs significatives et que ces valeurs sont différentes, fixez la valeur de _KeyField pour qu'elle soit unique. Pour ce faire, définissez la valeur maximale occupée de _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 :
Mise à jour du code 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 erronée, elle doit être supprimée :
Suppression du code SQL de _Document140_VT1385
où _Document140_IDRRef = id1 et _LineNo1386 = lineno1
Si les entrées en double ont les mêmes valeurs dans toutes les colonnes, l'une d'entre elles doit être laissée :
Code SQL S_elect distinct *
dans #tmp1
de _Document140_VT1385

Supprimer de _Document140_VT1385
où _Document140_IDRRef = id1 et _KeyField = clé1

I_nsert into _Document140_VT1385
S_elect #tmp1

Tableau D_rop #tmp1

La procédure décrite doit être effectuée pour chaque paire d'entrées 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
AYANT (COMPTER(*) > 1)

2.3.4 Exemple de définition d'enregistrements non uniques à l'aide d'une requête 1C:Enterprise :
Code 1C v 8.x CHOOSE Manuel Lien
Annuaire FROM. Annuaire AS Annuaire
PAR GROUPE
AYANT QUANTITE(*) > 1

Informations tirées du site