Să începem, ca întotdeauna, de la început. După ce ați creat RIB, puteți efectua toate modificările la configurația bazei de date de informații numai în nodul principal. Ulterior, la următorul schimb, toate modificările vor fi transferate către nodurile subordonate și aplicate automat acolo. Dar era netedă pe hârtie.
În practică, uneori se întâmplă ca între sesiunile de schimb, mai ales dacă periferia este rău cu canalul, configurația nodului principal reușește să se schimbe de două ori. De exemplu, modificările au fost făcute, descărcate, baza periferică a schimbării a fost primită, dar nu le-a aplicat încă, ceea ce poate dura ceva timp și confirmarea nu a fost încă trimisă. Dacă modificați acest interval, descărcați din nou și din nou schimbul, se pare că centrul se așteaptă să vadă configurația # 1 în nodul periferic și încercați să îl actualizați la configurația # 3 și, de fapt, se va confrunta cu configurația # 2 acolo. Uneori, o situație similară apare atunci când baza de date centrală este actualizată dinamic. În consecință, schimbul va deveni imposibil și veți primi un mesaj în care se spune că configurația nodului IB distribuit nu se potrivește cu cel așteptat!
În general, moralul acestei povestiri este simplu - nu revizuiți activ baza de lucru și, dacă conduceți, finalizați toate sesiunile de schimb înainte de a face următoarele schimbări. Dar cum să fii, dacă s-ar fi întâmplat așa ceva?
Decizia "pe frunte" este de a crea o imagine nouă a nodului subordonat, dar în practică nu este, de obicei, aplicabilă. De regulă, apariția unei erori grave la schimb nu este stabilită imediat, dar după un timp după ce datele operaționale din bazele periferice au încetat să ajungă. În funcție de calendarul schimbului dintre momentul apariției problemei și detectarea acesteia, aceasta poate dura o zi întreagă de lucru și chiar mai mult.
Pentru a schimba configurația nodului slave, trebuie să o deconectați temporar de la baza centrală de date. În acest scop, puteți utiliza unul dintre tratamentele care sunt suficient de reprezentate în rețea sau deconectați IS de la nodul central utilizând parametrul Configurator / ResetMasterNode.
Deschideți un prompt de comandă și tastați (luând în considerare versiunea platformei și calea de instalare reală):
După ce se execută această comandă, va apărea fereastra obișnuită de pornire, selectați baza necesară și faceți clic pe butonul Confugator.
Atenție vă rog! Pe platformele 8.3.7 - 8.3.9, executarea acestei comenzi are ca rezultat oprirea anormală. Problema este fixată în platforma 8.3.10.
Dacă nu doriți să vă mâncați cu linia de comandă, atunci puteți folosi unul dintre tratamente, mai jos este cel pe care îl folosim, a fost găsit în rețea și am făcut doar modificări cosmetice la acesta. Rețineți că procesarea este potrivită numai pentru o aplicație tipică, pentru configurațiile unei aplicații gestionate, utilizați cheia de pornire Configurator.
Lucrul cu acesta este extrem de simplu, executați în modul 1C: Enterprise, prin File - Open. apoi apăsați butonul dorit, în cazul nostru Dezactivați nodul principal.
Acum avem nevoie de configurația reală de la nodul central. Pentru a face acest lucru, deschideți centrala IB din Configurator și executați Configurația - Salvați configurația într-un fișier. Fișierul rezultat cu extensia cf va trebui transferat la nodul periferic.
Acum trebuie să restaurați conexiunea de bază la nodul central. Pentru configurații bazate pe o aplicație obișnuită (de exemplu, Retail 1.0), veți avea nevoie de procesare. Porniți-l și selectați Restaurare nod principal.
