1c Distribuția de configurare a IB-ului. Pentru a preveni problemele numite această eroare, se recomandă să nu faceți o actualizare dinamică (cel puțin de mai multe ori într-un rând - înainte de a descărca modificări ale ramurilor) și, de preferință, în setările postului de schimb

Baza de informație distribuită (RIB) este adesea folosită pentru a organiza activitatea de ramuri și unități, permițându-vă să schimbați rapid informații, menținând în același timp gradul de autonomie dorit. Cu toate că această tehnologie Este destul de fiabil, se rupe din când în când. Astăzi ne vom uita la una dintre greșelile destul de comune: vom spune despre motivele apariției și metodelor de combatere a acestuia.

Să începem, ca întotdeauna, de la început. După ce ați creat RIB toate modificările la configurație baza de informare pot fi făcute numai în nodul principal. Ulterior, cu următorul schimb, toate modificările vor fi transferate în nodurile subordonate și sunt utilizate automat acolo. Dar a fost netedă pe hârtie ...

În practică, uneori se întâmplă că între sesiunile de schimb, mai ales dacă pe periferie este rău cu canalul, configurația principală a nodului are timp să se schimbe de două ori. De exemplu, a făcut modificări, descărcate, baza de date periferică primită, dar nu le-a aplicat încă, ceea ce ar putea dura ceva timp, iar confirmarea nu a fost încă trimisă. Dacă în timpul acestui decalaj pentru a face modificări din nou și a descărca din nou schimbul, se va dovedi că centrul se așteaptă să vadă numărul de configurare 1 în nodul periferic și va încerca să o actualizeze la configurarea nr. 3 și, de fapt, se va confrunta Configurare nr. 2. Uneori această situație apare atunci când baza centrală este dinamică. Ca rezultat, schimbul va fi imposibil și veți primi un mesaj care Configurația nodului IB distribuit nu se potrivește cu cea așteptată!

În general, moralul acestei povestiri este simplu - nu perfecționați în mod activ baza de lucru și dacă conduceți, completați toate sesiunile de schimb înainte de a efectua următoarele modificări. Dar cum să fie dacă sa întâmplat o astfel de problemă?

Soluția "în frunte" este de a crea o nouă imagine a nodului subordonat, dar în practică nu este de obicei aplicabilă. De regulă, apariția unei erori grave în schimb nu este fixată imediat, dar după o anumită perioadă după ce datele operaționale din bazele periferice au încetat. În funcție de programul de schimb între momentul apariției problemei și detectarea acestuia poate avea loc o zi de lucru întregi sau chiar mai mult.

Aici merită să aruncați o piatră în grădina dezvoltatorilor care dau o greșeală și subliniază situația roșie Numărul mesajului este mai mic sau egal cu numărul primit anteriorcare este, în general, destul de normal. Ca rezultat, utilizatorii, percepția erorilor sunt lovite și pur și simplu încetează să citească mesajele afișate, crezând că totul este bine și doar o altă parte nu a făcut încă schimbul în sine.

Dar înapoi la greșeala noastră. Soluția este destul de simplă și se află pe suprafață: pentru a aduce configurația bazei periferice la așteptat, adică. Aduceți-o în linie cu configurația nodului central. Dar, în practică, acest lucru nu este atât de simplu. Dacă deschidem baza periferică în configurator, vom vedea că modificările sunt blocate de comenzile RID.

Pentru a schimba configurația nodului subordonat, va fi necesar să o dezactivați temporar de la baza centrală. În aceste scopuri, puteți utiliza unul dintre tratamente, care sunt prezentate în rețea sau dezactivează IB de la nodul central utilizarea parametrului de pornire a configuratorului/ ResetareMasternode..

Deschideți promptul de comandă și introduceți (luând în considerare versiunea platformei și a căii de instalare reale):

"C: \\ Program (x86) \\ 1cv8 \\ 8.3.6.2100 \\ bin \\ 1cv8.exe" Config / ResetMasternode

După executarea acestei comenzi, va apărea o fereastră regulator de pornire, selectați baza de date dorită acolo și faceți clic pe Conivrator..

Lansați Ib în același timp nu se va intampla. Poate părea că nu sa întâmplat nimic, ci prin deschiderea bazei de date din configurator, vă puteți asigura că este dezactivată de la nodul principal și este disponibil pentru efectuarea modificărilor.

Atenţie! Pe platformele 8.3.7 - 8.3.9 Execuția acestei comenzi conduce la o finalizare de urgență a muncii. Eroarea este fixată în platforma 8.3.10.

Dacă nu vrei să teștizi linie de comandaPuteți utiliza unul dintre tratamente, cel care este prezentat mai jos pe care îl folosim, a fost găsit pe discul rețelei și am introdus-o numai pe ea numai pentru editări cosmetice. Notă, procesarea este potrivită numai pentru o aplicație obișnuită, pentru configurații pe o aplicație gestionată, utilizați cheia de pornire a configuratorului.

Lucrul cu acesta este extrem de simplu, executați-l în modul 1C: întreprinderi, prin Fișier - DeschisApoi apăsați butonul dorit în cazul nostru Dezactivați nodul principal.

Acum avem nevoie de configurația curentă de la nodul central. Pentru a face acest lucru, deschis central Ib. în configurator și executați Configurare - Salvați configurația la fișier. Fișierul rezultat cu extensia cf. Va fi necesar să se transfere la nodul periferic.

Apoi, în nodul periferic, executați IB (după oprirea acestuia de la nodul principal) în configurator și eliminați din suport. Pentru a face acest lucru, alegeți: Configurare - suport - ajustarea suportului.

În fereastra care se deschide, prima pornire a posibilității schimbării.

Și apoi scoateți configurația din suport.

Acum puteți descărca configurația din fișier, pentru a face acest lucru, selectați Configurare - Descărcați configurația din fișier și specificați nu ne transferați de la nodul central cf.-fişier. După aceasta, veți primi un avertisment că configurația curentă nu este goală. Vă rugăm să rețineți că manipularea pe care o faceți este potențial periculoasă și poate duce la deteriorări ireversibile la IB, deci înainte de a continua să vă asigurați că aveți o copie de rezervă relevantă.

Această eroare este tipică pentru. Eroare "Configurarea unui nod distribuit IB nu se potrivește cu cea așteptată" este sistemică. Practic apare din cauza unei finalizări de urgență a muncii în timpul schimbului de date privind URIB.

Este posibil să o rezolvați calea usoara. Ia in considerare.

Instrucțiune

1. Faceți copii ale bazelor de date care vor fi efectuate (în configuratorul de administrare - descărcați baza de informații).

2. Rulați configuratorul principal principal al nodului coastei.

3. Salvați configurația nodului central în fișierul de bază de date (Configurare - Salvați configurația într-un fișier ... ")

4. Deschideți configuratorul de bază al nodului subordonat.

Obțineți 267 Tutoriale video pentru 1C gratuit:

5. Scoateți configurația nodului subordonat cu suport (configurare - Suport - Setări suport - Eliminați din suport):

6. Încărcați configurația bazei de date ("Configurare - Descărcați o configurație din fișier ...").

8. După restructurare, este necesar să introduceți modul Enterprise și să setați nodul principal de configurare. Este posibil să faceți acest lucru cu ajutorul unei prelucrări speciale. Procesarea funcționează atât în \u200b\u200bmodul aplicație controlată, cât și în modul normal de aplicare.

9. În procesare, trebuie să selectați nodul principal și faceți clic pe "RUN":

10. Gata! Încercați să începeți schimbul, sistemul trebuie să schimbe corect.

Pentru a începe cu, aduc o listă de reduceri utilizate de mine:

• RIB - Baza de informare distribuită
• CB - Baza centrală, nod rădăcină
• UB - Baza de la distanță, baza de date a nervurilor nodului la distanță

De experiență proprie Pot spune că a trecut două motive pentru o eroare:

1. În timpul recepției fișierului de mesaje în baza UB "a căzut", în legătură cu care, aparent, a existat o dezinxline de conf. Banca Centrală și UB;
2. sub MSSQL, clientul a descărcat o copie a bazei de lucru și nu a dezactivat regulamentul în copie. Sarcinile Autobrack, ca rezultat, parte a mesajelor din noduri de la distanță a fost formată din baza de date de lucru și o parte a copiei, care a condus la configurația la distanță

Există, de asemenea, opinia că această eroare oferă utilizarea unui mecanism de actualizare dinamică. Există îndoieli aici, pentru că pe de o parte actualizare dinamică Nu afectează niciodată structura bazei de date, iar mecanismele nervoase lucrează exact cu structura bazei de date și nu cu partea sa aplicată, cu toate acestea, nervura este utilizată pentru a forma o versiune de configurare digitală a versiunii de configurare (în viitor O voi numi pentru a reduce hashe), iar schimbarea părții aplicate a hash este, în mod natural, obligată să recalculeze. Nu o voi nega și nici nu voi spune, pentru că Dacă am dat peste această situație, nu am găsit aceste dovezi.

Pentru corectare, folosesc 2 tehnici, în funcție de situație.

Prima tehnică

Primul (cel mai frecvent) este menționat în mod repetat în cadrul conferinței afiliate și pe alte resurse de Internet asociate cu 1c. Este folosit în majoritatea cazurilor atunci când, în ciuda mesajului despre configurații, atunci când este comparat manual, se eliberează că acestea sunt identice.

Secvențiere:

1. descărcați fișierul CF de la banca centrală;
2. asigurăm UB de la RIB (metoda de instalare a lanțului, prelucrarea recuperată poate fi găsită în apendice sau în alte publicații);
3. Înlocuiți conf. UB În fișierul CF descărcat în primul pas, pentru a face acest lucru, utilizați "Configurația de descărcare din fișierul" (și nu comparați-asociația !!!);
4. semne relative de coaste pentru UB.

În majoritatea cazurilor, aceste acțiuni sunt mai mult decât suficiente care restaurează schimbul, dar nu întotdeauna ...

A doua tehnică

Se folosește dacă prima tehnică nu a funcționat și nu este posibilă descărcarea din nou a nodului.

Preistoria: Clientul a avut o coaste cascada si eroarea a avut loc la primul nivel al scenei (al doilea nivel a lucrat in acest timp). Dezvoltarea configurației a fost efectuată împreună cu serviciul client IT și, din momentul în care apare eroarea, configurația CB a reușit să se schimbe de mai multe ori. O opțiune cu o reducere a modificărilor nu a fost considerată nici măcar în principiu, deoarece Pierderea părților de date și oprirea activității mai multor unități au fost complet inacceptabile. Prima versiune a corectării erorii oricăror rezultate tangibile nu a dat. În acest sens, ceea ce a trebuit să caute alte soluții.

Un gând a venit să încerce să înlocuiască fișierele de configurare HASHI direct în fișierele de schimb XML. Descrierea structurii fișierelor de partajare din cartea "Dezvoltarea profesională în 1C: Enterprise 8" a dat o idee slabă a formării semnături digitale Configurații și modificări ale acestora, dar au determinat direcția de căutare: digest1 și digest2 valori. Orice altceva a aflat un mod pur empiric (vreau să spun prin metoda eșantioanelor și erorilor), dar regularitatea este de a stabili același lucru.

Experimentele de testare au avut succes. Pe bazele de lucru, totul a mers bine.

Deci, secvența de acțiuni:

1. efectuați acțiunile 1 - 4 din prima tehnică;
2. descărcarea de la partajarea fișierelor UB, dar nu o încărcați în banca centrală;
3. descărcați de la banca centrală fișierul Exchange, dar nu îl încărcați în UB;
4. În dosarul de schimb de la banca centrală, înlocuim un bloc care conține informații despre modificările de configurare și Hashi (Digest1 și Digest2), pe blocul cache din fișierul UB (vezi exemplul de mai jos)
5. producem descărcarea fișierului din cel de-al patrulea punct din UB;
6. asigurați-vă că ați suprascrie fișierul de schimb de la UB (al doilea element)! Acest fișier nu ar trebui să fie descărcat atunci când se schimbă în banca centrală!
7. pentru verificare, facem câteva schimburi consecutive.

Dacă schimbul este utilizat pentru a comprima datele, apoi opriți comprimarea, fie pentru prima dată despachetați fișierul, schimbați, apoi suntem inversați înapoi și trimiteți.

Unitatea de partajare a fișierelor de la banca centrală

106.0
... Iată blocurile pentru descrierea schimbărilor de configurare ...
1CF680807E97A5DC0D1ED7F901B07392.
038211651CF680807E97A5DC0D1ED7F9.

trebuie să înlocuiți fișierul Exchange din UB (Notă Digest1 din fișierul de la UB este întotdeauna egal cu "0000000000000000000000000000" !!!)

106.0
00000000000000000000000000000000
11651CF680807E97A5DC0D1ED7F901B0.

Acțiunile enumerate trebuie să fie efectuate cu prudență marginală, secvența incorectă este plină de inoperabilitatea completă a coastei. Prin urmare, înainte de aceste acțiuni, creația backups. Fii sigur!

Pentru restul, pot să doresc doar noroc!

Pentru a începe cu, aduc o listă de reduceri utilizate de mine:

• RIB - Baza de informare distribuită
• CB - Baza centrală, nod rădăcină
• UB - Baza de la distanță, baza de date a nervurilor nodului la distanță

Potrivit propriului dvs. experiență, pot spune că am dat două motive pentru o eroare:

1. În timpul recepției fișierului de mesaje în baza UB "a căzut", în legătură cu care, aparent, a existat o dezinxline de conf. Banca Centrală și UB;
2. sub MSSQL, clientul a descărcat o copie a bazei de lucru și nu a dezactivat regulamentul în copie. Atribuțiile de autobracții, ca rezultat, o parte din mesajele către nodurile de la distanță au fost formate din baza de date de lucru și o parte a copiei, care a condus la conexiunea la configurație

Există, de asemenea, opinia că această eroare oferă utilizarea unui mecanism de actualizare dinamică. Există îndoieli aici, deoarece, pe de o parte, actualizarea dinamică nu afectează niciodată structura bazei de date, iar mecanismele nervoase funcționează exact cu structura bazei de date, și nu cu propria sa parte, cu toate acestea, nervura utilizează o semnătură digitală Mecanismul pentru versiunea de configurare (în i se va numi pentru a reduce hashe) și la schimbarea părții aplicate, hash este obligat în mod natural să recalculeze. Nu o voi nega și nici nu voi spune, pentru că Dacă am dat peste această situație, nu am găsit aceste dovezi.

Pentru corectare, folosesc 2 tehnici, în funcție de situație.

Prima tehnică

Primul (cel mai frecvent) este menționat în mod repetat în cadrul conferinței afiliate și pe alte resurse de Internet asociate cu 1c. Este folosit în majoritatea cazurilor atunci când, în ciuda mesajului despre configurații, atunci când este comparat manual, se eliberează că acestea sunt identice.

Secvențiere:

1. descărcați fișierul CF de la banca centrală;
2. asigurăm UB de la RIB (metoda de instalare a lanțului, prelucrarea recuperată poate fi găsită în apendice sau în alte publicații);
3. Înlocuiți conf. UB În fișierul CF descărcat în primul pas, pentru a face acest lucru, utilizați "Configurația de descărcare din fișierul" (și nu comparați-asociația !!!);
4. semne relative de coaste pentru UB.

În majoritatea cazurilor, aceste acțiuni sunt mai mult decât suficiente care restaurează schimbul, dar nu întotdeauna ...

A doua tehnică

Se folosește dacă prima tehnică nu a funcționat și nu este posibilă descărcarea din nou a nodului.

Preistoria: Clientul a avut o coaste cascada si eroarea a avut loc la primul nivel al scenei (al doilea nivel a lucrat in acest timp). Dezvoltarea configurației a fost efectuată împreună cu serviciul client IT și, din momentul în care apare eroarea, configurația CB a reușit să se schimbe de mai multe ori. O opțiune cu o reducere a modificărilor nu a fost considerată nici măcar în principiu, deoarece Pierderea părților de date și oprirea activității mai multor unități au fost complet inacceptabile. Prima versiune a corectării erorii oricăror rezultate tangibile nu a dat. În acest sens, ceea ce a trebuit să caute alte soluții.

Un gând a venit să încerce să înlocuiască fișierele de configurare HASHI direct în fișierele de schimb XML. Descrierea structurii fișierelor de partajare din cartea "Dezvoltarea profesională în sistemul 1C: Enterprise 8" a dat o înțelegere slabă a formării semnăturilor de configurare digitale și a modificărilor în ele, dar a determinat direcția de căutare: Digest1 și Digest2 Valorile. Orice altceva a aflat un mod pur empiric (vreau să spun prin metoda eșantioanelor și erorilor), dar regularitatea este de a stabili același lucru.

Experimentele de testare au avut succes. Pe bazele de lucru, totul a mers bine.

Deci, secvența de acțiuni:

1. efectuați acțiunile 1 - 4 din prima tehnică;
2. descărcarea de la partajarea fișierelor UB, dar nu o încărcați în banca centrală;
3. descărcați de la banca centrală fișierul Exchange, dar nu îl încărcați în UB;
4. În dosarul de schimb de la banca centrală, înlocuim un bloc care conține informații despre modificările de configurare și Hashi (Digest1 și Digest2), pe blocul cache din fișierul UB (vezi exemplul de mai jos)
5. producem descărcarea fișierului din cel de-al patrulea punct din UB;
6. asigurați-vă că ați suprascrie fișierul de schimb de la UB (al doilea element)! Acest fișier nu ar trebui să fie descărcat atunci când se schimbă în banca centrală!
7. pentru verificare, facem câteva schimburi consecutive.

Dacă schimbul este utilizat pentru a comprima datele, apoi opriți comprimarea, fie pentru prima dată despachetați fișierul, schimbați, apoi suntem inversați înapoi și trimiteți.

Unitatea de partajare a fișierelor de la banca centrală

106.0 ... Iată blocurile pentru descrierea schimbărilor de configurare ... 1CF680807E97A5DC0D1ED7F901B07392. 038211651CF680807E97A5DC0D1ED7F9.

trebuie să înlocuiți fișierul Exchange din UB (Notă Digest1 din fișierul de la UB este întotdeauna egal cu "0000000000000000000000000000" !!!)

106.0 00000000000000000000000000000000 11651CF680807E97A5DC0D1ED7F901B0.

Acțiunile enumerate trebuie să fie efectuate cu prudență marginală, secvența incorectă este plină de inoperabilitatea completă a coastei. Prin urmare, înainte de aceste acțiuni, este necesară crearea copiilor de backup!

Pentru restul, pot să doresc doar noroc!

• Fișierul de mesaje a fost deja încărcat în baza de date a receptorului. Este necesar să o descărcați din baza de date sursă.

Eroare "Eroare la copierea unui fișier cu resurse FTP ... Eroare de lucru pe Internet: Timeout a fost atins"

• De la site prin care schimbul trece, este imposibil să copiați fișierul dorit.. Se poate datora muncă lentă Internetul dvs. sau cu problemele site-ului în sine.
• Trebuie să încercați să repetați schimbul după 15-30 de minute.

Eroare "Editarea acestor perioade este interzisă. Modificările nu pot fi înregistrate ... "

• Datele descărcabile conțin documente dintr-o perioadă închisă.
• Este necesar să se schimbe în cadrul utilizatorilor care au dreptul de a modifica documentele în această perioadă.

Eroare "Trebuie să actualizați configurația bazei de date. Actualizare poate fi efectuată în modul Configurator »

Cauză: Programatorii au schimbat configurația în centru. Soluție: Actualizați configurația modificată în baza de date periferică. Pentru aceasta:

• Du-te la configurator.
• Rulați elementul de meniu "Configurator / Actualizare configurare a bazei de date".
• Dacă se emite o întrebare cu răspunsurile "repetați", "Anulare", "Actualizați Dynamic", faceți clic pe butonul "Actualizare dinamică".
• Dacă o întrebare este emisă numai cu răspunsuri "repetați" și "Anulare".
  • toți utilizatorii ies din 1C.
  • apăsați butonul "Repetare".
• Pentru întrebările rămase pentru a răspunde afirmativului: "Da", "Accept", "OK".
• Închideți configuratorul.
• Repetați descărcarea din centru.

Configurația de eroare "nu se potrivește cu încercarea de așteptat", "de a primi modificări dintr-o configurație necunoscută"

• Eroare în baza de date.
• Este necesar să se facă referire la specialiști.

Schimbul trece foarte mult, atârnă

Posibile motive:

• Există o mulțime de date.
  • Aflați de la expeditor, indiferent dacă a efectuat o schimbare de grup în documente (conducerea, înlocuirea de recuzită etc.).
  • Dacă da, lăsați un computer cu schimb de noapte.
• Un fișier mare nu poate fi plecat de pe Internet.
  • Dacă fișierul are o dimensiune mare (80-100 mb și mai mult), atunci poate că 1c pur și simplu nu o poate descărca.
  • Trebuie să descărcați fișierul și să îl descărcați în 1C manual (poate cu ajutorul specialiștilor).
    • element de meniu de operații / Planuri de schimb / Full / buton pe panoul "Citire mesaj".
• Baza este deteriorată:
  • Încerca
• Dacă aceste acțiuni nu au ajutat - va trebui să vă referiți la specialiștii în domeniu.

• Dacă nu ați reușit să corectați eroarea, apelați la asistență de urgență +7 (8512) 64-55-05.
• Specialistul nostru vă va ajuta în nici un oraș nu sunteți.