Sie sind auf eine Nachricht gestoßen, die die folgenden Zeilen enthält:
Microsoft OLE DB-Anbieter für SQL Server: CREATE UNIQUE INDEX wurde beendet, weil ein doppelter Schlüssel für die Index-ID gefunden wurde
oder
I_nsert kann keine doppelte Schlüsselzeile im Objekt einfügen
oder
Es wurde versucht, einen nicht eindeutigen Wert in einen eindeutigen Index einzufügen.
Lösungsoptionen:
1. In SQL Server Management Studio zerstören wir den fehlerhaften Index physisch (in meinem Fall war es ein Index in der Summentabelle des Buchhaltungsregisters). Wir werden fehlerhafte Dokumente in 1C verteilen. Aktivieren Sie im Test- und Fixierungsmodus die Kontrollkästchen für die Neuindizierung von Tabellen und die Neuberechnung von Summen. 1C erstellt den Index ohne Fehler neu. Wir führen bisher fehlgeschlagene Dokumente aus.
2.
1) Mit Management Studio 2005 habe ich ein Erstellungsskript zum Erstellen eines fehlerhaften Index generiert und in einer Datei gespeichert.
2) Ich habe den Index manuell aus der Tabelle _AccumRgTn19455 gelöscht
3) Eine Abfrage wie gestartet
SQL Code S_elect count (*) index_fields
FROM AccumRgTn19455
GROUP BY index_field
HAVING count (*)\u003e 1
Nachdem der Index gelöscht wurde, erhielt ich 15 doppelte Datensätze, obwohl die Abfrage vor Schritt 2 nichts zurückgab.
4) Ich habe alle Aufzeichnungen durchgesehen und die Duplikate manuell bereinigt. Tatsächlich habe ich auch die Verarbeitung "Berichtsstruktur" verwendet, um zu verstehen, womit ich überhaupt zu tun hatte. Es stellte sich heraus, dass in der Tabelle _AccumRgTn19455 das Akkumulationsregister "Produktausgabe (Steuerbuchhaltung)" gespeichert ist. Ich habe mich immer noch mit SQL-Abfragen beschäftigt, 15 nicht eindeutige Dokumente identifiziert und nach Abschluss aller Aktionen in 1C überprüft, ob diese Dokumente ohne Fehler normal verarbeitet werden. Natürlich lohnt es sich nicht, Tische nach dem Zufallsprinzip zu reinigen: Es ist wichtig zu verstehen, was gereinigt wird und wie es ausgehen kann.
5) Eine Anforderung zum Erstellen eines Index gestartet, der in einer Datei gespeichert wurde.
6) Ich habe die Datenbank in den Einzelbenutzermodus geschaltet und dbcc checkdb ausgeführt - diesmal wurden keine Fehler ausgegeben.
7) Die Basis wurde wieder in den Einzelbenutzermodus versetzt.
Das war's ... das Problem ist besiegt. Nun, selbst in 1C habe ich "Testing and Correction" gestartet, auch dort lief alles gut und ich habe aufgehört, auf einen nicht eindeutigen Index zu schwören.
3. Wenn die Eindeutigkeit in Daten mit Nullwerten liegtDann wird das Problem gelöst, indem eine Basis mit einem Offset-Parameter von 2000 erstellt wird.
1. Wenn das Problem beim Laden der Datenbank auftritt, gehen Sie wie folgt vor:
1.1. Wenn Sie in die MS SQL Server-Datenbank hochladen (eine dt-Datei verwenden), geben Sie beim Erstellen der Datenbank vor dem Hochladen den Datumsversatz - 2000 an.
Wenn die Basis bereits mit dem Offset 0 erstellt wurde, erstellen Sie ab 2000 eine neue.
1.2. Wenn es möglich ist, mit der Datenbank in der Dateiversion zu arbeiten, führen Sie Tests und Korrekturen sowie Konfiguration - Überprüfen der Konfiguration - Überprüfen der logischen Integrität der Konfiguration + Suchen nach ungültigen Links durch.
1.3. Wenn keine Dateiversion vorhanden ist, versuchen Sie, mit DB2 (das weniger Anforderungen an die Eindeutigkeit stellt) von DT auf eine Client / Server-Version zu laden. Führen Sie dann Test and Fix und anschließend Konfiguration - Konfiguration überprüfen - Logische Konsistenz der Konfiguration prüfen + Ungültige Referenzen suchen aus.
1.4. Um das Problem einzugrenzen, können Sie die Daten des Objekts ermitteln, das nicht geladen werden konnte. Dazu müssen Sie die Ablaufverfolgung beim Booten im Profiler-Dienstprogramm aktivieren oder die Aufzeichnung im technologischen Ereignisprotokoll DBMSSQL und EXCP aktivieren.
2. Wenn sich das Problem der Nicht-Eindeutigkeit während der Benutzerarbeit manifestiert:
2.1. Suchen Sie die Problemanforderung mithilfe der Methode in Absatz 1.4.
2.1.2. Manchmal tritt während der Ausführung von Anforderungen ein Fehler auf, zum Beispiel:
Dieser Fehler tritt auf, weil im Akkumulationsregistermodul "Arbeitszeiten von Mitarbeitern von Organisationen" in der Prozedur "RegisterRecalculations" die Abfrage nicht das Servicewort "VARIOUS" enthält.
Code 1C v 8.x Dh. sollte sein:
Anfrage \u003d Neue Anfrage (
"WÄHLEN SIE VERSCHIEDENES
| Basic.PhysFace,
. . . . .
In den neuesten veröffentlichten ZUP- und UPP-Versionen tritt der Fehler nicht auf, weil es gibt "VERSCHIEDENES".
2.2. Nachdem Sie den problematischen Index vom vorherigen Punkt gefunden haben, müssen Sie einen nicht eindeutigen Eintrag finden.
2.2.1. Fischskript zum Definieren nicht eindeutiger Datensätze mit SQL:
SQL-Code S_elect COUNT (*) Counter,<перечисление всех полей соответствующего индекса> von<имя таблицы>
GRUPPIERE NACH<перечисление всех полей соответствующего индекса>
HABEN Zähler\u003e 1
2.2.2 Beispiel. Der Index im Fehler heißt "_Document140_VT1385_IntKeyIndNG".
Liste der Tabellenfelder:
_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
Führen Sie dies aus, bevor Sie das folgende Verfahren ausführen backup Datenbank.
In MS SQL Server Query Analizer ausführen:
SQL Code S_elect count (*), _Document140_IDRRef, _KeyField
von _Document140_VT1385
Gruppe nach _Document140_IDRRef, _KeyField
mit count (*)\u003e 1
Verwenden Sie diese Option, um die Werte der Spalten _Document140_IDRRef, _KeyField und doppelte Datensätze (ID, Schlüssel) zu ermitteln.
Auf Anfrage:
SQL S_elect *
von _Document140_VT1385
oder _Document140_IDRRef \u003d id2 und _KeyField \u003d key2 oder ...
Sehen Sie sich die Werte der anderen Spalten doppelter Datensätze an.
Wenn beide Einträge aussagekräftige Werte haben und die Werte unterschiedlich sind, korrigieren Sie den _KeyField-Wert so, dass er eindeutig ist. Definieren Sie dazu den maximal belegten _KeyField (Keymax) -Wert:
SQL-Code S_elect max (_KeyField)
von _Document140_VT1385
Dabei ist _Document140_IDRRef \u003d id1
Ersetzen Sie den _KeyField-Wert in einem der doppelten Einträge durch den richtigen:
SQL-Aktualisierungscode _Document140_VT1385
setze _KeyField \u003d keymax + 1
Hier _LineNo1386 \u003d - zusätzlicher ZustandHier können Sie einen von zwei doppelten Einträgen auswählen.
Wenn einer (oder beide) der doppelten Einträge einen offensichtlich falschen Wert hat, muss er entfernt werden:
SQL-Code aus _Document140_VT1385 löschen
Dabei ist _Document140_IDRRef \u003d id1 und _LineNo1386 \u003d lineno1
Wenn doppelte Datensätze in allen Spalten dieselben Werte haben, sollten Sie einen davon belassen:
SQL S_elect different *
in # tmp1
von _Document140_VT1385
Dabei ist _Document140_IDRRef \u003d id1 und _KeyField \u003d key1
Aus _Document140_VT1385 löschen
Dabei ist _Document140_IDRRef \u003d id1 und _KeyField \u003d key1
I_nsert in _Document140_VT1385
S_elect # tmp1
D_rop Tabelle # tmp1
Das beschriebene Verfahren muss für jedes Paar doppelter Datensätze durchgeführt werden.
2.2.3. Zweites Beispiel:
SQL-Code S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Reference8_
GRUPPE NACH _IDRRef, _Beschreibung
HABEN (COUNT (*)\u003e 1)
2.3.4 Ein Beispiel für die Definition nicht eindeutiger Datensätze mithilfe der Abfrage 1C: Enterprise:
Code 1C v 8.x SELECT Reference.Link
FROM Referenz. Referenz AS Referenz
LOAD BY Reference.Link
MENGE HABEN (*)\u003e 1
Ein Fehler tritt auf, wenn einige Objekte, Attribute, subconto einen NULL-Wert in der Datenbank haben, aber keinen solchen Wert haben können. Und dieser Fehler tritt nur in SQL-Datenbanken auf. Jene. Wenn eine solche Datenbank in eine Datei entladen wird, ist dieser Fehler nicht vorhanden. weil Die Dateidatenbank verfügt über eigene Tabellen (insgesamt 4), während SQL über eigene Tabellen verfügt. Und die SQL-Datenbank reagiert kritisch auf solche Werte in ihren Tabellen.
Dieses Problem wird nicht durch Tests (weder extern noch intern) in Datenbankoptionen (SQL oder Datei) und sogar durch die Prozedur _1sp_DBReindex im SQL-Manager gelöst, die anscheinend Tabellen in SQL umstrukturieren soll.
Lassen Sie uns die Lösung des Problems am Beispiel des Übergangs von Accounting 3.0 PROF zu CORP analysieren. Nach dem Übergang hat Konto 68.01 eine neue Unterkontoregistrierung bei der Steuerbehörde. In den SQL-Datenbanken werden dann alle in der PROF-Version erstellten Dokumente, die dieses Konto verwenden, nicht erneut veröffentlicht. Der obige Fehler wird ausgegeben. weil Dieses neue Subconto für alte Dokumente in Transaktionen wird mit einem NULL-Wert geschrieben (obwohl es einen leeren Wert geben sollte, na ja, oder irgendwie die Steuerbehörde).
Um diesen Fehler zu beheben, müssen Sie NULL-Werte dort entfernen, wo sie nicht sein sollten. In diesem Fall in den Dokumenten, in denen das Subconto verwendet wird Registrierung bei der Steuerbehörde. Sie können dies tun, indem Sie eine Verarbeitung schreiben, die NULL durch einen leeren Wert ersetzt (Sie können die fertige Verarbeitung aus diesem Artikel herunterladen). Tun Sie es durch Verarbeitung, weil Ein Versuch, den Wert dieses Subcontos in Dokumentbuchungen manuell zu ändern, führt zu demselben Fehler.
Die Verarbeitung zum Ersetzen von NULL-Werten in allen Unterkonten der Registrierung bei der Steuerbehörde kann in diesem Artikel unten heruntergeladen werden.
ABER es wird nicht funktionieren, NULL in der SQL-Datenbank zu ersetzen, der gleiche Fehler wird während der Verarbeitung generiert. Daher müssen Sie Folgendes tun:
1. Laden Sie die bereits funktionierende, in die CORP-Version übersetzte SQL-Datenbank in dt'shnik hoch (im Administrationskonfigurator - Datenbank entladen - wählen Sie aus, wo die Datenbank als * .dt-Datei entladen werden soll).
2. Laden Sie dt'shnik in die Dateibasis (in unnötiger oder vorbereiteter, sauberer, dateibasis, im Administrationskonfigurator - Basis laden - wählen Sie die zuvor entladene dt'shnik)
3. Führen Sie die Verarbeitung in der Dateidatenbank durch (es treten keine Fehler auf und alle NULL-Werte werden korrekt ersetzt) \u200b\u200b(wie die Verarbeitung durchgeführt wird, wird unten beschrieben).
5. Entladen Sie nun im Gegenteil die dt-Datei aus der Dateidatenbank und laden Sie sie in die SQL-Datenbank. Beim Posten verarbeiteter Dokumente werden nun keine Fehler mehr angezeigt.
Die Verarbeitung aus diesem Artikel findet alle Dokumente für den angegebenen Zeitraum, in dem der Subkontinent RegistrationIn the Tax Authority (der in der CORP-Version erscheint) in den Transaktionen erscheint, die einen NULL-Wert haben. Und ersetzt diesen Wert durch einen leeren Wert.
Bei der Verarbeitung muss der Zeitraum angegeben werden, für den Dokumente verarbeitet werden müssen (dies ist für den gesamten Zeitraum möglich, in dem die Datensätze in der Datenbank gespeichert sind), und auf "Tabellarischer Bereich ausfüllen" geklickt. Danach können Sie mit Kontrollkästchen markieren, welche Dokumente verarbeitet werden sollen (Sie können alle auswählen) und auf die Schaltfläche "Verarbeiten" klicken.
Dementsprechend, wenn jemand den gleichen Fehler hat, jedoch NICHT nach dem Wechsel zu CORP, sondern beispielsweise nach dem Austausch, dem Laden einiger Daten, dem Durchführen einer Verarbeitung usw. Dann muss herausgefunden werden, wo der NULL-Wert in einem bestimmten Dokument / Nachschlagewerk zugewiesen wurde, und auf ähnliche Weise diese NULL entfernt werden, jedoch bereits durch eigene Verarbeitung, jedoch in der oben beschriebenen Reihenfolge. Denken Sie daran, dass NULL wie bei Dokumententransaktionen inkl. nicht nur Buchhaltung, sondern irgendwo in Form eines Dokuments / Nachschlagewerks, in einigen erforderlichen Fällen, aber in diesem Fall wird es wahrscheinlich nicht einmal geöffnet.
Wenn Sie diesen Fehler beim Posten eines Dokuments erhalten haben, nachdem Sie die Bukh CORP-Dateibasis nach SQL übertragen haben (und die Basis ursprünglich PROF war), befinden sich die Dokumente, die in der PROF-Version erstellt wurden, jetzt auch im Unterkonto Registrierung im Steuerorgan Der NULL-Wert und die SQL-Datenbank akzeptieren dies nicht. Beim Laden der Datenbank in SQL wird ein solcher Fehler angezeigt. Hier in der Tat in der Dateibasis nULL-Werte Tatsächlich wird dies nicht der Fall sein, aber SQL lädt genau diese Werte in seine Tabellen. Daher müssen Sie hier die SQL-Datenbank zwingen, diese NULL-Werte zu erstellen und sie dann in der Dateidatenbank zu korrigieren. Ich werde Ihnen jedoch nicht sagen, wie dies zu tun ist.
Sie sind auf eine Nachricht gestoßen, die die folgenden Zeilen enthält:
Microsoft OLE DB-Anbieter für SQL Server: CREATE UNIQUE INDEX wurde beendet, weil ein doppelter Schlüssel für die Index-ID gefunden wurde
oder
I_nsert kann keine doppelte Schlüsselzeile im Objekt einfügen
oder
Es wurde versucht, einen nicht eindeutigen Wert in einen eindeutigen Index einzufügen.
Lösungsoptionen:
1. In SQL Server Management Studio zerstören wir den fehlerhaften Index physisch (in meinem Fall war es ein Index in der Summentabelle des Buchhaltungsregisters). Wir werden fehlerhafte Dokumente in 1C verteilen. Aktivieren Sie im Test- und Fixierungsmodus die Kontrollkästchen für die Neuindizierung von Tabellen und die Neuberechnung von Summen. 1C erstellt den Index ohne Fehler neu. Wir führen bisher fehlgeschlagene Dokumente aus.
2.
1) Mit Management Studio 2005 habe ich ein Erstellungsskript zum Erstellen eines fehlerhaften Index generiert und in einer Datei gespeichert.
2) Ich habe den Index manuell aus der Tabelle _AccumRgTn19455 gelöscht
3) Eine Abfrage wie gestartet
SQL Code S_elect count (*) index_fields
FR OM AccumRgTn19455
GROUP BY index_field
HAVING count (*)\u003e 1
Nachdem der Index gelöscht wurde, erhielt ich 15 doppelte Datensätze, obwohl die Abfrage vor Schritt 2 nichts zurückgab.
4) Ich habe alle Aufzeichnungen durchgesehen und die Duplikate manuell bereinigt. Tatsächlich habe ich auch die Verarbeitung "Berichtsstruktur" verwendet, um zu verstehen, womit ich überhaupt zu tun hatte. Es stellte sich heraus, dass in der Tabelle _AccumRgTn19455 das Akkumulationsregister "Produktausgabe (Steuerbuchhaltung)" gespeichert ist. Ich habe mich immer noch mit SQL-Abfragen beschäftigt, 15 nicht eindeutige Dokumente identifiziert und nach Abschluss aller Aktionen in 1C überprüft, ob diese Dokumente ohne Fehler normal verarbeitet werden. Natürlich lohnt es sich nicht, Tische nach dem Zufallsprinzip zu reinigen: Es ist wichtig zu verstehen, was gereinigt wird und wie es ausgehen kann.
5) Eine Anforderung zum Erstellen eines Index gestartet, der in einer Datei gespeichert wurde.
6) Ich habe die Datenbank in den Einzelbenutzermodus geschaltet und dbcc checkdb ausgeführt - diesmal wurden keine Fehler ausgegeben.
7) Die Basis wurde wieder in den Einzelbenutzermodus versetzt.
Das war's ... das Problem ist besiegt. Nun, selbst in 1C habe ich "Testing and Correction" gestartet, auch dort lief alles gut und ich habe aufgehört, auf einen nicht eindeutigen Index zu schwören.
3. Wenn die Eindeutigkeit in Daten mit Nullwerten liegtDann wird das Problem gelöst, indem eine Basis mit einem Offset-Parameter von 2000 erstellt wird.
1. Wenn das Problem beim Laden der Datenbank auftritt, gehen Sie wie folgt vor:
1.1. Wenn Sie in die MS SQL Server-Datenbank hochladen (eine dt-Datei verwenden), geben Sie beim Erstellen der Datenbank vor dem Hochladen den Datumsversatz - 2000 an.
Wenn die Basis bereits mit dem Offset 0 erstellt wurde, erstellen Sie ab 2000 eine neue.
1.2. Wenn es möglich ist, mit der Datenbank in der Dateiversion zu arbeiten, führen Sie Tests und Korrekturen sowie Konfiguration - Überprüfen der Konfiguration - Überprüfen der logischen Integrität der Konfiguration + Suchen nach ungültigen Links durch.
1.3. Wenn keine Dateiversion vorhanden ist, versuchen Sie, mit DB2 (das weniger Anforderungen an die Eindeutigkeit stellt) von DT auf eine Client / Server-Version zu laden. Führen Sie dann Test and Fix und anschließend Konfiguration - Konfiguration prüfen - Integrität der logischen Konfiguration überprüfen + Ungültige Referenzen suchen aus.
1.4. Um das Problem einzugrenzen, können Sie die Daten des Objekts ermitteln, das nicht geladen werden konnte. Dazu müssen Sie die Ablaufverfolgung beim Booten im Profiler-Dienstprogramm aktivieren oder die Aufzeichnung im technologischen Ereignisprotokoll DBMSSQL und EXCP aktivieren.
2. Wenn sich das Problem der Nicht-Eindeutigkeit während der Benutzerarbeit manifestiert:
2.1. Suchen Sie die Problemanforderung mithilfe der Methode in Absatz 1.4.
2.1.2. Manchmal tritt während der Ausführung von Anforderungen ein Fehler auf, zum Beispiel:
Dieser Fehler tritt auf, weil im Akkumulationsregister-Modul "Arbeitszeiten von Mitarbeitern von Organisationen" im Verfahren "RegisterRecalculations" die Anforderung nicht das Servicewort "VARIOUS" enthält.
Code 1C v 8.x Dh. sollte sein:
Anfrage \u003d Neue Anfrage (
"WÄHLEN SIE VERSCHIEDENES
| Basic.PhysFace,
. . . . .
In den neuesten veröffentlichten ZUP- und UPP-Versionen tritt der Fehler nicht auf, weil es gibt "VERSCHIEDENES".
2.2. Nachdem Sie den problematischen Index vom vorherigen Punkt gefunden haben, müssen Sie einen nicht eindeutigen Eintrag finden.
2.2.1. Fischskript zum Definieren nicht eindeutiger Datensätze mit SQL:
SQL-Code S_elect COUNT (*) Counter,<перечисление всех полей соответствующего индекса> von<имя таблицы>
GRUPPIERE NACH<перечисление всех полей соответствующего индекса>
HABEN Zähler\u003e 1
2.2.2 Beispiel. Der Index im Fehler heißt "_Document140_VT1385_IntKeyIndNG".
Liste der Tabellenfelder:
_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
Sichern Sie Ihre Datenbank, bevor Sie die folgenden Schritte ausführen.
In MS SQL Server Query Analizer ausführen:
SQL Code S_elect count (*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
Gruppe nach _Document140_IDRRef, _KeyField
mit count (*)\u003e 1
Verwenden Sie diese Option, um die Werte der Spalten _Document140_IDRRef, _KeyField und doppelte Datensätze (ID, Schlüssel) zu ermitteln.
Auf Anfrage:
SQL S_elect *
fr om _Document140_VT1385
Dabei ist _Document140_IDRRef \u003d id1 und _KeyField \u003d key1 oder _Document140_IDRRef \u003d id2 und _KeyField \u003d key2 oder ...
Sehen Sie sich die Werte der anderen Spalten doppelter Datensätze an.
Wenn beide Einträge aussagekräftige Werte haben und die Werte unterschiedlich sind, korrigieren Sie den _KeyField-Wert so, dass er eindeutig ist. Definieren Sie dazu den maximal belegten _KeyField (Keymax) -Wert:
SQL-Code S_elect max (_KeyField)
fr om _Document140_VT1385
wh ere _Document140_IDRRef \u003d id1
Ersetzen Sie den _KeyField-Wert in einem der doppelten Einträge durch den richtigen:
SQL-Aktualisierung aß _Document140_VT1385
setze _KeyField \u003d keymax + 1
Hier ist _LineNo1386 \u003d eine zusätzliche Bedingung, mit der Sie einen von zwei doppelten Einträgen auswählen können.
Wenn einer (oder beide) der doppelten Einträge einen offensichtlich falschen Wert hat, muss er entfernt werden:
SQL-Code aus _Document140_VT1385 löschen
wh ere _Document140_IDRRef \u003d id1 und _LineNo1386 \u003d lineno1
Wenn doppelte Datensätze in allen Spalten dieselben Werte haben, sollten Sie einen davon belassen:
SQL S_elect different *
in # tmp1
von _Document140_VT1385
Aus _Document140_VT1385 löschen
wh _e_Document140_IDRRef \u003d id1 und _KeyField \u003d key1
I_nsert in _Document140_VT1385
S_elect # tmp1
D_rop Tabelle # tmp1
Das beschriebene Verfahren muss für jedes Paar doppelter Datensätze durchgeführt werden.
2.2.3. Zweites Beispiel:
SQL-Code S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Reference8_
GRUPPE NACH _IDRRef, _Beschreibung
HABEN (COUNT (*)\u003e 1)
2.3.4 Ein Beispiel für die Definition nicht eindeutiger Datensätze mithilfe der 1C: Enterprise-Abfrage:
Code 1C v 8.x SELECT Reference.Link
FROM Referenz. Referenz AS Referenz
LOAD BY Reference.Link
MENGE HABEN (*)\u003e 1
Informationen von der Website entnommen
In diesem Artikel wird beschrieben, was zu tun ist, wenn Sie bei der Arbeit mit 1C: Enterprise 8.1 auf eine Meldung stoßen, die die folgenden Zeilen enthält:
Es kann keine doppelte Schlüsselzeile in das Objekt eingefügt werden
Es wurde versucht, einen nicht eindeutigen Wert in einen eindeutigen Index einzufügen.
Was ist ein Index?
Indizes sind eine Struktur, mit der Sie schnell auf die Zeilen einer Tabelle zugreifen können, basierend auf den Werten einer oder mehrerer ihrer Spalten.
Ein Index enthält Schlüssel, die aus einer oder mehreren Spalten einer Tabelle oder Ansicht erstellt wurden, sowie Zeiger, die dem Speicherort der Daten zugeordnet sind.
Indizes reduzieren die Datenmenge, die gelesen werden muss, um eine Ergebnismenge zurückzugeben.
Obwohl ein Index einer bestimmten Spalte (oder Spalten) in einer Tabelle zugeordnet ist, handelt es sich immer noch um ein eigenständiges Datenbankobjekt.
Tabellenindizes in der 1C: Enterprise-Datenbank werden implizit beim Erstellen von Konfigurationsobjekten sowie mit bestimmten Einstellungen von Konfigurationsobjekten erstellt.
Die physische Natur von Indizes in MS SQL Server 2005.
Physikalisch werden Daten gespeichert auf 8Kb Seiten... Unmittelbar nach der Erstellung sieht die Tabelle, obwohl sie keine Indizes enthält, wie ein Datenhaufen aus. Datensätze haben keine bestimmte Speicherreihenfolge.
Wenn Sie auf Daten zugreifen möchten, erstellt SQL Server tabellenscan (Tabellenscan). SQL Server durchsucht die gesamte Tabelle nach den gesuchten Datensätzen.
Ab hier wird es klar basisfunktionen Indizes:
- Erhöhung der Geschwindigkeit des Zugriffs auf Daten,
- Unterstützung für die Eindeutigkeit von Daten.
Indizes haben trotz ihrer Vorteile auch eine Reihe von Nachteilen. Der erste ist Indizes nehmen Sie zusätzlichen Speicherplatz in Anspruch und in arbeitsspeicher... Jedes Mal, wenn Sie einen Index erstellen, speichern Sie die Schlüssel in absteigender oder aufsteigender Reihenfolge, die mehrstufig sein kann. Und je größer / länger der Schlüssel, desto größere Größe Index. Der zweite Nachteil ist operationen verlangsamen sich Einfügen, Aktualisieren und Löschen von Datensätzen.
In MS SQL Server 2005 sind verschiedene Arten von Indizes implementiert:
- nicht gruppierte Indizes;
- gruppierte (oder gruppierte) Indizes;
- eindeutige Indizes;
- indizes mit eingeschlossenen Spalten
- indizierte Ansichten
- voller Text
Einzigartiger Index
Die Eindeutigkeit der Werte in der indizierten Spalte wird durch eindeutige Indizes garantiert. Wenn sie vorhanden sind, kann der Server keinen neuen Wert einfügen oder einen vorhandenen Wert ändern, sodass infolge dieser Operation zwei identische Werte in der Spalte angezeigt werden.
Ein eindeutiger Index ist eine Art Add-On und kann sowohl für Clustered-Indizes als auch für Nicht-Clustered-Indizes implementiert werden. Eine Tabelle kann einen eindeutigen Clustered-Index und viele eindeutige Nonclustered-Indizes enthalten.
Eindeutige Indizes sollten nur definiert werden, wenn dies unbedingt erforderlich ist. Um die Datenintegrität in einer Spalte sicherzustellen, können Sie eine Integritätsbeschränkung UNIQUE oder PRIMARY KEY definieren, anstatt auf eindeutige Indizes zurückzugreifen. Die Verwendung nur zur Gewährleistung der Datenintegrität ist eine unnötige Verschwendung von Datenbankspeicher. Darüber hinaus wird CPU-Zeit für deren Wartung aufgewendet.
1C: Enterprise 8.1 verwendet ab Version 8.1 aktiv gruppierte eindeutige Indizes. Dies bedeutet, dass beim Konvertieren von 8.0 oder Verschieben von 8.1.7 möglicherweise ein nicht eindeutiger Indexfehler auftritt.
Wenn Daten mit Nullwerten nicht eindeutig sind, wird das Problem gelöst, indem eine Basis mit einem Offset-Parameter von 2000 erstellt wird.
Was zu tun ist?
1. Wenn das Problem beim Laden der Datenbank auftritt, gehen Sie wie folgt vor:
1.1. Wenn Sie in die MS SQL Server-Datenbank hochladen (eine dt-Datei verwenden), geben Sie beim Erstellen der Datenbank vor dem Hochladen den Datumsversatz - 2000 an.
Wenn die Basis bereits mit dem Offset 0 erstellt wurde, erstellen Sie ab 2000 eine neue.
1.2. Wenn es möglich ist, mit der Datenbank in der Dateiversion zu arbeiten, führen Sie Tests und Korrekturen sowie Konfiguration - Überprüfen der Konfiguration - Überprüfen der logischen Integrität der Konfiguration + Suchen nach ungültigen Links durch.
1.3. Wenn keine Dateiversion vorhanden ist, versuchen Sie, mit DB2 (das weniger Anforderungen an die Eindeutigkeit stellt) von DT auf eine Client / Server-Version zu laden. Führen Sie dann Test und Fix aus und anschließend Konfiguration - Konfiguration überprüfen - Integrität der logischen Konfiguration überprüfen + Ungültige Referenzen suchen.
1.4. Um das Problem einzugrenzen, können Sie die Daten des Objekts ermitteln, das nicht geladen werden konnte. Dazu müssen Sie die Ablaufverfolgung beim Start im Profiler-Dienstprogramm aktivieren oder die Aufzeichnung im technologischen Ereignisprotokoll von DBMSSQL und EXCP aktivieren.
1.5. Wenn ein Knoten verfügbar ist (Austauschpläne), führen Sie einen Austausch durch. Sie können zusätzlich vor dem Austausch auch Absatz 2.3.5 ausführen
2. Wenn sich das Problem der Nicht-Eindeutigkeit während der Benutzerarbeit manifestiert:
2.1. Suchen Sie die Problemanforderung mithilfe der Methode in Absatz 1.4.
2.1.2. Manchmal tritt während der Ausführung von Anforderungen ein Fehler auf, zum Beispiel:
Dieser Fehler tritt auf, weil im Akkumulationsregistermodul "Arbeitszeiten von Mitarbeitern von Organisationen" in der Prozedur "RegisterRecalculations" die Anfrage nicht das Servicewort "VARIOUS" enthält.
Jene. sollte sein:
Anfrage \u003d Neue Anfrage (
WÄHLEN SIE VERSCHIEDENE
| Basic.PhysFace,
In den neuesten veröffentlichten ZUP- und UPP-Versionen tritt der Fehler nicht auf, weil es gibt "VERSCHIEDENES".
2.2. Nachdem Sie den problematischen Index vom vorherigen Punkt gefunden haben, müssen Sie einen nicht eindeutigen Eintrag finden.
2.2.1. Fischskript zum Definieren nicht eindeutiger Datensätze mit SQL:
COUNT AUSWÄHLEN (*) Zähler,<перечисление всех полей соответствующего индекса> von<имя таблицы>
GRUPPIERE NACH<перечисление всех полей соответствующего индекса>
HABEN Zähler\u003e 1
2.2.2 Beispiel. Der Index im Fehler heißt "_Document140_VT1385_IntKeyIndNG".
Liste der Tabellenfelder:
Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_R13R94
Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_Ref_RF22
Sichern Sie Ihre Datenbank, bevor Sie die folgenden Schritte ausführen.
In MS SQL Server Query Analizer ausführen:
wählen Sie count (*), _Document140_IDRRef, _KeyField
von _Document140_VT1385
Gruppe nach _Document140_IDRRef, _KeyField
mit count (*)\u003e 1
Verwenden Sie diese Option, um die Werte der Spalten _Document140_IDRRef, _KeyField und doppelte Datensätze (ID, Schlüssel) zu ermitteln.
Auf Anfrage:
wählen *
von _Document140_VT1385
oder _Document140_IDRRef \u003d id2 und _KeyField \u003d key2 oder ...
sehen Sie sich die Werte der anderen Spalten doppelter Datensätze an.
Wenn beide Einträge aussagekräftige Werte haben und die Werte unterschiedlich sind, korrigieren Sie den _KeyField-Wert so, dass er eindeutig ist. Definieren Sie dazu den maximal belegten _KeyField (Keymax) -Wert:
wähle max (_KeyField)
von _Document140_VT1385
Dabei ist _Document140_IDRRef \u003d id1
Ersetzen Sie den _KeyField-Wert in einem der doppelten Einträge durch den richtigen:
update _Document140_VT1385
setze _KeyField \u003d keymax + 1
Hier ist _LineNo1386 \u003d eine zusätzliche Bedingung, mit der Sie einen von zwei doppelten Einträgen auswählen können.
Wenn einer (oder beide) der doppelten Einträge einen offensichtlich falschen Wert hat, muss er entfernt werden:
Dabei ist _Document140_IDRRef \u003d id1 und _LineNo1386 \u003d lineno1
Wenn doppelte Datensätze in allen Spalten dieselben Werte haben, sollten Sie einen davon belassen:
wählen Sie verschiedene *
in # tmp1
von _Document140_VT1385
Dabei ist _Document140_IDRRef \u003d id1 und _KeyField \u003d key1
aus _Document140_VT1385 löschen
Dabei ist _Document140_IDRRef \u003d id1 und _KeyField \u003d key1
in _Document140_VT1385 einfügen
Wählen Sie # tmp1
drop table # tmp1
Das beschriebene Verfahren muss für jedes Paar doppelter Datensätze durchgeführt werden.
2.2.3. Zweites Beispiel:
SELECT COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Reference8_
GRUPPE NACH _IDRRef, _Beschreibung
HABEN (COUNT (*)\u003e 1)
2.3.4 Ein Beispiel für die Definition nicht eindeutiger Datensätze mithilfe der Abfrage 1C: Enterprise:
oder für die Buchhaltung
WÄHLEN
Subquery.Period,
Subquery.Registrator,
<измерения>,
SUM (Subquery.Number of Records) AS Anzahl der Datensätze
VON
(WÄHLEN
Selbsttragende Periode AS Periode
Selbsttragender Registrar AS Registrar,
<измерения>,
1 AS Anzahl der Datensätze
VON
Register of Accounting. Selbsttragende AS Selbsttragende) AS-Unterabfrage
LADEN DURCH
Subquery.Period,
Subquery.Registrator,
<измерения>
HABEN
SUM (Subquery.Number of Records)\u003e 1
2.3.5 Machen Sie den Subdat-Index nicht eindeutig. Skripten Sie den Index mit Management Studio.
2.3.6 Ein Sonderfall beim Austausch in der RDB. Der Fehler fällt auf die "Hilfstabellen", die mit der Berechnung von Summen oder Dimensionen verbunden sind. Zum Beispiel:
Beim Aufrufen der Kontextmethode (Write) ist ein Fehler aufgetreten: Versuch, einen nicht eindeutigen Wert in einen eindeutigen Index einzufügen:
Microsoft OLE DB-Anbieter für SQL Server: Es kann keine doppelte Schlüsselzeile in das Objekt "dbo._AccntRegED10319" mit dem eindeutigen Index "_Accnt10319_ByPeriod_TRNRN" eingefügt werden.
HRESULT \u003d 80040E2F, SQLSrvr: Fehlerstatus \u003d 1, Schweregrad \u003d E, native \u003d 2601, Zeile \u003d 1
Deaktivieren Sie in diesem Fall vor dem Laden die Verwendung von Summen, laden Sie die Nachricht, aktivieren Sie die Verwendung von Summen und berechnen Sie neu.
