1C distribuovaná zmena konfigurácie IB. Aby sa zabránilo problémom, ktoré sa nazývajú túto chybu, odporúča sa neuskutočniť dynamickú aktualizáciu (aspoň niekoľkokrát v rade - pred stiahnutím zmien na vetvy), a tiež výhodne v nastaveniach po výmene

Distribuovaná informačná základňa (rebro) sa často používa na organizovanie práce pobočiek a jednotiek, čo vám umožní rýchlo vymieňať informácie, pri zachovaní požadovaného stupňa autonómie. Hoci táto technológia Je to celkom spoľahlivé, z času na čas sa rozbije. Dnes sa pozrieme na jednu z pomerne bežných chýb: O dôvodoch jeho výskytu a metód boja proti nemu.

Začnime, ako vždy, od začiatku. Potom, čo ste vytvorili rebro všetky zmeny v konfigurácii informačná základňa môže byť vyrobený len v hlavnom uzle. Následne, s ďalšou výmenou, všetky zmeny budú prenesené na podriadené uzly a sú automaticky použité. Ale bol hladký na papieri ...

V praxi sa niekedy stáva, že medzi výmennými sedeniami, najmä ak na periférii je zlé s kanálom, hlavná konfigurácia uzla má čas na zmenu dvakrát. Napríklad vykonané zmeny, vyložené, prijaté periférne databázy, ale ešte ich neuplatňovali, čo by mohlo chvíľu trvať, a potvrdenie ešte nebol odoslané. Ak počas tejto medzery vykonáte zmeny a znova vyložte výmenu, zobrazí sa, že centrum očakáva, že zobrazí konfiguračné číslo 1 v periférnom uzle a pokúsi sa ho aktualizovať na konfiguráciu č. 3 a v skutočnosti bude čeliť Konfigurácia č. 2. Niekedy sa táto situácia vyskytuje, keď je centrálna základňa dynamická. Výsledkom je, že výmena bude nemožná, a dostanete správu Konfigurácia distribuovaného uzla IB nezodpovedá očakávanému!

Všeobecne platí, že morálka tohto príbehu je jednoduchá - aktívne nevykonávajte pracovnú databázu, a ak vediete, dokončite všetky výmeny pred vykonaním nasledujúcich zmien. Ale ako sa tak stalo takéto problémy?

Riešenie "v čele" je vytvoriť nový obraz podriadeného uzla, ale v praxi zvyčajne nie je použiteľné. Spravidla, vznik vážnej chyby v oblasti výmeny nie je okamžite opravená, ale po určitom čase po určitom čase po operačných údajoch z periférnych základov zastavila. V závislosti od výmenného harmonogramu medzi okamihom výskytu problému a jeho detekciou je možné konať celý pracovný deň, alebo ešte viac.

Tu stojí za to hádzať kameň v záhrade vývojárov, ktorí rozdávajú ako chybu a len zdôrazňujú červenú situáciu Číslo správy je menšie alebo rovné číslo predtým prijatémučo je všeobecne celkom normálne. Ako výsledok, užívatelia, vnímanie chýb je vypustený, a jednoducho prestanú čítať zobrazené správy, veriť, že všetko je v poriadku a len ďalšia strana ešte neuskutočnila výmenu samotnej.

Ale späť k našej chybe. Riešenie je pomerne jednoduché a leží na povrchu: priviesť konfiguráciu periférnej základne k očakávanému, t.j. Priveďte ho do riadku s konfiguráciou centrálneho uzla. Ale v praxi to nie je také jednoduché. Ak otvoríme periférnu základňu v konfigurátore, uvidíme, že zmeny sú blokované rebrami.

Ak chcete zmeniť konfiguráciu podriadeného uzla, bude potrebné dočasne vypnúť z centrálnej základne. Na tieto účely môžete použiť jednu z procedúr, ktoré sú prezentované v sieti, alebo vypnúť IB z centrálneho uzla používanie parametra štartovacieho konfigurátora/ Resetmasternode..

Otvorte príkazový riadok a zadajte (berúc do úvahy verziu platformy a reálnu inštalačnú cestu):

"C: Programové súbory (x86) \\ _CV8.exe" Config / resetmasternode

Po vykonaní tohto príkazu sa zobrazí pravidelné okno štartéra, vyberte požadovanú databázu a kliknite na tlačidlo Etifurátor.

Spustiť IB v rovnakom čase sa nestane. Môže sa zdať, že sa nič nestalo, ale opätovným otvorením databázy v konfigurátori sa môžete uistiť, že je to zakázané z hlavného uzla a je k dispozícii na vykonanie zmien.

Pozor! Na platformách 8.3.7 - 8.3.9 Vykonávanie tohto príkazu vedie k núdzovému ukončeniu práce. Chyba je upevnená v platforme 8.3.10.

Ak nechcete, aby ste sa s ním príkazový riadokMôžete použiť jednu z procedúr, ten, ktorý je uvedený nižšie, na ktorom sa používame, bol nájdený na disku siete a zadali sme to len kozmetické úpravy. POZNÁMKA, Spracovanie je vhodné len pre pravidelnú aplikáciu, pre konfigurácie na spravovanej aplikácii, použite tlačidlo Štart Configurator.

Práca s ním je mimoriadne jednoduchý, spustiť ho v režime 1C: podniky, cez Súbor - otvorenýPotom stačí stlačiť požadované tlačidlo v našom prípade Vypnite hlavný uzol.

Teraz potrebujeme aktuálnu konfiguráciu z centrálneho uzla. Urobiť to, otvorené centrálna IB v konfigurátore a vykonajte Konfigurácia - Uloženie konfigurácie do súboru. Výsledný súbor s rozšírením cF. Bude potrebné preniesť na periférny uzol.

Potom v periférnom uzle spustite IB (po vypnutí z hlavného uzla) v konfigurátore a vyberte ho z podpory. Na tento účel si vyberte: Konfigurácia - Podpora - Nastavenie podpory.

V okne, ktoré sa otvorí, najprv zapnite možnosť zmeny.

A potom odstráňte konfiguráciu z podpory.

Teraz si môžete stiahnuť konfiguráciu zo súboru, aby ste to mohli urobiť, vyberte položku Konfigurácia - Prevzatie konfigurácie zo súboru a špecifikujte nie sú prenesené z centrálneho uzla cF.-File. Potom dostanete varovanie, že aktuálna konfigurácia nie je prázdna. Upozorňujeme, že manipulácia, ktorú robíte, je potenciálne nebezpečné a môže viesť k ireverzibilnému poškodeniu IB, takže predtým, ako sa uistite, že máte relevantnú zálohu.

Táto chyba je typická. Chyba "Konfigurácia uzla distribuovanej IB nezodpovedá očakávanému" je systémové. V podstate vzniká v dôsledku núdzového ukončenia práce počas výmeny údajov o URIB.

Je možné ho vyriešiť jednoduchý spôsob. Zvážiť to.

Výučba

1. Urobte kópie databáz, ktoré budú vykonané práce (v konfigurátore administrácie - Unit Information Base).

2. Spustite hlavnú základňu konfigurátora rebierového uzla.

3. Uložte konfiguráciu centrálneho uzla do databázového súboru ("Konfigurácia - Uložiť konfiguráciu do súboru ...")

4. Otvorte konfigurátor podriadeného základného uzla.

Získajte 267 video tutoriály pre 1c zadarmo:

5. Odstráňte konfiguráciu podriadeného uzla pomocou podpory (Konfigurácia - Nastavenia podpory - Podpora - Odstrániť z podpory):

6. Vložte konfiguráciu databázy ("Konfigurácia - Stiahnite si konfiguráciu zo súboru ...").

8. Po reštrukturalizácii je potrebné zadať režim Enterprise a nastavte hlavnú konfiguračnú uzol. Je možné to urobiť s pomocou špeciálneho spracovania. Spracovanie funguje v režime riadenej aplikácie a v normálnom režime aplikácie.

9. Pri spracovaní musíte vybrať hlavný uzol a kliknite na tlačidlo "RUN":

10. Pripravené! Skúste začať výmenu, systém musí správne výmenu.

Začať, prinášam zoznam redukcií používaných:

• Rebro - distribuovaná informačná základňa
• CB - Centrálna základňa, rebrový koreňový uzol
• UB - Remote Base, Databáza rebra z diaľkového uzla

Za zážitok Môžem povedať, že to narazilo na dva dôvody chyby:

1. počas prijímania súboru správy v UB "padol" základňu, v súvislosti s ktorým, zrejme, bol dezinxclínu z CONT. Centrálna banka a UB;
2. podľa MSSQL, klient si stiahol kópiu pracovnej základne a nevypínala reguláciu v kópii. Autobarcové úlohy, ako výsledok, časť správ v diaľkové uzly bola vytvorená z pracovnej databázy a časti kópie, ktorá viedla k konfigurácii vzdialenosti

Tam je tiež názor, že táto chyba poskytuje použitie dynamického mechanizmu aktualizácie. Tam sú pochybnosti, pretože na jednej strane dynamická aktualizácia Nikdy neovplyvňuje štruktúru databázy a mechanizmy rebrá stále pracujú presne so štruktúrou databázy, a nie s aplikovanou časťou, rebro sa používa na vytvorenie digitálnej konfiguračnej verzie verzie konfigurácie (v budúcnosti) Zavolám ho na zníženie Hashe) a zmena v aplikovanej časti hash je prirodzene povinná prepočítať. Nebudem to popierať ani povedať, pretože Ak som narazil do tejto situácie, nenašiel som tento dôkaz.

Na korekciu používam 2 techniky v závislosti od situácie.

Prvá technika

Prvý (najčastejšie) sa opakovane spomína v affiliate konferencii a na iných internetových zdrojoch súvisiacich s 1C. Vo väčšine prípadov sa používa, keď napriek posolstvu o konfiguráciách, keď sa v porovnaní ručne porovnáva, je vydaná, že sú identické.

Sekvenovanie:

1. vyložiť súbor CF z centrálnej banky;
2. sme Asslaunt UB z rebra (spôsob inštalácie reťazca, hotové spracovanie možno nájsť v prílohe alebo v iných publikáciách);
3. nahradiť CONF. UB na súbor CF vyložených v prvom kroku, aby ste to urobili, použite "Prevziať konfiguráciu zo súboru" menu (a nie porovnanie-asociácie !!!);
4. relatívne príznaky rebra pre UB.

Vo väčšine prípadov sú tieto akcie viac než dosť, ktoré obnovujú výmenu, ale nie vždy ...

Druhá technika

Používa sa, ak prvá technika nefungovala, a nie je možné znova vyložiť uzol.

Prehistória: Klient mal kaskádové rebro a chyba sa vyskytla v prvej úrovni javiska (druhá úroveň po celý čas pracoval bezchybne). Vývoj konfigurácie bol vykonaný v spojení s službou IT klientom a od okamihu, keď sa vyskytne chyba, konfigurácia CB sa podarilo niekoľkokrát zmeniť. Možnosť s návratom zmien nebola považovaná v zásade aj v zásade, pretože Strata dátových dielov a zastavenie práce viacerých jednotiek boli úplne neprijateľné. Prvá verzia korekcie chyby akýchkoľvek hmatateľných výsledkov nedávala. V tejto súvislosti, čo muselo hľadať iné riešenia.

Myšlienka sa pokúsi nahradiť konfiguračné súbory Hashi priamo v XML Exchange Files. Popis štruktúry zdieľania Štruktúra z knihy "Profesionálny rozvoj v 1C: Enterprise 8" dal slabú predstavu o formácii digitálne podpisy Konfigurácie a zmeny v nich, ale určené Smer vyhľadávania: DIGEST1 a hodnoty DIGEST2. Všetko ostatné zistilo, že je to čisto empirický spôsob (myslím týmto spôsobom vzoriek a chýb), ale pravidelnosťou je vytvoriť to isté.

Skúšobné experimenty boli úspešné. Aj na pracovných základoch, všetko šlo dobre.

Takže postupnosť akcií:

1. vykonávať akcie 1 - 4 prvej techniky;
2. vykladanie z zdieľania súborov UB, ale nenačítajte ho do centrálnej banky;
3. vyložiť z centrálnej banky výmenný súbor, ale nenačítajte ho do UB;
4. v súbore Exchange od centrálnej banky nahradíme blok obsahujúci informácie o konfiguračných zmenách a Hashi (Digest1 a DIGEST2), na bloku vyrovnávacej pamäte zo súboru UB (pozri príklad nižšie)
5. vyrábame súbor na stiahnutie zo 4. bodu v UB;
6. uistite sa, že ste prepísali Exchange File z UB (2. položku)! Tento súbor by sa nemal stiahnuť pri výmene v centrálnej banke!
7. na overenie robíme niekoľko po sebe idúcich výmen.

Ak sa výmena používa na kompresiu údajov, potom vypnite kompresiu, alebo najprv rozbaľte súbor, zmeňte sa, potom sme obrátené späť a posielame.

Zdieľanie súborov z centrálnej banky

106.0
... Tu sú bloky na opis zmien konfigurácie ...
1CF680807E97A5DC0D1ED7F901B07392.
038211651CF680807E97A5DC0D1ED7F9.

musíte vymeniť Exchange súbor z UB (poznamenajte si Digest1 zo súboru z UB je vždy rovný "000000000000000000000000000000" !!!

106.0
00000000000000000000000000000000
11651CF680807E97A5DC0D1ED7F901B0.

Uvedené akcie sa musia vykonať s okrajovou opatrnosťou, nesprávna sekvencia je plná úplnej nefunkviteľnosti rebier. Preto, pred týmito činmi, vytvorenie zálohovanie Buď si istý!

Pre zvyšok, môžem len želám veľa šťastia!

Začať, prinášam zoznam redukcií používaných:

• Rebro - distribuovaná informačná základňa
• CB - Centrálna základňa, rebrový koreňový uzol
• UB - Remote Base, Databáza rebra z diaľkového uzla

Podľa vlastnej skúsenosti môžem povedať, že som prišiel z dvoch dôvodov pre chybu:

1. počas prijímania súboru správy v UB "padol" základňu, v súvislosti s ktorým, zrejme, bol dezinxclínu z CONT. Centrálna banka a UB;
2. podľa MSSQL, klient si stiahol kópiu pracovnej základne a nevypínala reguláciu v kópii. Priradenia autobakcií, ako výsledok, časť správ na vzdialených uzloch bola vytvorená z pracovnej databázy a časti kópie, ktorá viedla k pripojeniu k konfigurácii

Tam je tiež názor, že táto chyba poskytuje použitie dynamického mechanizmu aktualizácie. Tam sú pochybnosti, pretože na jednej strane dynamická aktualizácia nikdy neovplyvňuje štruktúru databázy a mechanizmy rebrá stále pracujú presne s databázou štruktúrou, a nie s vlastnou časťou, rebro používa digitálny podpis Mechanizmus pre konfiguračnú verziu (v I bude nazývaná na zníženie Hashe), a pri zmene aplikovanej časti je hash prirodzene povinný prepočítať. Nebudem to popierať ani povedať, pretože Ak som narazil do tejto situácie, nenašiel som tento dôkaz.

Na korekciu používam 2 techniky v závislosti od situácie.

Prvá technika

Prvý (najčastejšie) sa opakovane spomína v affiliate konferencii a na iných internetových zdrojoch súvisiacich s 1C. Vo väčšine prípadov sa používa, keď napriek posolstvu o konfiguráciách, keď sa v porovnaní ručne porovnáva, je vydaná, že sú identické.

Sekvenovanie:

1. vyložiť súbor CF z centrálnej banky;
2. sme Asslaunt UB z rebra (spôsob inštalácie reťazca, hotové spracovanie možno nájsť v prílohe alebo v iných publikáciách);
3. nahradiť CONF. UB na súbor CF vyložených v prvom kroku, aby ste to urobili, použite "Prevziať konfiguráciu zo súboru" menu (a nie porovnanie-asociácie !!!);
4. relatívne príznaky rebra pre UB.

Vo väčšine prípadov sú tieto akcie viac než dosť, ktoré obnovujú výmenu, ale nie vždy ...

Druhá technika

Používa sa, ak prvá technika nefungovala, a nie je možné znova vyložiť uzol.

Prehistória: Klient mal kaskádové rebro a chyba sa vyskytla v prvej úrovni javiska (druhá úroveň po celý čas pracoval bezchybne). Vývoj konfigurácie bol vykonaný v spojení s službou IT klientom a od okamihu, keď sa vyskytne chyba, konfigurácia CB sa podarilo niekoľkokrát zmeniť. Možnosť s návratom zmien nebola považovaná v zásade aj v zásade, pretože Strata dátových dielov a zastavenie práce viacerých jednotiek boli úplne neprijateľné. Prvá verzia korekcie chyby akýchkoľvek hmatateľných výsledkov nedávala. V tejto súvislosti, čo muselo hľadať iné riešenia.

Myšlienka sa pokúsi nahradiť konfiguračné súbory Hashi priamo v XML Exchange Files. Opis štruktúry zdieľania zo štruktúry zdieľania z knihy "Profesionálny rozvoj v systéme 1c: Enterprise 8" poskytol slabé pochopenie tvorby digitálnych konfiguračných podpisov a zmien v nich, ale určil smer vyhľadávania: DIGEST1 a DIGEST2 Hodnoty. Všetko ostatné zistilo, že je to čisto empirický spôsob (myslím týmto spôsobom vzoriek a chýb), ale pravidelnosťou je vytvoriť to isté.

Skúšobné experimenty boli úspešné. Aj na pracovných základoch, všetko šlo dobre.

Takže postupnosť akcií:

1. vykonávať akcie 1 - 4 prvej techniky;
2. vykladanie z zdieľania súborov UB, ale nenačítajte ho do centrálnej banky;
3. vyložiť z centrálnej banky výmenný súbor, ale nenačítajte ho do UB;
4. v súbore Exchange od centrálnej banky nahradíme blok obsahujúci informácie o konfiguračných zmenách a Hashi (Digest1 a DIGEST2), na bloku vyrovnávacej pamäte zo súboru UB (pozri príklad nižšie)
5. vyrábame súbor na stiahnutie zo 4. bodu v UB;
6. uistite sa, že ste prepísali Exchange File z UB (2. položku)! Tento súbor by sa nemal stiahnuť pri výmene v centrálnej banke!
7. na overenie robíme niekoľko po sebe idúcich výmen.

Ak sa výmena používa na kompresiu údajov, potom vypnite kompresiu, alebo najprv rozbaľte súbor, zmeňte sa, potom sme obrátené späť a posielame.

Zdieľanie súborov z centrálnej banky

106.0 ... Tu sú bloky na opis zmien konfigurácie ... 1CF680807E97A5DC0D1ED7F901B07392. 038211651CF680807E97A5DC0D1ED7F9.

musíte vymeniť Exchange súbor z UB (poznamenajte si Digest1 zo súboru z UB je vždy rovný "000000000000000000000000000000" !!!

106.0 00000000000000000000000000000000 11651CF680807E97A5DC0D1ED7F901B0.

Uvedené akcie sa musia vykonať s okrajovou opatrnosťou, nesprávna sekvencia je plná úplnej nefunkviteľnosti rebier. Preto sa pred týmito akciami vyžaduje vytvorenie záložných kópií!

Pre zvyšok, môžem len želám veľa šťastia!

• Súbor správy sa už vložil do databázy prijímača. Je potrebné ho vyložiť zo zdrojovej databázy.

Chyba "Chyba pri kopírovaní súboru s ftp zdrojom ... Internet Work Chyba: Timeout bol dosiahnutý"

• Z miesta, prostredníctvom ktorého výmena prechádza, nie je možné kopírovať požadovaný súbor.. Môže to byť spôsobené pomalé práce Váš internet alebo s problémami samotnej stránky.
• Musíte sa pokúsiť zopakovať výmenu po 15-30 minútach.

Chyba "Úprava týchto období je zakázané. Zmeny nie je možné zaznamenať ... "

• Stiahnuteľné údaje obsahuje dokumenty z uzavretého obdobia.
• Je potrebné vymieňať si užívateľov, ktorí majú právo zmeniť dokumenty v tomto období.

Chyba "Musíte aktualizovať konfiguráciu databázy. Aktualizácia je možné vykonať v režime Konfigurátor »

Príčina: Programátori zmenili konfiguráciu v strede. Riešenie: Aktualizujte upravenú konfiguráciu v periférnej databáze. Pre to:

• Prejdite do konfigurátora.
• Spustite položku menu "Konfigurácia databázy / aktualizácie".
• Ak je otázka vydaná len s odpoveďami "REPEAT", "CANCEL", "UPDATE DYNAMIC", kliknite na tlačidlo "Update Dynamic".
• Ak je otázka vydaná odpoveďou len "REPEAT" a "CANCEL".
  • všetci používatelia sa dostanú z 1c.
  • stlačte tlačidlo "REPEAPY".
• Pre zostávajúce otázky odpovedať na kladnosť: "Áno," "Accept", "OK".
• Zatvorte konfigurátor.
• Opakovanie stiahnutia z centra.

Chyba "Konfigurácia nezodpovedá očakávanému", "pokus o prijatie zmien z neznámej konfigurácie"

• Chyba v databáze.
• Je potrebné odkazovať na špecialistov.

Výmena prechádza veľmi dlhé, visí

Možní dôvody:

• Existuje veľa údajov.
  • Zistili sa od odosielateľa, či už vykonal skupinovú zmenu dokumentov (vedenie, výmena rekvizín atď.).
  • Ak áno, nechajte počítač s výmenou za noc.
• Veľký súbor nemožno prejsť z internetu.
  • Ak má súbor veľkú veľkosť (80-100 MB a viac), potom možno 1C jednoducho si ho nedokáže stiahnuť.
  • Musíte si stiahnuť súbor a stiahnuť ho v 1C manuálne (možno s pomocou špecialistov).
    • operations Menu Položka / výmena plánov / plné / tlačidlo na paneli "Prečítajte si správu".
• Základňa je poškodená:
  • Vyskúšať
• Ak tieto akcie nepomohli - budete musieť odkazovať na odborníkov v odbore.

• Ak sa vám nepodarilo opraviť chybu, zavolajte na núdzovú podporu +7 (8512) 64-55-05.
• Náš špecialista vám pomôže v každom meste, ktoré nie ste.