1s 8 Rippen und hinzugefügte Objekte. Alexey Alekseev, willkommen auf meinem gemütlichen Blog

Dies ist mein erster Artikel, konstruktive Kritik ist willkommen.

Die Zielgruppe sind diejenigen, die zum ersten Mal mit RBD in Berührung kommen.

RDB-Aufgaben

Als Erstes müssen Sie die Frage beantworten: „Warum brauchen wir eine RDB?“ Es gibt viele mögliche Antworten, insbesondere:

Wir haben Zweige, die in getrennten Datenbanken ausgeführt werden. Jetzt möchten wir, dass die Informationen zwischen ihnen synchronisiert werden.
Wir haben Filialen, aber die Belastung der Datenbank ist zu hoch (das bedeutet Transaktionsblockierung, nicht das Volumen der Datenbank) und die Online-Relevanz (nicht zu verwechseln mit Relevanz in wenigen Minuten, online ist, wenn nach jeder Transaktion die Daten verfügbar sind). an den zweiten Knoten übertragen) werden keine Daten für Zweige benötigt;
Wir haben Filialen, in denen nur die Dateneingabe erfolgt (z. B. Einzelhandelsgeschäfte), sodass wir die Belastung der zentralen Datenbank erheblich reduzieren können;
Aus Sicherheitsgründen möchten wir, dass die Filialen auch theoretisch (mit Admin-Passwort) keinen Zugriff auf wichtige Daten, wie beispielsweise die Bilanz des Unternehmens, haben.

In einem Fall waren für mich die Fragen 2 und 4 relevant, in einem anderen Fall die Fragen 2 und 3. Der erste Punkt ist zu umfangreich und wird im Rahmen dieses Artikels nicht berücksichtigt.

Es ist auch besser, sich sofort mit dem Problem des Transports von Austauschdateien zu befassen, da dies in einigen Fällen zu erheblichen Einschränkungen bei der Durchführung des Datenaustauschs führen kann. Zunächst müssen Sie bestimmen, in welchen Zweigen genau die RDB-Knoten angezeigt werden (normalerweise handelt es sich dabei um regionale Zweige). Als nächstes überlegen wir, wo wir sonst noch RDB-Knoten installieren möchten und ob sie Online-Relevanz benötigen. Beispielsweise ist es in Einzelhandelsgeschäften nicht immer möglich, auch nur ein Modem zu installieren, und die Installation einer drahtlosen Verbindung wäre zu teuer. Hier müssen Sie eine Entscheidung treffen – vielleicht kann dieser Laden offline betrieben werden und über ein physisches Medium, beispielsweise ein Flash-Laufwerk, regelmäßig (einmal am Tag/einmal in der Woche) mit dem Zentrum austauschen.

In einigen Fällen ist der Austausch über physische Medien nicht möglich, beispielsweise handelt es sich um eine sehr abgelegene Zweigstelle, in der es erhebliche Probleme beim Aufbau einer Hgibt. Hier lohnt es sich, die Menge der ausgetauschten Informationen grob zu berechnen. Wenn es einmal pro Stunde oder mehrmals am Tag relevant ist, reicht oft ein 32k-Modem aus. Beachten Sie jedoch, dass Sie neben Datenaktualisierungen manchmal auch Aktualisierungen an die Konfiguration selbst oder an externe Dateien (gedruckte Formulare, Warenfotos) senden müssen, sodass es von Zeit zu Zeit zu einer Situation kommen kann, in der die Austauschdatei erheblich zunimmt zu solchen Updates.

Topologie

Insgesamt erreichten uns folgende Fragen, die es zu beantworten gilt:

In welchen Abteilungen installieren wir garantiert RDB-Knoten und ist es möglich, dort einen Hochgeschwindigkeitskanal zu installieren?
In welchen Abteilungen ist die Installation einer RBD-Einheit nicht erforderlich?
Welche Abteilungen können in mehreren Stunden relevant arbeiten?
Welche Abteilungen können offline arbeiten (Datenaustausch weniger als 3-4 Mal am Tag).

Nachdem wir diese Fragen beantwortet haben, erhalten wir ein ungefähres Diagramm unserer RDB. Bei großen Unternehmen sieht es in der Regel so aus:

Abb. 1. Typisches Diagramm der RDB eines großen Unternehmens

Wenn bei den „Branch“-Knoten alles relativ klar ist – das sind große Zentren, die Automatisierung erfordern, dann bedeuten die „Store“-Knoten einen Knoten mit einer starken Belastung der Datenbank bei der Dateneingabe, der zur Reduzierung der Belastung getrennt werden sollte. Zum Beispiel ein Markt mit 50 Kassen und einem Tagesumsatz von mehr als 10.000 Einheiten.

Filialen – Geben Sie Daten zu Ihrem eigenen Umsatz und Cashflow ein. Die Analysen sind oberflächlich, nur für Ihren eigenen Shop.
Branchen – Dateneingabe von nicht automatisierten Punkten, Buchhaltung, Gehälter und Personal, Produktion usw. Analytics innerhalb Ihrer eigenen Branche.
Zentrum - Dateneingabe nicht automatisierter Filialen. Analyse des gesamten Unternehmens.

Es ist wichtig zu verstehen, für welche Zwecke die Datenbank in jedem Knoten verwendet wird. Aus den Zielen werden die zur Umsetzung notwendigen Aufgaben aufgebaut, zum Beispiel:

Zweigstellen sehen die Geschichte der gegenseitigen Abrechnungen mit den Gegenparteien des jeweils anderen;
Geschäfte sehen übrig gebliebene Waren im gesamten Unternehmen (oder in Teilen davon);
Analysen zu Einnahmen/Ausgaben, Budgetausführung usw. sind nur innerhalb der Hierarchie Ihrer eigenen Abteilung sichtbar;
Buchhaltung, Lohn- und Gehaltsabrechnung und Personal sind nur innerhalb der Hierarchie Ihrer eigenen Abteilung sichtbar;
Die Nomenklatur, alle ihre Eigenschaften und Merkmale sind in allen Knoten der RDB sichtbar;
Bezogen auf die Abteilungshierarchie fließen alle Daten nach oben, werden aber nach unten gefiltert;
Das Zentrum enthält absolut alle Informationen über das Unternehmen.

Indem Sie sich solche Fragen stellen, können Sie die schwierigste Frage beantworten: Welche Informationen sollen wo und wie zwischen RDB-Knoten fließen? Warum das Schwierigste? Wenn Sie wissen, welche Datensätze zwischen Knoten zirkulieren, können Sie klar verstehen, wie Sie die aktuelle Datenbank „ausschneiden“, damit die Daten logisch konsistent bleiben. Beispielsweise können Daten zu Warenbilanzen nicht von Daten zu aktuellen Reserven getrennt werden.

Lassen Sie uns nun abhängig von den Informationsflüssen das RDB-Diagramm neu zeichnen:

Was sehen wir in Abbildung 2? Entsprechend der Hierarchie der Unternehmensbereiche wurde eine Topologie des Informationsflusses zwischen den Datenbankknoten aufgebaut. Der Knoten „Center 2“ wurde ebenfalls hinzugefügt, warum? Bei der Implementierung der Sterntopologie ist die Belastung des Zentrums immer höher als die Belastung der peripheren Knoten, und oft ist die vom Knoten selbst erzeugte Belastung bereits hoch. Beispiele für die Verwendung der Knoten „Center 1“ und „Center 2“:

„Center 1“ dient lediglich der Konsolidierung von Daten anderer RDB-Knoten. Nur der Administrator hat Zugriff darauf. „Center 2“ dient der Arbeit der Zentrale;
„Center 1“ dient der Arbeit der Zentrale. Im Knoten „Center 2“ werden jedoch umfangreiche Analyse- und Testvorgänge durchgeführt, die eine enorme Belastung für die Datenbank darstellen. zum Beispiel die Reihenfolge wiederherstellen, geschlossene Zeiträume neu planen, zusammenfassende Berichte für das gesamte Unternehmen über einen langen Zeitraum erstellen, Analysen erstellen, die zu Datenänderungen führen;
„Center 1“ dient der Arbeit der Zentrale. „Center 2“ ist ein Backup für unvorhergesehene Situationen zur schnellen Wiederherstellung der gesamten RDB.

Umsetzung des Austauschs

Für den RDB-Betrieb gibt es zwei Möglichkeiten:

Automatisch – erfolgt ohne Benutzereingriff. Die Kontrolle über Notfallsituationen wird entweder dem Datenbankadministrator oder einem fortgeschrittenen Benutzer zugewiesen;
Manuell – der Austausch erfolgt nur auf Wunsch des Benutzers.

Meiner Erfahrung nach habe ich alle Implementierungen immer auf die automatische Version umgestellt. Wenn es Probleme mit dem Transport von Austauschdateien gab (das Vorhandensein eines Netzwerks im Knoten ist nicht konstant), konnte der Benutzer höchstens auf die Schaltfläche „Jetzt austauschen“ klicken. In Situationen, in denen neben der Datenaktualisierung auch ein Konfigurationsupdate erfolgt, empfiehlt es sich, dies auch vollautomatisch durchzuführen (z. B. mit Software von Drittanbietern).

Generieren von Update-Paketen

Da es eine eindeutige Entscheidung darüber gibt, welchen RDB-Knoten welche Funktionen zugewiesen werden, ist es möglich, nur das Datenpaket zu generieren, das dieser Knoten benötigt. Einerseits muss angegeben werden, welche Objekttypen zwischen Knoten synchronisiert werden sollen. Beispielsweise sollten die Abrechnungsregister für den Knoten „Store 1“ überhaupt nicht synchronisiert werden, weil Daten werden nur auf der Ebene des Zweigknotens eingegeben. Andererseits müssen diejenigen Arten von Daten, die einem Austausch unterliegen, abteilungsbezogen gefiltert werden. Beispielsweise können Daten zum Geldeingang vom Knoten „Filiale 1 Filiale 2“ nur in den Knoten „Filiale 2“, „Center 1“ und „Center 2“ gefunden werden.

Allerdings gibt es auch das gegenteilige Problem: Filtert man die Austauschdaten zu stark, verliert das Datenpaket seine logische Integrität. Beispielsweise werden die Warenbestände im Zusammenhang mit Lagern und die Reserven im Kontext des Unternehmens als Ganzes berücksichtigt. Wenn Sie dann die Warenbestände nach Lagern filtern und die Reserven nicht filtern, werden die Die Daten werden falsch sein.

Sie sollten auch entscheiden, in welchem Lebensabschnitt das Objekt ausgetauscht werden soll. Beispielsweise können nur gebuchte Rechnungen ausgetauscht werden, nicht jedoch einfach gespeicherte. Store-Rechnungen werden auch nach der Anpassung nie vom Center-Knoten entladen, es muss jedoch der gegenteilige Effekt berücksichtigt werden – die Daten sind möglicherweise nicht synchron oder einige Änderungen werden möglicherweise überschrieben.

Es ist wichtig zu verstehen, dass beim Austausch zwischen Knoten einer von ihnen Vorrang hat. Betrachten Sie die Situation:

Im Knoten „Shop 1“ wurde ein Dokument erstellt;
Während des Austauschs landete er im Knoten „Branch 1“;
Das Dokument wird in beiden Knoten gleichzeitig korrigiert.

Welches Dokument wird als wahr angesehen? In 1C 8.x ist bei Verwendung des Mechanismus „Exchange Plans“ die Standardpriorität der Hauptknoten, d. h. In diesem Fall gehen die im Knoten „Store 1“ vorgenommenen Änderungen verloren und werden durch Daten vom Knoten „Branch 1“ ersetzt.

Eine weitere, komplexere Situation entsteht, wenn zwei verbundene Objekte gleichzeitig angepasst werden. Beispielsweise werden die Rechnung und der PQR dafür in verschiedenen Knoten angepasst; es besteht die Möglichkeit eines Integritätsverlusts, wenn Preise, Zahlungsbeträge, Kontrahenten usw. geändert werden.

Wichtig ist auch, das Löschen von Objekten zu kontrollieren, da dies sonst dazu führen kann, dass beispielsweise eine Rechnung nicht mehr existiert, Buchhaltungsbewegungen aber bestehen bleiben.

Austauschmechanismen in 1C 8.x

Für die Umsetzung gibt es zwei Ansätze:

„Exchange Plans“-Mechanismus;
Eigene Implementierung der Objektregistrierung.

Betrachten wir beide Optionen.

Der Mechanismus der Austauschpläne ermöglicht es, ohne jegliche Konfiguration in wenigen Minuten eine Datenbank mit vollständigem Datenaustausch zu erstellen. Wenn Sie das Flag „Verteilte Infobase“ setzen, werden beim Erstellen eines Update-Pakets auch Konfigurationsupdates heruntergeladen. In nur wenigen Minuten können Sie Regeln zum Zulassen/Verbieten des Austauschs verschiedener Datentypen festlegen, indem Sie die Zusammensetzung des Austauschplans öffnen. Wenn Sie das Flag „Auto-Registrierung“ auf die Position „Verweigern“ setzen, wird ein solcher Objekttyp niemals ohne zusätzlichen Aufwand ausgetauscht.

Warum ist eine Registrierung erforderlich, warum nicht alles auf einmal hochladen? In jedem Fall ist eine Datei, die nur Änderungen am Datenbankstatus enthält, kleiner als ein vollständiger Snapshot der Datenbank selbst. Daher wird die Möglichkeit einer vollständigen Entladung nicht in Betracht gezogen.

Wie richte ich die Datenfilterung nach Abteilungszugehörigkeit ein? Hier müssen Sie bereits programmieren. In meiner Implementierung wurde ein Abonnement für das Ereignis „Beim Schreiben“ für die Aufzeichnung eines beliebigen Objekts installiert, wobei Sie mithilfe der Eigenschaft „Datenaustausch. Empfänger“ die Liste der Empfänger dieses Objekts festlegen können. Diese. Beim Entladen mit Standardmitteln für einen Knoten, der nicht in der Liste enthalten ist, wird das Objekt nicht entladen. Es gibt eine andere Lösung: Sie können in den Verfahren „Beim Senden von Daten an einen Untergebenen“ und „Beim Senden von Daten an einen Master“ des Austauschplanmoduls auswählen, ob ein Objekt direkt beim Entladen des Objekts entladen werden soll.

Beide Optionen haben ihre Daseinsberechtigung. Allerdings habe ich die erste Option als die beste Option gewählt, da die Berechnung des Vorladefähigkeitsattributs sofort beim Schreiben des Objekts erfolgt, was die Dauer der Objektaufzeichnung um 3-5 % erhöht (kann optimiert werden, in manchen Fällen auch). auf 0,01 % reduziert werden, d. h. im Durchschnitt 0,1-0,3 Sekunden, und wenn die Entladebarkeit eines Objekts direkt beim Senden von Daten berechnet wird, was bereits eine erhebliche Belastung der Datenbank darstellt, beträgt diese Zeit bis zu mehrere Minuten.

Um die Funktionsweise des Mechanismus „Exchange Plans“ vollständig zu verstehen, empfehle ich die Lektüre von Kapitel 15 des Buches „Berufliche Entwicklung im 1C:Enterprise 8-System“, Gabets A.P., Goncharov D.I.

Meiner Meinung nach wird jede eigene Implementierung entweder den „Exchange Plans“-Mechanismus wiederholen oder das Objekt bei Änderungen sofort entladen oder mehr als den „Exchange Plans“-Mechanismus entladen (z. B. alle Änderungen für heute entladen). Ich berücksichtige dieses Problem aufgrund mangelnder Implementierungserfahrung nicht.

Transport

Die Aufgabe, Dateien vom Master- zum Slave-Knoten zu transportieren, wird auf maximale Fehlertoleranz reduziert. Es ist nicht ungewöhnlich, dass Dateien verschlüsselt oder über einen sicheren Kanal übertragen werden. Um Dateien zu übertragen, empfiehlt es sich, mehrere unterschiedliche Dienste zu nutzen oder mehrere unterschiedliche Verbindungsoptionen vorzubereiten. Die Hauptübertragungsmethode ist beispielsweise die Verwendung eines FTP-Servers, der über einen VPN-Tunnel verbunden ist; Der Backup-Server ist ein E-Mail-Server mit einer TLS-Verbindung. Warum benötigen Sie einen Backup-Kanal mit einem anderen Dienst? Wie die Praxis zeigt, ist die Verwendung von zwei verschiedenen FTP-Servern weniger zuverlässig als ein FTP-Server und E-Mail.

Ich empfehle, den Aktualisierungspaket-Erstellungsdienst vom Transportdienst zu trennen, da dies die Fehlertoleranz des gesamten Datenaustauschkomplexes erhöht. Wenn der Dateitransportdienst nicht funktioniert, funktioniert der Dienst zum Erstellen von Update-Paketen normal weiter und startet unter bestimmten Bedingungen den Transportdienst neu und umgekehrt.

Meine RDB-Implementierung

Die Umsetzung erfolgt völlig autonom, daher fungierte als Teilaufgabe maximale Fehlertoleranz. Daraus entstanden zwei Dienste – der Update-Transportdienst und der Datenimport-/Exportdienst. Beide Dienste arbeiten unabhängig voneinander.

Nach jedem erfolgreichen Datenimport-Export-Zyklus wurde der Zeitpunkt des letzten Austauschs mit diesem Knoten gespeichert. Wenn der Austausch sehr lange nicht stattfand, begann der Transportdienst, Dateien auf alle ihm zur Verfügung stehenden Kommunikationskanäle hochzuladen, in der Erwartung, dass der zweite Knoten weiterhin Updates erhalten und seine Dateien hochladen würde. In Ausnahmesituationen sendet das System selbst eine Meldung mit einer detaillierten Fehlerbeschreibung an den Administrator.

Um den Datenverkehr zu reduzieren, wurden XML-Dateien in Zip-Archive gepackt. Das System unterstützt zwei Transportarten: FTP und E-Mail.

Es gibt zwei Tabellen als Einstellungen für den Datenfilter. Einer (der tabellarische Teil von Austauschplänen) speichert Bedingungen für allgemeine Details (für jedes Objekt versucht das System, dieses Detail zu finden), der andere enthält Einstellungen für ein bestimmtes Metadatenobjekt. Bei der Erfassung eines beliebigen Objekts werden Bedingungen zunächst anhand allgemeiner Details (z. B. Abteilung) gesucht. Anschließend versucht das System anhand aller Details festzustellen, ob für diesen Objekttyp eine persönliche Regel vorliegt. Ich empfehle nicht, die Listen zu filtern – die Wahrscheinlichkeit eines Fehlers ist hoch, z. B. verschwinden mehrere Zeilen aus dem tabellarischen Teil der Rechnung und der Restbetrag wird verschoben und umgekehrt.

Es ist wichtig zu verstehen, unter welchem Systembenutzer die Dienste ausgeführt werden, denn Möglicherweise verfügen Sie nicht über ausreichende Rechte, um Dateien selbst im temporären 1C-Ordner zu erstellen. Zum Debuggen empfehle ich dringend, jeden erfolgreich abgeschlossenen Vorgang in das Registrierungsprotokoll oder in eine TXT-Datei zu schreiben. In 1C 8.1 kann die Ausführung von Servercode nicht debuggt werden.

Um das Debuggen und Einrichten meiner Implementierung zu erleichtern, füge ich die Verarbeitung „Registrierung von Änderungen“ bei, deren Beschreibung in der Verarbeitung selbst enthalten ist.

Das allgemeine Betriebsdiagramm des Datenaustauschkomplexes ist in Abb. 3 dargestellt.

Die Datenfilterung erfolgt in einem Abonnement für das Ereignis „BeforeRecording“ jedes Objekts. Vergessen Sie nicht, dass beim Erstellen des anfänglichen Knotenbilds auch die Daten gefiltert werden müssen. Das Verfahren zum Erstellen eines ersten Bildes ist ziemlich langwierig, daher empfehle ich, den Code maximal zu optimieren (z. B. Filtereinstellungen zwischenzuspeichern).

Nachwort

Die Hauptaufgabe besteht darin, eine Liste von Fragen zu beantworten:

Warum brauchen wir RDB?
Was könnte Ihnen an der Arbeit mit einem RDP-Client nicht gefallen?
Wo und warum wollen wir RDB-Knoten installieren?
Wie werden die Updates transportiert?
Welches Maß an Fehlertoleranz wird implementiert?

Abwicklung „Anmeldung von Änderungen“

Durch die Verarbeitung können Sie die Registrierung von Änderungen an Objekten erzwingen. Es gibt mehrere Möglichkeiten, Änderungen zu protokollieren:

Wenn Metadaten überprüft werden und keine Objekte ausgewählt sind und das Flag „Nach allen Werten laden“ NICHT gesetzt ist, wird NUR DIE AUSGEWÄHLTE TABELLE REGISTRIERT;
Wenn das Flag „Für alle Werte hochladen“ gesetzt ist, werden die ausgewählten Metadaten für alle Objekte im Zyklus entladen;
Wenn der Schalter auf den Modus „Nur ausgewählte Objekte hochladen“ eingestellt ist, werden nur ausgewählte Objekte entladen (Beispiel: Das Setzen eines Flags für Metadaten ohne Auswahl von Objekten entspricht dem Aktivieren des Flags „Nach allen Werten hochladen“ und des Schalters in der Position „Nur ausgewählte Objekte entladen“;
Wenn der Schalter auf den Modus „Ausgewählte und direkt verwandte Objekte entladen“ eingestellt ist, werden die ausgewählten Objekte und diejenigen Objekte, deren Existenz von der Existenz des ausgewählten Objekts abhängt, entladen (z. B. für Verzeichnisse – untergeordnete Verzeichnisse);
Wenn der Schalter auf den Modus „Hochladen über alle Links“ eingestellt ist, werden ALLE Objekte entladen, die einen Link zum ausgewählten Objekt enthalten.

Zusätzliche Funktionalität verfügbar:

Zum Debuggen ist häufig eine erneute Registrierung registrierter Objekte erforderlich.
Das Entfernen registrierter Dateien ist häufig zum Debuggen erforderlich.
Änderungen drucken – eine vollständige Liste der Objekte drucken, die als geändert markiert sind;
Das Drucken des Konfigurationsbaums dient lediglich der bequemen Anzeige der gesamten Konfiguration.

Distributed Information Base (DIB) – wird verwendet, wenn Zugriff auf verteilte Daten einer Kampagne oder eines Unternehmens erforderlich ist, um die darin enthaltenen Informationen nutzen und austauschen zu können.

Ein Beispiel ist die Konfiguration der Plattform Trade Management 11 (11.0.6.9) – 1C 8.2.

Um eine Distributionsinformationsbasis zu erstellen, müssen Sie die folgenden Vorgänge ausführen.

Als erstes starten wir 1C:Enterprise, gehen dann auf die Registerkarte „Administration“ und wählen schließlich den Punkt „Buchhaltungsparameter konfigurieren“.
Danach öffnet sich ein Fenster und wählen Sie darin den Punkt „Datenaustausch“. Klicken Sie auf „Nutzung des Datenaustauschs zulassen“ und anschließend auf die Schaltfläche „Aufzeichnen und schließen“.
Nachdem wir den Datenaustausch aktiviert haben, sollte auf der linken Seite des Fensters ein neuer Eintrag „Datenaustausch“ erscheinen. Klicken Sie auf den Punkt „Datenaustausch“.
Wenn sich das Fenster öffnet, klicken Sie auf die Schaltfläche „Erstellen“. Wählen Sie den Punkt „Erstellen Sie einen Austausch in einer verteilten Informationsbasis“. Danach öffnet sich das Assistentenfenster zum Erstellen einer Verteilungsinformationsbasis.
Wir suchen im sich öffnenden Fenster nach der Schaltfläche „Weiter“, klicken darauf und wechseln dann zu einem anderen Fenster. Der von Ihnen angezeigte Artikel beschreibt den Datenaustausch über ein lokales oder Netzwerkverzeichnis.
Suchen Sie das Exchange-Verzeichnis und aktivieren Sie das Kontrollkästchen neben „Ausgehende Nachrichtendatei komprimieren“. Klicken Sie dann auf „Weiter“ und überspringen Sie die nächsten beiden Fenster (wir tun dies, weil wir in diesem Artikel den Austausch per FTP und Mail nicht berücksichtigen).
Weiter klicken".
Den für Sie passenden Namen für den Datenaustauschplan nennen wir, ich habe zum Beispiel „Exchange_With_Peripheral_Base“ gewählt, Sie können Ihren Namen festlegen. Dann überprüfen wir, ob die „Hauptmethode des Datenaustauschs“ „Austausch über ein lokales oder Netzwerkverzeichnis“ ist und klicken auf „Weiter“.
Anschließend überprüfen wir den Inhalt des aktuellen Fensters und klicken auf „Weiter“.
Auch in diesem Fenster ändern wir nichts und klicken auf die Schaltfläche „Fertig stellen“.
Geben Sie den Pfad zum Ordner zum Erstellen der Distribution Information Base an. Sie müssen es im UNC-Format angeben, zum Beispiel „\\rib\1Cv8.1CD“. Wenn alles korrekt ist, wird im angegebenen Ordner eine verteilte Datenbankdatei erstellt.
Jetzt richten wir den automatischen Austausch und seinen Zeitplan ein. Gehen Sie dazu auf die Registerkarte „Administration“, wählen Sie den Punkt „Datenaustausch“ und doppelklicken Sie auf die vorhandene Zeile in der Liste der Datenaustausche:
Klicken Sie im sich öffnenden Fenster auf „Datenaustauschszenarien“:
Klicken Sie im sich öffnenden Fenster auf die Schaltfläche „Hinzufügen“:
Klicken Sie im sich öffnenden Fenster auf die Zeile „Jeden Tag, alle 900 Sekunden.“:
Stellen Sie im sich öffnenden Fenster die erforderlichen Parameter ein:
Wir stellen die Parameter so ein, dass der Austausch täglich von 00:00:00 bis 23:59:59 Uhr mit einer Pause von 30 Sekunden durchgeführt wird. Dies geschieht, um im beigefügten Video zu zeigen, dass der Austausch durchgeführt wird; Sie können andere Parameterwerte für sich selbst festlegen. Klicken Sie im vorherigen Fenster auf die Schaltflächen „OK“ und „Speichern und schließen“.
Die Konfiguration des Datenaustauschs für den zentralen Knoten ist abgeschlossen und der periphere Knoten wird auf die gleiche Weise konfiguriert. Es ist notwendig, die 1C-Startverknüpfung durch Hinzufügen des Startparameters „/CDoScheduledJobs“ zu ändern, damit der Austausch automatisch durchgeführt wird.

Das Einrichten des automatischen Austauschs auf einem Peripherieknoten unterscheidet sich nicht vom Einrichten auf dem Hauptknoten. Wenn Sie das Austauschskript konfigurieren, wird der Austausch automatisch gestartet, wenn sich ein Benutzer mit Administratorrechten anmeldet.

Die Konfiguration in der Distribution wird wie folgt aktualisiert: Manuell werden zunächst die Änderungen in der Zentralbank vorgenommen, dann laden wir sie hoch und übertragen sie an die Peripherie. Der automatische Austausch funktioniert in der Regel nicht.

Mit der Technologie der verteilten Informationsbasen (RIB) können Sie ein geografisch verteiltes System basierend auf 1C Enterprise-Konfigurationen erstellen. Dies ermöglicht Ihnen einen gemeinsamen Informationsraum auch mit Abteilungen, die nicht über einen zuverlässigen Kommunikationskanal verfügen, und kombiniert eine hohe Autonomie der Knoten mit der Möglichkeit eines schnellen Informationsaustauschs. In unseren Artikeln werden wir uns mit den Funktionen und der praktischen Umsetzung dieses Mechanismus auf der 8.2-Plattform befassen

Fragen wir uns zunächst einmal: Warum Autoexchange? Moderne Technologien, gepaart mit günstigem und schnellem Internet, ermöglichen eine problemlose Organisation von Remote-Arbeit. Die Auswahl an Methoden ist nach wie vor groß: RDP, Thin- und Web-Clients, Netzwerkanbindung per VPN – es gibt viel zu bedenken. Alle diese Methoden haben jedoch einen wesentlichen Nachteil – eine starke Abhängigkeit von der Qualität des Kommunikationskanals.

Auch bei optimalem Betrieb des lokalen Anbieters kann eine hundertprozentige Verfügbarkeit des Kommunikationskanals nicht garantiert werden. Probleme mit dem Backbone-Anbieter, mangelnde Stromversorgung, physische Schäden an der Kommunikationsleitung und viele andere Faktoren machen diese Aufgabe unüberwindbar. Gleichzeitig führt die Unzugänglichkeit der Informationsbasis in einem abgelegenen Lager oder Einzelhandelsgeschäft zu erheblichen Verlusten. Und schließlich dürfen wir nicht vergessen, dass es Orte gibt (z. B. Industriegebiete am Stadtrand), an denen die Bereitstellung eines hochwertigen Kommunikationskanals teuer und/oder problematisch ist.

Mit dem RIB-Mechanismus können Sie diese Mängel beseitigen; jede Abteilung verfügt über eine eigene Kopie der Informationsbasis, mit der Sie auch dann autonom arbeiten können, wenn keine Kommunikation mit der Außenwelt besteht. Und die geringe Menge an übertragenen Informationen ermöglicht es Ihnen, jeden Kommunikationskanal, einschließlich des mobilen Internets, für den Austausch zu nutzen.

RIB auf Plattform 8.2 ist nichts grundlegend Neues, sondern stellt eine Weiterentwicklung der RIB-Plattform 7.7 dar, nur ist diese Technologie jetzt zugänglicher und einfacher geworden. Im Gegensatz zur RIB-Komponente, die separat erworben werden musste, ist das RIB fester Bestandteil vieler Standardkonfigurationen und funktioniert vollständig im Benutzermodus, sodass Sie bereits bei der Einrichtung auf den Konfigurator verzichten können.

An dieser Stelle wäre es an der Zeit, zum praktischen Teil überzugehen, aber wir müssen noch einen Exkurs machen. Tatsache ist, dass der Übergang zur 8.2-Plattform, der offenbar bereits stattgefunden hat, tatsächlich zur Entstehung von zwei Arten von Konfigurationen geführt hat: basierend auf einer verwalteten Anwendung, „nativ“ für die 8.2-Plattform und angepasst von 8.1, fortlaufend veraltete Technologien und Mechanismen zu nutzen. Da ein erheblicher Teil der Konfigurationen (Unternehmensbuchhaltung, Lohn- und Gehaltsabrechnung und Personalverwaltung) angepasst oder vorübergehend sind, können sie nicht außer Acht gelassen werden. Daher wird der erste Teil unseres Artikels diesen Konfigurationen (im Wesentlichen der 8.1-Plattform) gewidmet, während der zweite Teil Wir werden die Einrichtung des automatischen Austauschs für Konfigurationen untersuchen, die auf einer verwalteten Anwendung (Plattform 8.2) basieren.

Betrachten wir eine praktische Aufgabe: Einrichten des automatischen Austauschs per FTP für die Enterprise Accounting 2.0-Konfiguration. Obwohl RIB den Austausch per E-Mail oder Dateifreigabe ermöglicht, empfehlen wir die Verwendung von FTP als einfachste und zuverlässigste Kommunikationsmethode. Sie können lesen, wie Sie Ihren eigenen FTP-Server einrichten, oder Sie können den FTP-Dienst eines beliebigen Hosting-Anbieters nutzen.

Zunächst müssen wir die Austauschknoten konfigurieren. Dazu die Konfiguration mit Administratorrechten starten und auswählen Transaktionen – Austauschpläne.

Wählen Sie in der angezeigten Liste aus Voll planen bzw Nach Organisation, wenn Datensätze für mehrere Unternehmen in einer Datenbank geführt werden und der Austausch nur für eines davon erfolgen muss. Im sich öffnenden Fenster gibt es bereits einen Knoten – den zentralen, wir müssen ihn bearbeiten, indem wir den Code und den Namen angeben.

Dann erstellen wir einen weiteren Knoten für den Zweig und füllen ihn auf die gleiche Weise (zum Hinzufügen klicken Sie auf den grünen Kreis mit einem Plus). Der nächste Schritt besteht darin, ein erstes Image für diesen Knoten zu erstellen, bei dem es sich um eine vorgefertigte Informationsbasis im Dateimodus handelt. Klicken Sie dazu mit der rechten Maustaste auf den gewünschten Knoten und wählen Sie ihn aus der Dropdown-Liste aus Erstellen Sie ein Startbild.

Jetzt lasst uns weitermachen Dienst – Distributed Information Base (DIB) – RIB-Knoten konfigurieren.

Klicken Sie im sich öffnenden Fenster auf die Schaltfläche Hinzufügen und konfigurieren Sie einen neuen Austausch, indem Sie den Remote-Host, den Austauschtyp (über FTP) und die Serververbindungsparameter angeben.

Lesezeichen Automatischer Austausch ermöglicht Ihnen die Einrichtung eines Austauschplans, den Austausch nach Ereignissen (Beginn und Ende der Arbeit usw.). Diese Einstellungen werden für den Benutzer vorgenommen, in dessen Namen der Austausch durchgeführt wird. Stellen Sie daher sicher, dass er über Rechte zum Datenaustausch verfügt.

Vergessen Sie nicht, unter Extras - Programmeinstellungen das Knotenpräfix für die Dokumentnummerierung anzugeben (sonst erhalten Sie unterschiedliche Dokumente mit den gleichen Nummern); hier können Sie auch einige andere Austauschparameter konfigurieren. Auf derselben Registerkarte sollten Sie einen Benutzer auswählen, der Austauschaufgaben ausführen soll. Wenn Sie dies nicht tun, funktioniert der Zeitplan nicht. Denken Sie daran, dass der Austausch nur dann erfolgt, wenn der Benutzer im Programm angemeldet ist.

Damit ist die Konfiguration des zentralen Knotens abgeschlossen. Jetzt müssen Sie ähnliche Einstellungen für den peripheren Knoten vornehmen und das ursprüngliche Image als vorhandenes Informationssicherheitssystem verbinden. Anschließend können Sie mit dem Datenaustausch beginnen. Zur Kontrolle sollten Sie verwenden Kommunikationsmonitor Damit können Sie nicht nur den Erfolg des Uploads/Downloads überwachen, sondern auch aufgetretene Kollisionen oder verzögerte Bewegungen anzeigen (falls der Benutzer, der den Austausch durchgeführt hat, nicht über ausreichende Rechte verfügt, um Aktionen in der Datenbank durchzuführen). Das Vorhandensein dieses Tools ermöglicht es Ihnen, verschiedene Arten von Problemen, die beim automatischen Austausch auftreten, schnell und effektiv zu lösen.

An diesem Punkt kann die Exchange-Einrichtung als abgeschlossen betrachtet werden und Sie können mit der Arbeit im verteilten Modus beginnen. Es lohnt sich, sich gezielt mit der Aktualisierung oder Änderung der Konfiguration zu befassen. Diese Aktionen sind nur auf dem zentralen Knoten verfügbar; alle vorgenommenen Änderungen werden beim nächsten Austausch automatisch an die peripheren Knoten weitergegeben. Um Änderungen automatisch vorzunehmen, muss sich die periphere Datenbank im exklusiven Modus befinden. Andernfalls müssen Sie sie ausführen Konfigurator und ausführen Aktualisieren der Datenbankkonfiguration manuell.

In 1C 8.3 oder in 1C 8.2? Einrichten einer verteilten Infobase. Schritt-für-Schritt-Anleitung.

Die Informationsbasisverteilung wird verwendet, wenn es notwendig ist, gemeinsame Datensätze in Datenbanken zu führen, die aus verschiedenen Gründen keine physische Verbindung haben können. Ein Beispiel wäre die Buchhaltung eines Unternehmens, das eine Niederlassung in einer Großstadt oder einem kleinen Dorf hat und nicht über die Möglichkeit verfügt, eine Verbindung zum Internet herzustellen. Oder in einigen besonderen Fällen, in denen es regelmäßig erforderlich ist, gleichzeitig mit einer Datenbank im Büro und außerhalb des Büros, beispielsweise zu Hause, zu arbeiten. In solchen und ähnlichen Fällen ist der Einsatz einer verteilten Informationsbasis (DIB) gerechtfertigt und notwendig.

In diesem Artikel befassen wir uns mit der Organisation der Verteilung einer Informationsdatenbank in der Konfiguration von 1C Accounting for Russia Version 8.3 über ein lokales oder Netzwerkverzeichnis. In Version 8.2 1C wird diese Anleitung auch nützlich sein, weil beschreibt im Wesentlichen einen Prozess mit deutlich geringen Unterschieden.

==== Vorbereitungen für die Hauptbasis ====

Nachdem wir 1C 8.3 im „Enterprise“-Modus geöffnet haben, gehen wir zum Abschnitt „Administration“. In Version 1C 8.2 müssen Sie zum Einstieg zum Hauptmenü „Service“ – „Distributed Information Base (DIB)“ – „RIB-Knoten konfigurieren“ gehen.

Als nächstes betrachten wir den Prozess im Kontext der Informationssicherheitsversion 8.3. Gehen Sie also zum Abschnitt „Administration“ und wählen Sie „Programmeinstellungen“. Gehen Sie in den Einstellungen zum Abschnitt „Datensynchronisierung“. Hier setzen wir den Haken bei „Datensynchronisierung verwenden“ und geben das Datenbankpräfix an. Geben wir „CB“ an, was eine zentrale Basis impliziert.

Danach erscheint im rechten Menü der Punkt „Datensynchronisation“. Lasst uns ihn wählen. Klicken Sie im sich öffnenden untergeordneten Fenster auf die Schaltfläche „Datensynchronisierung einrichten“. Im Dropdown-Menü können Sie Einstellungen für verschiedene Synchronisierungsanwendungsfälle auswählen. Wir wählen „Verteilte Informationsbasis...“.

Machen Sie sich zur allgemeinen Entwicklung mit dem Inhalt des nächsten Fensters vertraut und klicken Sie auf „Weiter“.

Geben Sie im nächsten Fenster das Verzeichnis ein, über das die . Wir legen die Datenkomprimierung fest, um die Größe des Uploads zu reduzieren, und Sie können sofort ein Passwort für das Archiv mit den Daten festlegen. Es ist wichtig, ihn nicht zu vergessen. Bestätigen Sie das Ausfüllen mit der Schaltfläche „Weiter“.

In den nächsten beiden Fenstern werden Einstellungen für den Austausch über einen FTP-Server und per E-Mail vorgenommen. Wie bereits erwähnt, erwägen wir die Austauschmethode über ein Verzeichnis und überspringen daher die Einstellungen für FTP und E-Mail.

Das nächste Fenster dient der Festlegung von Austauschparametern im peripheren Datenbankteil. Geben wir seinen Namen und sein Präfix an. Als nächstes kommt die Schaltfläche „Weiter“.

Lassen Sie uns die von uns erstellten Austauschparameter überprüfen und ihre Richtigkeit mit der traditionellen Schaltfläche „Weiter“ bestätigen.

Die für den Austausch notwendigen Einstellungen werden automatisch erstellt. Es wird einige Zeit in Anspruch nehmen.

Wichtig! Das Erstellen des ersten Images für den Slave-Knoten nimmt viel Zeit in Anspruch. Die Größe dieser Signifikanz hängt von den Computerressourcen und dem Abrechnungsvolumen in der Hauptdatenbank ab.

Nehmen wir an, wir beschließen, ein Bild zu erstellen. Nachdem wir im vorherigen Fenster auf die Schaltfläche „Fertig stellen“ geklickt haben, geben wir die Einstellungen ein, um ein Abbild der Slave-Informationssicherheit zu erstellen. Wir betrachten den einfachsten Fall für lokale Operationen. Geben Sie dazu im sich öffnenden Fenster die notwendigen Angaben an. Besonderes Augenmerk legen wir auf den Parameter „Vollständiger Name der Dateibasis“. Es muss im vollständigen UNC-Format angegeben werden, was die Bildung eines lokalen Pfads im „Netzwerk“-Format erfordert. Beispiel: „\\Server1C\Databases\RIB“. Zum angegebenen Pfad fügen wir den Namen der Datenbankdatei hinzu – 1Cv8.1CD.

Nach einem Klick auf die Schaltfläche „Startbild erstellen“ beginnt der Prozess der Generierung eines Bildes für die Slave-Datenbank.

Nach Abschluss des Vorgangs wird im angegebenen Verzeichnis eine Datenbankdatei erstellt. Diese neu erstellte Datenbank muss vor der vollständigen Nutzung konfiguriert werden.

==== Vorbereitung für eine periphere Basis ====

Dazu müssen Sie es an 1C anschließen. Wie das geht, erfahren Sie in der Anleitung in unserem Artikel – Nach der Verbindung müssen Sie die neue Datenbank im Konfiguratormodus starten und Benutzer anlegen. Als nächstes muss die Informationssicherheit im 1C-„Enterprise“-Modus gestartet werden.

Wenn die Erstellung von Benutzern aus irgendeinem Grund auf einen späteren Zeitpunkt verschoben werden muss, können Sie die Datenbank nach dem Herstellen der Verbindung einfach im 1C-Enterprise-Modus starten. Sie werden aufgefordert, einen „Administrator“-Benutzer zu erstellen, diesem zuzustimmen und die Erstbefüllung erfolgt.

Anschließend müssen Sie mit der Einrichtung der Kopplung mit der Hauptbasis fortfahren. Diese Einstellung ähnelt der oben für die Hauptdatenbank besprochenen.

Es wird ein Setup für die Kommunikation mit der Hauptbasis erstellt.

============================================

So, jetzt haben wir die Haupt- und Randbasen geschaffen. In jeder dieser Datenbanken wurden auch Synchronisierungseinstellungen erstellt. Jetzt können Sie diese Einstellungen bearbeiten und in eine geeignete Form bringen. Sie können automatische Austauschregeln erstellen oder den Austausch manuell durchführen.

Machen wir das in der Hauptdatenbank. Die periphere Basis ist auf die gleiche Weise konfiguriert.

Die Bearbeitung kann auf Datensynchronisierungsregeln und -zeitpläne angewendet werden.

Durch Klicken auf die Schaltfläche „Konfigurieren“ im Abschnitt „Zeitplan für die Datensynchronisierung“ müssen Sie die Skripts bearbeiten, um die Arbeit zum Hochladen/Laden von Daten für die ausgewählte Datenbank automatisch zu planen. Sie müssen es nicht bearbeiten, sondern stimmen einfach den Standardoptionen zu.

Um die Parameter zu bearbeiten, klicken Sie einfach auf den Link mit den automatischen Zeitplandaten. Und dann bearbeiten wir die temporären Parameter zum Starten von Aufgaben. Indem Sie die Lesezeichen durchgehen, können Sie sowohl die Uhrzeit als auch die Daten und Wochentage des Starts ändern.

Durch Klicken auf die Schaltfläche „Aufgabe ausführen“ im Hauptskriptfenster können Sie die Aufgabe manuell ausführen.

Durch Klicken auf die Schaltfläche „Konfigurieren“ im Abschnitt „Datensynchronisierungsregeln“ können Sie Vorgänge zum Ändern von Aufgabenstartskripten ausführen und das Protokoll der Uploads/Downloads anzeigen. Letzteres ist sehr wichtig für die Verwaltung des Zugangs und die Überwachung der Regelmäßigkeit des Austauschs.

Nachdem Sie die Erstellung und Bearbeitung von Skripten zum automatischen Starten des verteilten Datenbankaustauschs abgeschlossen haben, können Sie mit dem Hochladen und anschließenden Laden von Daten fortfahren.

Zu diesem Zeitpunkt ist die Konfiguration der verteilten Badehausdatenbank für die zentralen und peripheren Knoten im Wesentlichen abgeschlossen.

Laden Sie die bebilderte Anleitung herunter

Verteilte Informationsbasis. Schritt-für-Schritt-Anleitung
Verteilte Informationsbasis (RIB) 1C:Enterprise
Erstellen und Einrichten einer verteilten Infobase
So richten Sie Rib in 1s ein 8.2
So richten Sie eine verteilte Informationsbasis in 1C ein
So richten Sie es in 1C ein
So richten Sie es in 1C ein
Einrichten einer verteilten Informationsbasis (RIB) in 1C
Beispiel für die Einrichtung von RIB für 1C:Accounting 8
Erstellung einer verteilten Infobase und Konfiguration

Anweisungen zum Erstellen und Konfigurieren verteilter Datenbanken mithilfe der URDB-Komponente (URIB).

Die URDB-Komponente (Distributed Database Management) dient zum Austausch von Informationen zwischen zwei identischen 1C-Datenbanken. Wenn die Konfigurationen unterschiedlich sind, können Sie es auch verwenden, dies steht in einem anderen Artikel. Damit die Komponente funktioniert, muss sich die Datei DistrDB.dll im BIN-Ordner des Programms 1C: Enterprise befinden.

Schauen wir uns die Schritte zum Erstellen verteilter Datenbanken an. Beispielsweise haben wir eine Arbeitsbasis im Verzeichnis D:\base1. Es ist erforderlich, es zentral zu gestalten und eine periphere Basis zu schaffen.

1. Erstellen Sie ein Verzeichnis D:\base2 für die Peripheriedatenbank.

2. Erstellen Sie in den Verzeichnissen D:\base1 und D:\base2 die Ordner CP und PC (verwenden Sie lateinische Buchstaben).

3. Starten Sie den zentralen Datenbankkonfigurator (D:\base1) und wählen Sie Menü – Verwaltung – Verteilte Informationssicherheit – Verwaltung.

4. Klicken Sie auf die Schaltfläche „Zentrale Informationssicherheit“ und geben Sie im angezeigten Fenster den Code und den Namen der Datenbank ein. Für den Code ist es besser, Zahlen oder lateinische Buchstaben zu verwenden. Geben Sie beispielsweise 001 und „Zentrale Basis“ ein und bestätigen Sie mit der „OK“-Taste.

5. Klicken Sie auf die Schaltfläche „Neue periphere Informationssicherheit“, um eine periphere Datenbank zu erstellen. Wir geben die Parameter dafür ein: 002 und „Peripheriebasis 1“.

6. Wählen Sie mit dem Cursor die Basis „Peripheriebasis 1“ aus und drücken Sie die Schaltfläche „Setup“. Auto-Austausch". Ändern Sie in den Einstellungen den manuellen Modus auf automatisch. Seien Sie vorsichtig, das ist wichtig.

7. Wählen Sie mit dem Cursor die Datenbank „Peripheriebasis 1“ aus und klicken Sie auf die Schaltfläche „Daten hochladen“ und dann auf die Schaltfläche „OK“. Als Ergebnis des Uploads erscheint die Datei D:\base1\CP\020.zip.

8. Starten Sie 1C im Konfiguratormodus, fügen Sie im 1C-Startfenster eine neue Datenbank „Peripheriedatenbank 1“ hinzu und geben Sie das zuvor erstellte Verzeichnis D:\base2 dafür an.

9. Wählen Sie Menü – Verwaltung – Verteilte Informationssicherheit – Verwaltung. Auf die gestellte Frage „Die Informationsbasis wurde nicht gefunden.“ Möchten Sie Daten laden?“ Klicken Sie auf die Schaltfläche „Ja“ und geben Sie den Dateinamen „D:\base1\CP\020.zip“ an, klicken Sie auf die Schaltfläche „OK“. Nachdem der Download abgeschlossen ist, kann der Prozess der Erstellung einer peripheren Datenbank als abgeschlossen betrachtet werden.

In und auch in den Methoden zum Erstellen einer peripheren Datenbank durch Wiederherstellen einer Kopie der zentralen Datenbank aus einer Sicherung oder Anhängen von Dateien einer Kopie der zentralen Datenbank für das SQL-Format und Ausführen des Skripts werden angegeben. Dies ist bei großen Datenmengen nützlich, wenn Uploads und Downloads Stunden dauern oder völlig unrealistisch sind.

Anweisungen zum Austausch zwischen verteilten Datenbanken mithilfe der URDB-Komponente (URIB).

Betrachten wir ein vereinfachtes Beispiel: Wir führen den Austausch manuell durch, indem wir den Konfigurator starten. Sie können den Batch-Modus des Konfigurators verwenden; Sie können E-Mail, FTP und automatisches Kopieren von Dateien verwenden, um Austauschpakete zuzustellen.

Um den Austausch durchzuführen, müssen Sie Menü – Verwaltung – Verteilte Informationssicherheit – Automatischer Austausch auswählen. Erfolgt der Austausch automatisch (siehe Punkt 6 der vorherigen Anleitung), dann klappt alles.

1. Wir ändern oder erstellen also einige Objekte, die in die periphere Datenbank migriert werden. Objektmigrationsregeln werden auf der Registerkarte „Migration“ in den Objekteigenschaften festgelegt (siehe Objektbaum im Konfigurator).

2. Starten Sie den zentralen Datenbankkonfigurator, wählen Sie Menü – Verwaltung – Verteilte Informationssicherheit – Auto Exchange, klicken Sie auf die Schaltfläche „Ausführen“.

3. Verschieben Sie die resultierende Datei D:\base1\CP\020.zip in den Ordner D:\base2\CP\

4. Wir ändern einige Objekte in der Peripheriedatenbank. Am besten nicht diejenigen, die zuvor in der zentralen Datenbank geändert wurden, denn Bei Objektänderungen beim Austausch hat die zentrale Datenbank Vorrang.

5. Starten Sie den Peripheriedatenbank-Konfigurator, wählen Sie Menü – Verwaltung – Verteilte Informationssicherheit – Automatischer Austausch, klicken Sie auf die Schaltfläche „Ausführen“.

6. Als Ergebnis des automatischen Austauschs sollten wir Änderungen aus der zentralen Datenbank erhalten. Wir sollten auch eine Datei zur Übertragung in die zentrale Datenbank D:\base2\PC\021.zip haben

7. Kopieren Sie die Datei D:\base2\PC\021.zip in den Ordner D:\base1\PC

8. Wiederholen Sie Punkt 2. Dadurch werden die von der peripheren Datenbank empfangenen Änderungen in der zentralen Datenbank angezeigt.

Also das allgemeine Prinzip des Austauschs: abwechselnde Ausführung des automatischen Austauschs mit gleichzeitiger Verschiebung von Dateien (Austauschpaketen) vom PC-Ordner einer Datenbank in den PC-Ordner einer anderen Datenbank und vom CP-Ordner einer Datenbank in den CP-Ordner von eine andere Datenbank.

Konfigurationsänderungen werden nur in der zentralen Datenbank vorgenommen. Bei einer Änderung der Konfiguration ist es erforderlich, den Austausch in peripheren Datenbanken im exklusiven Modus durchzuführen. Um Pakete aus peripheren Datenbanken in der zentralen Datenbank erfolgreich zu verarbeiten, muss die Konfiguration in die peripheren Datenbanken geladen werden. Wenn Sie verwirrt sind, ist das kein Problem, das von der zentralen Datenbank abgelehnte Paket wird erneut heruntergeladen.