Pirma, naudojamų santrumpų sąrašas:
- RIB – paskirstyta informacinė bazė
- CB - centrinė bazė, šakninis RIB mazgas
- UB - nuotolinė bazė, nuotolinio RIB mazgo duomenų bazė
Iš savo patirties galiu pasakyti, kad susidūriau su dviem klaidos priežastimis:
- Gaunant pranešimo failą duomenų bazė „nukrito“ valdymo sistemoje, todėl, matyt, įvyko desinchronizacija tarp konf. Centrinis bankas ir UB;
- pagal MSSQL klientas atsisiuntė veikiančios duomenų bazės kopiją ir neišjungė reg. automatinio apsikeitimo užduotys, todėl kai kurie pranešimai nuotoliniams mazgams buvo generuojami iš veikiančios duomenų bazės, o kai kurie iš kopijos, dėl ko buvo desinchronizuojamos konfigūracijos
Taip pat yra nuomonė, kad šią klaidą sukelia dinaminio duomenų bazės atnaujinimo mechanizmo naudojimas. Čia kyla abejonių, nes, viena vertus, dinaminis atnaujinimas niekada nepaveikia duomenų bazės struktūros, bet RIB mechanizmai juk jie dirba būtent su duomenų bazės struktūra, o ne su jos taikoma dalimi, vis dėlto RIB naudoja generavimo mechanizmą Elektroninis parašas konfigūracijos versiją (ateityje trumpai vadinsiu maišą), o pasikeitus programos daliai, maišą natūraliai reikia perskaičiuoti. Aš to nei neigsiu, nei patvirtinsiu, nes... Jei susidūriau su tokia situacija, neradau jokių aiškių įrodymų.
Norėdami tai ištaisyti, naudoju 2 būdus, priklausomai nuo situacijos.
PIRMOJI TECHNIKA
Pirmasis (labiausiai paplitęs) ne kartą minimas tiek partnerių konferencijoje, tiek kituose interneto šaltiniuose, susijusiuose su 1C. Jis naudojamas daugeliu atvejų, kai, nepaisant pranešimo apie konfigūracijų neatitikimus, rankinis palyginimas rodo, kad jie yra identiški.
Seka:
- iškelti cf failą iš centrinio banko;
- atsiejame UB nuo RIB (metodas Set MainNode, paruoštą apdorojimą galima rasti programoje ar kituose leidiniuose);
- pakeičiant konf. UB į pirmame žingsnyje įkeltą cf failą, tam naudojame meniu „Įkelti konfigūraciją iš failo“ (o ne palyginimas-sujungimas!!!);
- Atkurkime RIB ženklą UX.
Daugeliu atvejų šių veiksmų pakanka mainams atkurti, tačiau ne visada...
ANTRAS METODAS
Jis naudojamas, jei pirmasis metodas nepasiteisino ir mazgo iš naujo iškrauti neįmanoma.
Fonas: klientas kūrė kaskadinį RIB ir pirmame kaskados lygyje įvyko klaida (antrasis lygis visą tą laiką veikė nepriekaištingai). Konfigūracija buvo sukurta kartu su kliento IT tarnyba, o nuo tada, kai įvyko klaida, centrinio banko konfigūracija keitėsi keletą kartų. Pakeitimų atšaukimo galimybė net iš esmės nebuvo svarstoma, nes kai kurių duomenų praradimas ir kelių skyrių uždarymas buvo visiškai nepriimtinas. Pirmasis klaidos ištaisymo variantas nedavė jokių apčiuopiamų rezultatų. Todėl teko ieškoti kitų sprendimų.
Kilo mintis pabandyti pakeisti konfigūracijos failų maišą tiesiai į XML mainų failus. Keitimosi failo struktūros aprašymas iš knygos „Profesionalus tobulėjimas sistemoje 1C:Enterprise 8“ davė silpną idėją apie konfigūracijų skaitmeninių parašų formavimąsi ir jų pakeitimus, tačiau nulėmė konfigūracijos kryptį. paieška: Digest1 ir Digest2 reikšmės. Visa kita išsiaiškinau grynai empiriškai (ty bandymų ir klaidų būdu), bet buvo įmanoma nustatyti modelį.
Bandomieji eksperimentai buvo sėkmingi. Darbo bazėse taip pat viskas sekėsi puikiai.
Taigi, veiksmų seka:
- atlikite pirmojo metodo 1–4 veiksmus;
- Keitimo failą iškrauname iš UB, bet neįkeliame į centrinį banką;
- Keitimo failą iškrauname iš Centrinio banko, bet neįkeliame į UB;
- mainų faile iš centrinio banko pakeičiame bloką, kuriame yra informacija apie konfigūracijos pakeitimus ir maišą (Digest1 ir Digest2), maišos bloku iš UB failo (žr. toliau pateiktą pavyzdį)
- Failą įkeliame iš 4 taško į UB;
- Būtinai perrašykite mainų failą iš UB (2 taškas)! Keičiant su Centriniu banku šis failas neturėtų būti atsisiunčiamas!
- Norėdami patikrinti, atliekame kelis mainus iš eilės.
Jei mainų metu naudojamas duomenų suspaudimas, tada arba išjungiame glaudinimą, arba pirmiausia išpakuojame failą, pakeičiame, tada supakuojame atgal ir išsiunčiame.
Keisti failų bloką iš centrinio banko
...čia yra blokai, apibūdinantys konfigūracijos pakeitimus...
reikia pakeisti mainų failo bloku iš UB (atminkite, kad UB failo Digest1 visada yra lygus "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"!!!)
Išvardyti veiksmai turi būti atliekami labai atsargiai, nes neteisinga seka gali sukelti visišką RIB neveikimą. Todėl prieš šiuos veiksmus sukurkite atsargines kopijas BŪTINAI!
Pirma, čia yra mano naudojamų santrumpų sąrašas:
- RIB – paskirstyta informacinė bazė
- CB - centrinė bazė, šakninis RIB mazgas
- UB - nuotolinė bazė, nuotolinio RIB mazgo duomenų bazė
Iš savo patirties galiu pasakyti, kad susidūriau su dviem klaidos priežastimis:
- Gaunant pranešimo failą duomenų bazė „nukrito“ valdymo sistemoje, todėl, matyt, įvyko desinchronizacija tarp konf. Centrinis bankas ir UB;
- pagal MSSQL klientas atsisiuntė veikiančios duomenų bazės kopiją ir neišjungė reg. automatinio apsikeitimo užduotys, todėl kai kurie pranešimai nuotoliniams mazgams buvo generuojami iš veikiančios duomenų bazės, o kai kurie iš kopijos, dėl ko buvo desinchronizuojamos konfigūracijos
Taip pat yra nuomonė, kad šią klaidą sukelia dinaminio duomenų bazės atnaujinimo mechanizmo naudojimas. Čia kyla abejonių, nes, viena vertus, dinaminis atnaujinimas niekada neveikia duomenų bazės struktūros, o RIB mechanizmai vis tiek veikia su duomenų bazės struktūra, o ne su jos taikoma dalimi, tačiau RIB naudoja skaitmeninio parašo generavimo mechanizmą. konfigūracijos versija (ateityje trumpai vadinsiu maišą), o pasikeitus programos daliai, maišą natūraliai reikia perskaičiuoti. Aš to nei neigsiu, nei patvirtinsiu, nes... Jei susidūriau su tokia situacija, neradau jokių aiškių įrodymų.
Norėdami tai ištaisyti, naudoju 2 būdus, priklausomai nuo situacijos.
PIRMOJI TECHNIKA
Pirmasis (labiausiai paplitęs) ne kartą minimas tiek partnerių konferencijoje, tiek kituose interneto šaltiniuose, susijusiuose su 1C. Jis naudojamas daugeliu atvejų, kai, nepaisant pranešimo apie konfigūracijų neatitikimus, rankinis palyginimas rodo, kad jie yra identiški.
Seka:
- iškelti cf failą iš centrinio banko;
- atsiejame UB nuo RIB (metodas Set MainNode, paruoštą apdorojimą galima rasti programoje ar kituose leidiniuose);
- pakeičiant konf. UB į pirmame žingsnyje įkeltą cf failą, tam naudojame meniu „Įkelti konfigūraciją iš failo“ (o ne palyginimas-sujungimas!!!);
- Atkurkime RIB ženklą UX.
Daugeliu atvejų šių veiksmų pakanka mainams atkurti, tačiau ne visada...
ANTRAS METODAS
Jis naudojamas, jei pirmasis metodas nepasiteisino ir mazgo iš naujo iškrauti neįmanoma.
Fonas: klientas kūrė kaskadinį RIB ir pirmame kaskados lygyje įvyko klaida (antrasis lygis visą tą laiką veikė nepriekaištingai). Konfigūracija buvo sukurta kartu su kliento IT tarnyba, o nuo tada, kai įvyko klaida, centrinio banko konfigūracija keitėsi keletą kartų. Pakeitimų atšaukimo galimybė net iš esmės nebuvo svarstoma, nes kai kurių duomenų praradimas ir kelių skyrių uždarymas buvo visiškai nepriimtinas. Pirmasis klaidos ištaisymo variantas nedavė jokių apčiuopiamų rezultatų. Todėl teko ieškoti kitų sprendimų.
Kilo mintis pabandyti pakeisti konfigūracijos failų maišą tiesiai į XML mainų failus. Keitimosi failo struktūros aprašymas iš knygos „Profesionalus tobulėjimas sistemoje 1C:Enterprise 8“ davė silpną idėją apie konfigūracijų skaitmeninių parašų formavimąsi ir jų pakeitimus, tačiau nulėmė konfigūracijos kryptį. paieška: Digest1 ir Digest2 reikšmės. Visa kita išsiaiškinau grynai empiriškai (ty bandymų ir klaidų būdu), bet buvo įmanoma nustatyti modelį.
Bandomieji eksperimentai buvo sėkmingi. Darbo bazėse taip pat viskas sekėsi puikiai.
Taigi, veiksmų seka:
- atlikite pirmojo metodo 1–4 veiksmus;
- Keitimo failą iškrauname iš UB, bet neįkeliame į centrinį banką;
- Keitimo failą iškrauname iš Centrinio banko, bet neįkeliame į UB;
- mainų faile iš centrinio banko pakeičiame bloką, kuriame yra informacija apie konfigūracijos pakeitimus ir maišą (Digest1 ir Digest2), maišos bloku iš UB failo (žr. toliau pateiktą pavyzdį)
- Failą įkeliame iš 4 taško į UB;
- Būtinai perrašykite mainų failą iš UB (2 taškas)! Keičiant su Centriniu banku šis failas neturėtų būti atsisiunčiamas!
- Norėdami patikrinti, atliekame kelis mainus iš eilės.
Jei mainų metu naudojamas duomenų suspaudimas, tada arba išjungiame glaudinimą, arba pirmiausia išpakuojame failą, pakeičiame, tada supakuojame atgal ir išsiunčiame.
Keisti failų bloką iš centrinio banko
...čia yra blokai, apibūdinantys konfigūracijos pakeitimus...
reikia pakeisti mainų failo bloku iš UB (atminkite, kad UB failo Digest1 visada yra lygus "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"!!!)
Išvardyti veiksmai turi būti atliekami labai atsargiai, nes neteisinga seka gali sukelti visišką RIB neveikimą. Todėl prieš šiuos veiksmus atsarginių kopijų kūrimas PRIVALOMA!
Dėl kitų galiu tik palinkėti sėkmės!
Pirma, čia yra mano naudojamų santrumpų sąrašas:
- RIB – paskirstyta informacinė bazė
- CB - centrinė bazė, šakninis RIB mazgas
- UB - nuotolinė bazė, nuotolinio RIB mazgo duomenų bazė
Iš savo patirties galiu pasakyti, kad susidūriau su dviem klaidos priežastimis:
- Gaunant pranešimo failą duomenų bazė „nukrito“ valdymo sistemoje, todėl, matyt, įvyko desinchronizacija tarp konf. Centrinis bankas ir UB;
- pagal MSSQL klientas atsisiuntė veikiančios duomenų bazės kopiją ir neišjungė reg. automatinio apsikeitimo užduotys, todėl kai kurie pranešimai nuotoliniams mazgams buvo generuojami iš veikiančios duomenų bazės, o kai kurie iš kopijos, dėl ko buvo desinchronizuojamos konfigūracijos
Taip pat yra nuomonė, kad šią klaidą sukelia dinaminio duomenų bazės atnaujinimo mechanizmo naudojimas. Čia kyla abejonių, nes, viena vertus, dinaminis atnaujinimas niekada neveikia duomenų bazės struktūros, o RIB mechanizmai vis tiek veikia su duomenų bazės struktūra, o ne su jos taikoma dalimi, tačiau RIB naudoja skaitmeninio parašo generavimo mechanizmą. konfigūracijos versija (ateityje trumpai vadinsiu maišą), o pasikeitus programos daliai, maišą natūraliai reikia perskaičiuoti. Aš to nei neigsiu, nei patvirtinsiu, nes... Jei susidūriau su tokia situacija, neradau jokių aiškių įrodymų.
Norėdami tai ištaisyti, naudoju 2 būdus, priklausomai nuo situacijos.
PIRMOJI TECHNIKA
Pirmasis (labiausiai paplitęs) ne kartą minimas tiek partnerių konferencijoje, tiek kituose interneto šaltiniuose, susijusiuose su 1C. Jis naudojamas daugeliu atvejų, kai, nepaisant pranešimo apie konfigūracijų neatitikimus, rankinis palyginimas rodo, kad jie yra identiški.
Seka:
- iškelti cf failą iš centrinio banko;
- atsiejame UB nuo RIB (metodas Set MainNode, paruoštą apdorojimą galima rasti programoje ar kituose leidiniuose);
- pakeičiant konf. UB į pirmame žingsnyje įkeltą cf failą, tam naudojame meniu „Įkelti konfigūraciją iš failo“ (o ne palyginimas-sujungimas!!!);
- Atkurkime RIB ženklą UX.
Daugeliu atvejų šių veiksmų pakanka mainams atkurti, tačiau ne visada...
ANTRAS METODAS
Jis naudojamas, jei pirmasis metodas nepasiteisino ir mazgo iš naujo iškrauti neįmanoma.
Fonas: klientas kūrė kaskadinį RIB ir pirmame kaskados lygyje įvyko klaida (antrasis lygis visą tą laiką veikė nepriekaištingai). Konfigūracija buvo sukurta kartu su kliento IT tarnyba, o nuo tada, kai įvyko klaida, centrinio banko konfigūracija keitėsi keletą kartų. Pakeitimų atšaukimo galimybė net iš esmės nebuvo svarstoma, nes kai kurių duomenų praradimas ir kelių skyrių uždarymas buvo visiškai nepriimtinas. Pirmasis klaidos ištaisymo variantas nedavė jokių apčiuopiamų rezultatų. Todėl teko ieškoti kitų sprendimų.
Kilo mintis pabandyti pakeisti konfigūracijos failų maišą tiesiai į XML mainų failus. Keitimosi failo struktūros aprašymas iš knygos „Profesionalus tobulėjimas sistemoje 1C:Enterprise 8“ davė silpną idėją apie konfigūracijų skaitmeninių parašų formavimąsi ir jų pakeitimus, tačiau nulėmė konfigūracijos kryptį. paieška: Digest1 ir Digest2 reikšmės. Visa kita išsiaiškinau grynai empiriškai (ty bandymų ir klaidų būdu), bet buvo įmanoma nustatyti modelį.
Bandomieji eksperimentai buvo sėkmingi. Darbo bazėse taip pat viskas sekėsi puikiai.
Taigi, veiksmų seka:
- atlikite pirmojo metodo 1–4 veiksmus;
- Keitimo failą iškrauname iš UB, bet neįkeliame į centrinį banką;
- Keitimo failą iškrauname iš Centrinio banko, bet neįkeliame į UB;
- mainų faile iš centrinio banko pakeičiame bloką, kuriame yra informacija apie konfigūracijos pakeitimus ir maišą (Digest1 ir Digest2), maišos bloku iš UB failo (žr. toliau pateiktą pavyzdį)
- Failą įkeliame iš 4 taško į UB;
- Būtinai perrašykite mainų failą iš UB (2 taškas)! Keičiant su Centriniu banku šis failas neturėtų būti atsisiunčiamas!
- Norėdami patikrinti, atliekame kelis mainus iš eilės.
Jei mainų metu naudojamas duomenų suspaudimas, tada arba išjungiame glaudinimą, arba pirmiausia išpakuojame failą, pakeičiame, tada supakuojame atgal ir išsiunčiame.
Keisti failų bloką iš centrinio banko
reikia pakeisti mainų failo bloku iš UB (atminkite, kad UB failo Digest1 visada yra lygus "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"!!!)
Išvardyti veiksmai turi būti atliekami labai atsargiai, nes neteisinga seka gali sukelti visišką RIB neveikimą. Todėl prieš šiuos veiksmus atsarginių kopijų kūrimas PRIVALOMA!
Dėl kitų galiu tik palinkėti sėkmės!
Dinaminės naujinimo klaidos (ar kiti platformos trikdžiai) gali būti paskirstytų informacijos bazės mainų klaidų priežastis:
„Duomenys gaunami iš mazgo, kurio konfigūracijos pakeitimai buvo užregistruoti“
„Paskirstytos informacijos saugos mazgo konfigūracija neatitinka laukiamos“
Kaip atkurti mainus?
Bet pradėkime ne nuo restauravimo, o nuo galimybės jį atliktiapsikeisti „rankiniu būdu“, kas svarbu per dieną, nes kaip visada viskas turėtų veikti „vakar“ :) Tai galima padaryti pasitelkus nuostabias procedūras, kurių neprisiminiaunuogas ten, kur jį atsisiunčiau (autoriai, atsakykite - paliksiu nuorodas į jūsų šaltinį ir, jei reikės, ištrinsiu iš savo). Apdorojimas leidžia atsisiųsti tik registruotus duomenų pakeitimus duomenų bazėje (pagal nurodytą konkretaus mazgo mainų planą!) XML formatu, neatsisiunčiant konfigūracijos pakeitimų ir, jei konfigūracijos objektai nepasikeitė labai, yra labai didelė tikimybė. įkeliant šiuos duomenis. Juos galima atsisiųsti iš nuorodos straipsnio pabaigoje.
Kalbant apie atsigavimą. Yra paprastesnių metodų, į kuriuos neįtraukiami visi žemiau esančiame sąraše esantys elementai, tačiau jie ne visada padeda, kaip buvo vienu iš mano atvejų. Todėl pristatau metodą, kuris man padėjo, jis visapusiškiau apeina galimas problemas. Kitas žingsnis po žingsnio.
Patartina atlikti šiuos veiksmus, kai duomenų bazėje nėra dirbančių vartotojų. Jei tai neįmanoma, turėsite „užbaigti“ metodą patys, todėl pirmiausia turite suprasti jo logiką.
1. Kurkite atsargines kopijas visur.
2. Klientams-serveriams: išjunkite duomenų bazes per „serverio administravimą“ ir iš karto prijunkite jas suplanuotų užduočių blokavimu (tai iš naujo nustatys serverio talpyklą). Po to nepamirškite perkelti registracijos žurnalo į naują katalogą.
3. Visuose kompiuteriuose, naudojamuose atkūrimui, ištrinkite duomenų bazę 1C pradedančiųjų duomenų bazių sąraše ir sukurkite naują (bus išvalyta vartotojo talpykla)
4. Konfigūravimo priemonėje (centrinėje duomenų bazėje) pridėkite naują konstantą ir išsaugokite konf. pakeitimus.
5. Išvalykite visus mainų katalogus.
6. Atlikti iškrovimus į visas šakas (kol kas tik iškrovimus).
7. Pabandykite atsisiųsti (tik atsisiųsti) gautus duomenis į visus filialus. Natūralu priimti konf pakeitimus.
Jei viskas visur gerai, judame toliau, jei viskas blogai, manome, kad .cf iškėlimas iš centrinės duomenų bazės ir įkėlimas į šaką (ne lyginimas-jungimas) gali padėti. Verginiame mazge turėtumėte atsieti duomenų bazę nuo RIB (apdorojimas padės - atsisiųskite iš toliau pateiktos nuorodos). Infostart.ru yra straipsnis šia tema.
8. Atšaukiame pakeitimų registraciją filialams Centriniame banke (juk visus pakeitimus jau gavome visur). Šiame etape svarbu tai padaryti, kad sukaupti pokyčiai iš skirtingų šakų patektų į kitas šakas. (atsiuntimo apdorojimas, skirtas atrišimui-surišimui iš toliau pateiktos nuorodos).
9. Įkrauname į centrinį banką ir jei viskas gerai, tai su kiekvienu filialu po kelis kartus įkrauname ir iškrauname, kad rezultatas būtų konsoliduotas.
10. Štai ir viskas.
Galite įjungti įprastų klientų ir serverių duomenų bazių užduočių vykdymą.
Norint išvengti problemų, sukeliančių šią klaidą, rekomenduojama nedaryti dinaminių naujinimų (bent kelis kartus iš eilės – kol pakeitimai nebus įkelti į filialus), taip pat patartina pažymėti langelį „įkelti duomenis tik sėkmingai įkėlus“. mainų nustatymuose.
1C 8.x platformoms, kai įvyksta klaida „Paskirstytos informacijos saugos mazgo konfigūracija neatitinka laukiamos“
Problemos sprendimo metodika
Naudojamų santrumpų sąrašas:
RIB – paskirstyta informacinė bazė
CB - centrinė bazė, šakninis RIB mazgas
UB - nuotolinė bazė, nuotolinio RIB mazgo duomenų bazė
Iš savo patirties galiu pasakyti, kad susidūriau su dviem klaidos priežastimis:
Pranešimo failo priėmimo metu duomenų bazė „nukrito“ valdymo sistemoje, todėl, matyt, įvyko desinchronizacija tarp konf. Centrinis bankas ir UB;
pagal MSSQL klientas atsisiuntė veikiančios duomenų bazės kopiją ir neišjungė reg. automatinio apsikeitimo užduotys, todėl kai kurie pranešimai nuotoliniams mazgams buvo generuojami iš veikiančios duomenų bazės, o kai kurie iš kopijos, dėl ko buvo desinchronizuojamos konfigūracijos
Taip pat yra nuomonė, kad šią klaidą sukelia dinaminio duomenų bazės atnaujinimo mechanizmo naudojimas. Čia kyla abejonių, nes, viena vertus, dinaminis atnaujinimas niekada neveikia duomenų bazės struktūros, o RIB mechanizmai vis tiek veikia su duomenų bazės struktūra, o ne su jos taikoma dalimi, tačiau RIB naudoja skaitmeninio parašo generavimo mechanizmą. konfigūracijos versija (ateityje trumpai vadinsiu maišą), o pasikeitus programos daliai, maišą natūraliai reikia perskaičiuoti. Aš to nei neigsiu, nei patvirtinsiu, nes... Jei susidūriau su tokia situacija, neradau jokių aiškių įrodymų.
Norėdami tai ištaisyti, naudoju 2 būdus, priklausomai nuo situacijos.
PIRMOJI TECHNIKA
Pirmasis (labiausiai paplitęs) ne kartą minimas tiek partnerių konferencijoje, tiek kituose interneto šaltiniuose, susijusiuose su 1C. Jis naudojamas daugeliu atvejų, kai, nepaisant pranešimo apie konfigūracijų neatitikimus, rankinis palyginimas rodo, kad jie yra identiški.
Seka:
1. atsisiųskite cf failą iš centrinio banko;
2. atsieti UB nuo RIB (metodas Set MainNode, paruoštą apdorojimą rasite priede ar kituose leidiniuose);
3. pakeiskite konf. UB į pirmame žingsnyje įkeltą cf failą, tam naudojame meniu „Įkelti konfigūraciją iš failo“ (o ne palyginimas-sujungimas!!!);
4. atkurti RIB atributą UX.
Daugeliu atvejų šių veiksmų pakanka mainams atkurti, tačiau ne visada...
ANTRAS METODAS
Jis naudojamas, jei pirmasis metodas nepasiteisino ir mazgo iš naujo iškrauti neįmanoma.
Taigi, veiksmų seka:
1. Atlikite pirmojo metodo 1–4 veiksmus;
2. iškelti mainų failą iš UB, bet neįkelti į centrinį banką;
3. iškelti mainų failą iš Centrinio banko, bet neįkelti į MB;
4. Centrinio banko mainų faile bloką, kuriame yra informacija apie konfigūracijos pakeitimus ir maišą (Digest1 ir Digest2), pakeičiame maišos bloku iš UB failo (žr. toliau pateiktą pavyzdį).
5. Įkeliame failą iš 4 taško į UB;
Būtinai perrašykite mainų failą iš UB (2 taškas)! Keičiant su Centriniu banku šis failas neturėtų būti atsisiunčiamas!
Norėdami patikrinti, atliekame kelis mainus iš eilės.
Jei mainų metu naudojamas duomenų suspaudimas, tada arba išjungiame glaudinimą, arba pirmiausia išpakuojame failą, pakeičiame, tada supakuojame atgal ir išsiunčiame.
Keisti failų bloką iš centrinio banko
Reikia pakeisti „UB“ mainų failo bloku (atkreipkite dėmesį, kad failo iš UB „Digest1“ visada yra lygus „0000000000000000000000000000000000000“ !!!)
Išvardyti veiksmai turi būti atliekami labai atsargiai, nes neteisinga seka gali sukelti visišką RIB neveikimą. Todėl prieš šiuos veiksmus atsarginių kopijų kūrimas PRIVALOMA!
