Hier ist zunächst eine Liste der von mir verwendeten Abkürzungen:

• RIB – verteilte Informationsbasis
• CB – zentrale Basis, Wurzelknoten von RIB
• UB – Remote-Basis, Datenbank eines Remote-RIB-Knotens

Aus eigener Erfahrung kann ich sagen, dass ich auf zwei Gründe für den Fehler gestoßen bin:

1. Beim Empfang der Nachrichtendatei „stürzte“ die Datenbank in das Verwaltungssystem, und daher kam es offenbar zu einer Desynchronisation zwischen den conf. Zentralbank und UB;
2. Unter MSSQL hat der Client eine Kopie der Arbeitsdatenbank heruntergeladen und die Registrierung nicht deaktiviert. Bei automatischen Austauschaufgaben wurden daher einige Nachrichten an entfernte Knoten aus der Arbeitsdatenbank und einige aus einer Kopie generiert, was zu einer Desynchronisierung der Konfigurationen führte

Es gibt auch die Meinung, dass dieser Fehler durch die Verwendung eines dynamischen Datverursacht wird. Hier bestehen Zweifel, denn einerseits wirkt sich die dynamische Aktualisierung nie auf die Datenbankstruktur aus und die RIB-Mechanismen arbeiten immer noch mit der Datenbankstruktur und nicht mit ihrem Anwendungsteil; dennoch verwendet das RIB einen Mechanismus zur Generierung einer digitalen Signatur von die Konfigurationsversion (in Zukunft werde ich es kurz Hash nennen), und wenn sich der Anwendungsteil ändert, muss der Hash natürlich neu berechnet werden. Ich werde dies weder leugnen noch bestätigen, denn... Wenn ich auf diese Situation gestoßen bin, habe ich keine eindeutigen Beweise dafür gefunden.

Um es zu korrigieren, wende ich je nach Situation zwei Methoden an.

ERSTE TECHNIK

Die erste (häufigste) wird sowohl in der Partnerkonferenz als auch in anderen Internetressourcen im Zusammenhang mit 1C immer wieder erwähnt. Es wird in den meisten Fällen verwendet, wenn trotz der Meldung über Abweichungen in den Konfigurationen ein manueller Vergleich zeigt, dass sie identisch sind.

Reihenfolge:

1. Entladen Sie die CF-Datei von der Zentralbank.
2. wir trennen die UB von der RIB (die Set MainNode-Methode, vorgefertigte Verarbeitung finden Sie in der Anwendung oder in anderen Veröffentlichungen);
3. Ersetzen von conf. UB in die im ersten Schritt hochgeladene cf-Datei, dazu verwenden wir das Menü „Konfiguration aus Datei laden“ (und nicht vergleichen-zusammenführen!!!);
4. Lassen Sie uns das RIB-Zeichen für die UX wiederherstellen.

In den meisten Fällen reichen diese Maßnahmen mehr als aus, um den Austausch wiederherzustellen, aber nicht immer ...

ZWEITE METHODE

Es wird verwendet, wenn die erste Methode nicht funktioniert hat und es nicht möglich ist, den Knoten erneut zu entladen.

Hintergrund: Der Kunde richtete eine Kaskaden-RIB ein und in der ersten Ebene der Kaskade ist ein Fehler aufgetreten (die zweite Ebene funktionierte die ganze Zeit über einwandfrei). Die Konfiguration wurde gemeinsam mit dem IT-Dienst des Kunden entwickelt und seit dem Auftreten des Fehlers wurde die Konfiguration der Zentralbank mehrmals geändert. Die Möglichkeit, Änderungen rückgängig zu machen, wurde nicht einmal grundsätzlich in Betracht gezogen, weil Der Verlust einiger Daten und die Schließung mehrerer Abteilungen war völlig inakzeptabel. Die erste Möglichkeit zur Behebung des Fehlers brachte keine greifbaren Ergebnisse. Deshalb mussten wir nach anderen Lösungen suchen.

Es entstand die Idee, die Hashes von Konfigurationsdateien direkt in den XML-Austauschdateien zu ersetzen. Die Beschreibung der Struktur der Austauschdatei aus dem Buch „Berufliche Entwicklung im 1C:Enterprise 8-System“ gab eine schwache Vorstellung von der Bildung digitaler Signaturen von Konfigurationen und deren Änderungen, bestimmte jedoch die Richtung der Suche: die Werte von Digest1 und Digest2. Alles andere habe ich rein empirisch herausgefunden (also durch Versuch und Irrtum), aber es war möglich, ein Muster festzulegen.

Die Testversuche waren erfolgreich. Auch an den Arbeitsstützpunkten lief alles gut.

Also die Abfolge der Aktionen:

1. Führen Sie die Schritte 1 bis 4 der ersten Methode aus.
2. Wir entladen die Umtauschdatei von der UB, laden sie aber nicht in die Zentralbank;
3. Wir entladen die Umtauschdatei von der Zentralbank, laden sie aber nicht in die UB;
4. In der Austauschdatei der Zentralbank ersetzen wir den Block mit Informationen zu Konfigurationsänderungen und Hashes (Digest1 und Digest2) durch einen Block mit Hashes aus der UB-Datei (siehe Beispiel unten).
5. Wir laden die Datei ab dem 4. Punkt in die UB hoch;
6. Unbedingt die Austauschdatei von UB (2. Punkt) überschreiben! Diese Datei sollte beim Austausch mit der Zentralbank nicht heruntergeladen werden!
7. Um dies zu überprüfen, führen wir mehrere aufeinanderfolgende Austausche durch.

Wenn beim Austausch eine Datenkomprimierung verwendet wird, deaktivieren wir entweder die Komprimierung oder entpacken die Datei zunächst, ändern sie, packen sie dann zurück und senden sie.

Austauschdateisperre von der Zentralbank

106.0...hier sind Blöcke, die Konfigurationsänderungen beschreiben... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

muss durch einen Block der Austauschdatei von UB ersetzt werden (beachten Sie, dass Digest1 für eine Datei von UB immer gleich „000000000000000000000000000000000“ ist!!!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

Die aufgeführten Maßnahmen müssen mit äußerster Vorsicht durchgeführt werden; eine falsche Reihenfolge kann zur vollständigen Funktionsunfähigkeit des RIB führen. Daher ist vor diesen Aktionen die Erstellung von Sicherungskopien ZWINGEND!

Ansonsten kann ich Dir nur viel Glück wünschen!

Hier ist zunächst eine Liste der von mir verwendeten Abkürzungen:

• RIB – verteilte Informationsbasis
• CB – zentrale Basis, Wurzelknoten von RIB
• UB – Remote-Basis, Datenbank eines Remote-RIB-Knotens

Aus eigener Erfahrung kann ich sagen, dass ich auf zwei Gründe für den Fehler gestoßen bin:

1. Beim Empfang der Nachrichtendatei „stürzte“ die Datenbank in das Verwaltungssystem, und daher kam es offenbar zu einer Desynchronisation zwischen den conf. Zentralbank und UB;
2. Unter MSSQL hat der Client eine Kopie der Arbeitsdatenbank heruntergeladen und die Registrierung nicht deaktiviert. Bei automatischen Austauschaufgaben wurden daher einige Nachrichten an entfernte Knoten aus der Arbeitsdatenbank und einige aus einer Kopie generiert, was zu einer Desynchronisierung der Konfigurationen führte

Es gibt auch die Meinung, dass dieser Fehler durch die Verwendung eines dynamischen Datverursacht wird. Hier bestehen Zweifel, denn einerseits wirkt sich die dynamische Aktualisierung nie auf die Datenbankstruktur aus und die RIB-Mechanismen arbeiten immer noch mit der Datenbankstruktur und nicht mit ihrem Anwendungsteil; dennoch verwendet das RIB einen Mechanismus zur Generierung einer digitalen Signatur von die Konfigurationsversion (in Zukunft werde ich es kurz Hash nennen), und wenn sich der Anwendungsteil ändert, muss der Hash natürlich neu berechnet werden. Ich werde dies weder leugnen noch bestätigen, denn... Wenn ich auf diese Situation gestoßen bin, habe ich keine eindeutigen Beweise dafür gefunden.

Um es zu korrigieren, wende ich je nach Situation zwei Methoden an.

ERSTE TECHNIK

Die erste (häufigste) wird sowohl in der Partnerkonferenz als auch in anderen Internetressourcen im Zusammenhang mit 1C immer wieder erwähnt. Es wird in den meisten Fällen verwendet, wenn trotz der Meldung über Abweichungen in den Konfigurationen ein manueller Vergleich zeigt, dass sie identisch sind.

Reihenfolge:

1. Entladen Sie die CF-Datei von der Zentralbank.
2. wir trennen die UB von der RIB (die Set MainNode-Methode, vorgefertigte Verarbeitung finden Sie in der Anwendung oder in anderen Veröffentlichungen);
3. Ersetzen von conf. UB in die im ersten Schritt hochgeladene cf-Datei, dazu verwenden wir das Menü „Konfiguration aus Datei laden“ (und nicht vergleichen-zusammenführen!!!);
4. Lassen Sie uns das RIB-Zeichen für die UX wiederherstellen.

In den meisten Fällen reichen diese Maßnahmen mehr als aus, um den Austausch wiederherzustellen, aber nicht immer ...

ZWEITE METHODE

Es wird verwendet, wenn die erste Methode nicht funktioniert hat und es nicht möglich ist, den Knoten erneut zu entladen.

Hintergrund: Der Kunde richtete eine Kaskaden-RIB ein und in der ersten Ebene der Kaskade ist ein Fehler aufgetreten (die zweite Ebene funktionierte die ganze Zeit über einwandfrei). Die Konfiguration wurde gemeinsam mit dem IT-Dienst des Kunden entwickelt und seit dem Auftreten des Fehlers wurde die Konfiguration der Zentralbank mehrmals geändert. Die Möglichkeit, Änderungen rückgängig zu machen, wurde nicht einmal grundsätzlich in Betracht gezogen, weil Der Verlust einiger Daten und die Schließung mehrerer Abteilungen war völlig inakzeptabel. Die erste Möglichkeit zur Behebung des Fehlers brachte keine greifbaren Ergebnisse. Deshalb mussten wir nach anderen Lösungen suchen.

Es entstand die Idee, die Hashes von Konfigurationsdateien direkt in den XML-Austauschdateien zu ersetzen. Die Beschreibung der Struktur der Austauschdatei aus dem Buch „Berufliche Entwicklung im 1C:Enterprise 8-System“ gab eine schwache Vorstellung von der Bildung digitaler Signaturen von Konfigurationen und deren Änderungen, bestimmte jedoch die Richtung der Suche: die Werte von Digest1 und Digest2. Alles andere habe ich rein empirisch herausgefunden (also durch Versuch und Irrtum), aber es war möglich, ein Muster festzulegen.

Die Testversuche waren erfolgreich. Auch an den Arbeitsstützpunkten lief alles gut.

Also die Abfolge der Aktionen:

1. Führen Sie die Schritte 1 bis 4 der ersten Methode aus.
2. Wir entladen die Umtauschdatei von der UB, laden sie aber nicht in die Zentralbank;
3. Wir entladen die Umtauschdatei von der Zentralbank, laden sie aber nicht in die UB;
4. In der Austauschdatei der Zentralbank ersetzen wir den Block mit Informationen zu Konfigurationsänderungen und Hashes (Digest1 und Digest2) durch einen Block mit Hashes aus der UB-Datei (siehe Beispiel unten).
5. Wir laden die Datei ab dem 4. Punkt in die UB hoch;
6. Unbedingt die Austauschdatei von UB (2. Punkt) überschreiben! Diese Datei sollte beim Austausch mit der Zentralbank nicht heruntergeladen werden!
7. Um dies zu überprüfen, führen wir mehrere aufeinanderfolgende Austausche durch.

Wenn beim Austausch eine Datenkomprimierung verwendet wird, deaktivieren wir entweder die Komprimierung oder entpacken die Datei zunächst, ändern sie, packen sie dann zurück und senden sie.

Austauschdateisperre von der Zentralbank

106.0
...hier sind Blöcke, die Konfigurationsänderungen beschreiben...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

muss durch einen Block der Austauschdatei von UB ersetzt werden (beachten Sie, dass Digest1 für eine Datei von UB immer gleich „000000000000000000000000000000000“ ist!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Die aufgeführten Maßnahmen müssen mit äußerster Vorsicht durchgeführt werden; eine falsche Reihenfolge kann zur vollständigen Funktionsunfähigkeit des RIB führen. Daher ist vor diesen Aktionen die Erstellung von Sicherungskopien ZWINGEND!

Ansonsten kann ich Dir nur viel Glück wünschen!

Dynamische Aktualisierungsfehler (oder andere Plattformstörungen) können die Ursache für Fehler beim Austausch verteilter Infobases sein:

• „Es werden Daten von dem Knoten empfangen, für den Konfigurationsänderungen registriert wurden“
  

• „Die Konfiguration des verteilten Informationssicherheitsknotens entspricht nicht den Erwartungen“
  

Wie kann der Austausch wiederhergestellt werden?

Aber beginnen wir nicht mit der Restaurierung, sondern mit der Möglichkeit zur UmsetzungAustausch „manuell“, was tagsüber wichtig ist, denn wie immer sollte „gestern“ alles funktionieren :) Dies geht mit Hilfe wunderbarer Behandlungen, an die ich mich nicht erinnern konntenackt, wo ich es heruntergeladen habe (Autoren, bitte antworten Sie – ich hinterlasse Links zu Ihrer Ressource und lösche sie bei Bedarf aus meiner). Die Verarbeitung ermöglicht es, nur registrierte Datenänderungen in der Datenbank (gemäß dem angegebenen Austauschplan für einen bestimmten Knoten!) in XML herunterzuladen, ohne Konfigurationsänderungen herunterzuladen, und wenn sich die Konfigurationsobjekte nicht wesentlich geändert haben, besteht eine sehr hohe Wahrscheinlichkeit diese Daten zu laden. Diese können über den Link am Ende des Artikels heruntergeladen werden.

Was die Genesung angeht. Es gibt einfachere Methoden, die nicht alle Punkte in der folgenden Liste umfassen, aber sie helfen nicht immer, wie es in einem meiner Fälle der Fall war. Deshalb stelle ich die Methode vor, die mir geholfen hat; sie umgeht mögliche Probleme umfassender. Weiter Schritt für Schritt.

Es empfiehlt sich, diese Schritte durchzuführen, wenn in der Datenbank keine aktiven Benutzer vorhanden sind. Wenn dies nicht möglich ist, müssen Sie die Methode selbst „fertigstellen“ und müssen daher zunächst ihre Logik verstehen.

1. Erstellen Sie überall Backups.

2. Für Client-Server: Deaktivieren Sie die Datenbanken über „Serververwaltung“ und verbinden Sie sie sofort mit der Blockierung geplanter Aufgaben (dadurch wird der Server-Cache zurückgesetzt). Vergessen Sie danach nicht, das Registrierungsprotokoll in das neue Verzeichnis zu übertragen.

3. Löschen Sie auf allen für die Wiederherstellung verwendeten Computern die Datenbank in der Liste der 1C-Starterdatenbanken und erstellen Sie eine neue (der Benutzercache wird geleert).

4. Fügen Sie im Konfigurator (in der zentralen Datenbank) eine neue Konstante hinzu und speichern Sie die Konfigurationsänderungen.

5. Löschen Sie alle Exchange-Verzeichnisse.

6. Führen Sie Entladungen für alle Zweige durch (vorerst nur Entladungen).

7. Versuchen Sie, die empfangenen Daten in alle Filialen herunterzuladen (nur herunterzuladen). Es ist selbstverständlich, die Konfigurationsänderungen zu akzeptieren.

Wenn überall alles gut ist, machen wir weiter; wenn alles schlecht ist, denken wir, dass das Entladen von .cf aus der zentralen Datenbank und das LADEN in den Zweig (nicht das Vergleichen und Zusammenführen) hilfreich sein könnte. Im Slave-Knoten sollten Sie die Verknüpfung der Datenbank mit der RIB aufheben (die Verarbeitung hilft dabei – Download über den untenstehenden Link). Zu diesem Thema gibt es einen Artikel auf infostart.ru.

8. Wir stornieren die Registrierung von Änderungen für Filialen bei der Zentralbank (schließlich haben wir bereits überall alle Änderungen erhalten). In dieser Phase ist es wichtig, dass die gesammelten Änderungen aus verschiedenen Zweigen auch in andere Zweige gelangen. (Laden Sie die Bearbeitung zum Entbinden-Binden über den untenstehenden Link herunter).

9. Wir laden in die Zentralbank und wenn alles in Ordnung ist, laden und entladen wir jede Filiale mehrmals, um das Ergebnis zu konsolidieren.

10. Das ist es.

Sie können die Ausführung von Routineaufgaben für Client-Server-Datenbanken aktivieren.

Um Probleme zu vermeiden, die diesen Fehler verursachen, wird empfohlen, keine dynamischen Aktualisierungen durchzuführen (zumindest mehrmals hintereinander – bis die Änderungen in die Filialen hochgeladen werden). Außerdem ist es ratsam, das Kontrollkästchen „Daten nur nach erfolgreichem Upload hochladen“ zu aktivieren. in den Exchange-Einstellungen.

Hallo, liebe Leser unserer Blogseite! Heute werden wir darüber reden
zwei Fehler beheben die beim Austausch in einer verteilten Informationsbasis (RIB) entstehen können. Solche Fehler können auftreten, wenn Sie die Konfiguration Ihrer Datenbank geändert haben und versuchen, diese Änderungen von der zentralen Datenbank auf die periphere Datenbank zu übertragen. Zum Beispiel so, wie es beschrieben wurde. Lass uns anfangen!

Dies sind die Meldungen, die möglicherweise angezeigt werden, wenn Sie versuchen, einen Austausch über RIB durchzuführen:

„Daten werden von dem Knoten empfangen, für den
Konfigurationsänderungen wurden protokolliert.
Änderungen müssen übertragen werden
Konfigurationen auf den Knoten übertragen.


„Konfiguration verteilter Informationssicherheitsknoten
nicht wie erwartet!"

Schauen wir uns die Schritte an, die zur Behebung der Situation beitragen. Bevor wir beginnen, erstellen wir unsere Informationsdatenbank!!!

1. Nehmen wir die Konfigurationsdatei mit dem Update, öffnen die zentrale Datenbank im Konfigurator und laden sie (Konfiguration-Konfiguration aus Datei laden...). Speichern wir die Informationssicherheit (F7).
2. Gehen wir zu und laden eine Datei für die Peripheriedatenbank hoch:
   
   
   • Wählen Sie den Austauschplan in der Liste aus, öffnen Sie dann per Rechtsklick das Kontextmenü und wählen Sie „Änderungen speichern ...“.
3. Kommen wir nun zur peripheren Informationssicherheit. Öffnen wir es im exklusiven Modus, sodass keine Benutzer vorhanden sind, und schließen wir auch den Konfigurator. Jetzt müssen Sie sich den Knoten merken, der der Hauptknoten für die aktuelle Datenbank ist. Offene Operationen – Austauschpläne – Wählen Sie Ihren Austauschplan aus (z. B. „Nach Lager“). In der Liste der Austauschpläne ist der Hauptknoten der Eintrag mit dem gelben Symbol. Diese Informationen werden uns im siebten Punkt nützlich sein. Öffnen wir die Verarbeitung und klicken auf die Schaltfläche „Zuweisung des Masterknotens aufheben“.
4. Öffnen wir nun die periphere Informationssicherheit im Konfigurator und laden die gleiche Konfigurationsdatei, die wir im ersten Schritt in die zentrale Datenbank geladen haben (Konfiguration – Konfiguration aus Datei laden...). Speichern wir die Informationssicherheit (F7).
5. Lassen Sie uns die Support-Einstellungen ändern (Konfiguration-Support-Support-Einstellungen...). Wählen Sie im Dialogfeld die Zelle in der Tabelle am Schnittpunkt der ersten Zeile und der zweiten Spalte aus. Doppelklicken Sie dann, um das Dialogfeld „Support-Regeleinstellungen“ zu öffnen. Aktivieren Sie darin das Flag „Für untergeordnete Objekte installieren“ und klicken Sie auf die Schaltfläche „OK“. Schließen Sie den Support-Einstellungsdialog, indem Sie auf die Schaltfläche „Schließen“ klicken. IB speichern (F7). Schließen wir den Konfigurator.
6. Öffnen wir nun die periphere Informationssicherheit erneut im exklusiven 1C:Enterprise-Modus, sodass keine Benutzer vorhanden sind, und schließen wir auch den Konfigurator. Öffnen wir die Verarbeitungsinstallation der MainNodeDB.epf und wählen Sie den Exchange-Plan aus, den wir als Hauptknoten installieren möchten (im vierten Punkt haben wir uns an diesen Knoten erinnert). Klicken Sie dann auf die Schaltfläche „Masterknoten installieren“. Danach wird die aktuelle Informationssicherheit wieder peripher werden.
7. Jetzt öffnen wir in der aktuellen Informationssicherheit (Peripherie) die Austauschpläne und laden die Datei mit dem Austausch aus der zentralen Datenbank herunter, die wir im dritten Schritt erhalten haben:
   
   
   • Betriebsabläufe – Austauschpläne – Wählen Sie unseren Austauschplan aus (z. B. „Nach Lager“).
8. Wenn alles gut gelaufen ist, werden wir den Austausch für die zentrale Datenbank in die aktuelle Informationssicherheit (Peripherie) hochladen:
   
   
   • Betriebsabläufe – Austauschpläne – Wählen Sie unseren Austauschplan aus (z. B. „Nach Lager“).
   • Wählen Sie den Austauschplan in der Liste aus, öffnen Sie dann per Rechtsklick das Kontextmenü und wählen Sie „Änderungen speichern ...“.
   • Geben Sie im Dialog den Pfad und Namen der Austauschdatei an. Klicken Sie auf die Schaltfläche „OK“.
9. Versuchen wir nun, diese Datei in die zentrale Datenbank zu laden und im 1C:Enterprise-Modus zu öffnen:
   
   
   • Betriebsabläufe – Austauschpläne – Wählen Sie unseren Austauschplan aus (z. B. „Nach Lager“).
   • Wählen Sie den Austauschplan in der Liste aus - Rufen Sie per Rechtsklick das Kontextmenü auf und wählen Sie „Änderungen lesen...“
   • Wählen Sie im Dialog die Austauschdatei aus. Klicken Sie auf die Schaltfläche „OK“.

Um Probleme mit Arbeitskopien zu vermeiden, tun Sie dies zuerst

Eine verteilte Informationsbasis (DIB) wird häufig verwendet, um die Arbeit von Niederlassungen und Abteilungen zu organisieren und einen schnellen Informationsaustausch bei gleichzeitiger Wahrung des erforderlichen Maßes an Autonomie zu ermöglichen. Obwohl diese Technologie recht zuverlässig ist, kommt es von Zeit zu Zeit zu Ausfällen. Heute schauen wir uns einen der recht häufigen Fehler an: Wir erzählen Ihnen von den Gründen für sein Auftreten und den Methoden, wie man damit umgeht.

Fangen wir wie immer von vorne an. Nachdem Sie die RIB erstellt haben, können alle Änderungen an der Infobase-Konfiguration nur im Hauptknoten vorgenommen werden. Anschließend werden beim nächsten Austausch alle Änderungen an die Slave-Knoten übertragen und dort automatisch angewendet. Aber auf dem Papier war es glatt...

In der Praxis kommt es manchmal vor, dass sich die Konfiguration des Hauptknotens zwischen Austauschsitzungen zweimal ändert, insbesondere wenn der Kanal an der Peripherie schlecht ist. Sie haben beispielsweise Änderungen vorgenommen, diese hochgeladen, die periphere Datenbank hat die Änderungen erhalten, sie jedoch noch nicht angewendet, was einige Zeit dauern kann, und es wurde noch keine Bestätigung gesendet. Wenn Sie in diesem Zeitraum erneut Änderungen vornehmen und den Austausch erneut hochladen, stellt sich heraus, dass das Zentrum erwartet, Konfiguration Nr. 1 im Peripherieknoten zu sehen, und versucht, diese auf Konfiguration Nr. 3 zu aktualisieren, tatsächlich jedoch auf Konfiguration Nr. stößt . 2 da. Manchmal tritt eine ähnliche Situation bei der dynamischen Aktualisierung der zentralen Datenbank auf. Dadurch wird der Austausch unmöglich und Sie erhalten eine entsprechende Nachricht Die Konfiguration des verteilten Informationssicherheitsknotens entspricht nicht der erwarteten!

Im Allgemeinen ist die Moral dieser Geschichte einfach: Verfeinern Sie die Arbeitsdatenbank nicht aktiv. Wenn Sie dies tun, schließen Sie alle Austauschsitzungen ab, bevor Sie die nächsten Änderungen vornehmen. Was aber, wenn solch ein Ärgernis doch passiert?

Die einfachste Lösung besteht darin, ein neues Image des Slave-Knotens zu erstellen, in der Praxis ist dies jedoch normalerweise nicht anwendbar. Das Auftreten eines schwerwiegenden Fehlers beim Austausch wird in der Regel nicht sofort erkannt, sondern erst einige Zeit, nachdem Betriebsdaten aus umliegenden Datenbanken nicht mehr eintreffen. Abhängig vom Kommunikationsplan kann zwischen dem Auftreten des Problems und seiner Entdeckung ein ganzer Arbeitstag oder mehr vergehen.

Hier lohnt es sich, einen Stein auf die Entwickler zu werfen, die es als Fehler melden und den Sachverhalt ebenso rot markieren Die Nachrichtennummer ist kleiner oder gleich der Nummer einer zuvor empfangenen Nachricht, was im Allgemeinen ganz normal ist. Dadurch wird die Fehlerwahrnehmung der Benutzer abgeschwächt und sie hören einfach auf, die angezeigten Nachrichten zu lesen, weil sie glauben, dass alles in Ordnung ist und die andere Partei den Austausch noch nicht durchgeführt hat.

Aber kehren wir zu unserem Fehler zurück. Die Lösung ist recht einfach und liegt auf der Hand: Bringen Sie die Konfiguration der peripheren Basis auf die erwartete, d. h. Bringen Sie es in Einklang mit der Konfiguration des zentralen Knotens. Doch in der Praxis ist das nicht so einfach. Wenn wir die Peripheriedatenbank im Konfigurator öffnen, sehen wir, dass Änderungen durch die RIB-Verwaltungstools blockiert werden.

Um die Konfiguration eines Slave-Knotens zu ändern, müssen Sie ihn vorübergehend von der zentralen Datenbank trennen. Für diese Zwecke können Sie eine der im Netzwerk reichlich verfügbaren Verarbeitungsmöglichkeiten nutzen oder die Informationssicherheit vom zentralen Knoten trennen mit dem Startparameter des Konfigurators/ResetMasterNode.

Öffnen Sie eine Eingabeaufforderung und geben Sie ein (unter Berücksichtigung der Plattformversion und des tatsächlichen Installationspfads):

„C:\Programme (x86)\1cv8\8.3.6.2100\bin\1cv8.exe“ config /ResetMasterNode

Nach Ausführung dieses Befehls erscheint das übliche Startfenster, wählen Sie dort die gewünschte Basis aus und klicken Sie auf die Schaltfläche Konfigurator.

Gleichzeitig Informationssicherheit starten wird nicht passieren, d.h. Es mag den Anschein haben, dass nichts passiert ist, aber durch erneutes Öffnen der Datenbank im Konfigurator können Sie sicherstellen, dass sie vom Hauptknoten getrennt ist und für Änderungen verfügbar ist.

Aufmerksamkeit! Auf den Plattformen 8.3.7 bis 8.3.9 führt die Ausführung dieses Befehls zu einem Absturz. Der Fehler wurde in Plattform 8.3.10 behoben.

Wenn Sie nicht mit der Befehlszeile herumspielen möchten, können Sie eine der folgenden Behandlungen verwenden. Nachfolgend finden Sie die von uns verwendete. Sie wurde im Internet gefunden und wir haben nur kosmetische Änderungen daran vorgenommen. Bitte beachten Sie, dass die Verarbeitung nur für eine reguläre Anwendung geeignet ist; für Konfigurationen in einer verwalteten Anwendung verwenden Sie den Startschlüssel des Konfigurators.

Die Arbeit damit ist äußerst einfach, wir starten es im 1C:Enterprise-Modus über Datei öffnen, dann drücken Sie einfach die gewünschte Taste, in unserem Fall Masterknoten deaktivieren.

Jetzt benötigen wir die neueste Konfiguration vom zentralen Knoten. Dafür werden wir öffnen zentrale Informationssicherheit im Konfigurator eingeben und ausführen Konfiguration – Konfiguration in Datei speichern. Die resultierende Datei mit der Erweiterung vgl muss an einen peripheren Knoten gesendet werden.

Dann starten wir im Peripherieknoten die Informationssicherheit (nachdem wir sie zuvor vom Hauptknoten getrennt haben) im Konfigurator und entfernen sie aus dem Support. Wählen Sie dazu: Konfiguration – Support – Support-Setup.

Aktivieren Sie im sich öffnenden Fenster zunächst die Bearbeitungsoptionen.

Und dann entfernen wir die Konfiguration aus dem Support.

Nun können Sie die Konfiguration aus einer Datei laden, hierzu auswählen Konfiguration – Konfiguration aus Datei laden und zeigen an, dass sie nicht vom zentralen Knoten übertragen wurden vgl-Datei. Anschließend erhalten Sie eine Warnung, dass die aktuelle Konfiguration nicht leer ist. Bitte beachten Sie, dass die von uns durchgeführten Manipulationen potenziell gefährlich sind und zu irreversiblen Schäden an der Informationssicherheit führen können. Bevor Sie fortfahren, stellen Sie daher sicher, dass Sie über eine aktuelle Sicherungskopie verfügen.