Táto chyba je typická pre . Chyba „Konfigurácia distribuovaného uzla IS sa nezhoduje s očakávanou“ je systémová chyba. Vyskytuje sa hlavne v dôsledku zlyhania počas výmeny údajov cez URIB.
Dá sa to vyriešiť pomerne jednoduchým spôsobom. Zvážme to.
Inštrukcia
1. Vytvorte kópie databáz, s ktorými sa má pracovať (v konfigurátore „Správa – Uvoľniť infobázu“).
2. Spustite konfigurátor hlavnej databázy uzla RIB.
3. Uložte konfiguráciu centrálneho uzla do súboru databázy („Konfigurácia - Uložiť konfiguráciu do súboru…“).
4. Otvorte základný konfigurátor podriadeného uzla.
Získajte bezplatné video lekcie 267 1C:
5. Zrušte konfiguráciu podriadeného uzla z podpory (Konfigurácia - Podpora - Nastavenia podpory - Zrušiť podporu):
6. Načítajte konfiguráciu databázy ("Konfigurácia - Načítať konfiguráciu zo súboru...").
8. Po reštrukturalizácii musíte vstúpiť do podnikového režimu a nainštalovať hlavný konfiguračný uzol. To možno vykonať pomocou špeciálneho spracovania -. Spracovanie funguje v režime spravovanej aplikácie aj v režime bežnej aplikácie.
9. Pri spracovaní vyberte hlavný uzol a kliknite na „Spustiť“:
10. Hotovo! Skúste spustiť výmenu, systém by mal výmenu vykonať správne.
Na začiatok uvádzam zoznam skratiek, ktoré používam:
- RIB - distribuovaná informačná základňa
- CB - centrálna báza, koreňový uzol RIB
- UB - vzdialená základňa, databáza vzdialeného uzla RIB
Z vlastnej skúsenosti môžem povedať, že som narazil na dva dôvody chyby:
- pri prijímaní súboru správ v UB „padla základňa“, v súvislosti s ktorou zrejme došlo k desynchronizácii medzi konf. centrálna banka a UB;
- pod MSSQL si klient načítal kópiu pracovnej databázy a nevypol ju v kópii reg. úlohy automatickej výmeny, v dôsledku čoho sa časť správ do vzdialených uzlov vytvorila z pracovnej databázy a časť z kópie, čo viedlo k desynchronizácii konfigurácií
Existuje tiež názor, že k tejto chybe vedie použitie mechanizmu dynamickej aktualizácie databázy. Sú tu pochybnosti, pretože na jednej strane dynamická aktualizácia nikdy neovplyvňuje štruktúru databázy a mechanizmy RIB stále pracujú so štruktúrou databázy a nie s jej aplikačnou časťou, napriek tomu RIB používa mechanizmus na generovanie digitálneho podpisu verziu konfigurácie (v skratke to nazvem hash) a keď sa zmení aplikačná časť, musí sa hash prirodzene prepočítať. Nebudem to popierať ani tvrdiť, pretože. ak som sa stretol s touto situáciou, nenašiel som o tom jasný dôkaz.
Na opravu používam 2 spôsoby, v závislosti od situácie.
PRVÁ METÓDA
Prvý (najbežnejší) sa opakovane spomína na partnerskej konferencii aj na iných internetových zdrojoch súvisiacich s 1C. Používa sa vo väčšine prípadov, keď sa aj napriek hláseniu o nezrovnalostiach konfigurácií pri manuálnom porovnaní ukazuje, že sú totožné.
Sekvenovanie:
- vyložiť súbor cf z centrálnej banky;
- odpojíme UB od RIB (metóda SetMainNode, hotové spracovanie nájdete v aplikácii alebo v iných publikáciách);
- nahradiť konf. UB na súbore cf uvoľnenom v prvom kroku, na tento účel použijeme menu "Načítať konfiguráciu zo súboru" (a nie pomocou Compare-union !!!);
- obnovme znamenie RIB pre UB.
Vo väčšine prípadov sú tieto akcie viac než dostatočné na obnovenie výmeny, ale nie vždy...
DRUHÝ SPÔSOB
Používa sa, ak prvá metóda nefungovala a uzol nie je možné znova vyložiť.
Pozadie: klient nastavoval kaskádový RIB a v prvej úrovni kaskády sa vyskytla chyba (druhá úroveň fungovala celý čas bezchybne). Konfigurácia bola vyvinutá spoločne s IT službou klienta a od vzniku chyby sa konfigurácia CB niekoľkokrát zmenila. O možnosti vrátenia zmien sa v zásade ani neuvažovalo, pretože strata časti dát a odstávka viacerých oddelení boli úplne neprijateľné. Prvá verzia opravy chýb nepriniesla žiadne hmatateľné výsledky. V dôsledku toho bolo potrebné nájsť iné riešenia.
Prišiel nápad skúsiť zmeniť hashe konfiguračných súborov priamo v XML súboroch výmeny. Popis štruktúry výmenného súboru z knihy " Profesionálny vývoj v systéme 1C:Enterprise 8“ poskytol zlú predstavu o formácii digitálnych podpisov konfigurácie a ich zmeny, ale určil smer vyhľadávania: hodnoty Digest1 a Digest2. Na všetko ostatné som prišiel čisto empiricky (teda pokusom a omylom), ale podarilo sa mi stanoviť vzorec.
Testovacie experimenty dopadli dobre. Aj na základniach išlo všetko dobre.
Takže postupnosť akcií:
- vykonajte kroky 1 - 4 prvej techniky;
- uvoľnite súbor výmeny z UB, ale nenahrávajte ho do CB;
- vyložte výmenný súbor z centrálnej banky, ale nenahrávajte ho do UB;
- vo výmennom súbore z CB nahradíme blok obsahujúci informácie o zmenách konfigurácie a hashoch (Digest1 a Digest2) blokom hashov zo súboru UB (pozri príklad nižšie)
- nahráme súbor zo 4. bodu do UB;
- nezabudnite prepísať výmenný súbor z UB (2. odsek)! tento súbor sa nesmie načítať pri výmene v CB!
- pre kontrolu vykonáme niekoľko po sebe nasledujúcich výmen.
Ak sa pri výmene používa kompresia údajov, potom buď kompresiu vypnite, alebo súbor najskôr rozbaľte, zmeňte, potom zabaľte a odošlite.
Blokovať výmenu súborov z CB
je potrebné nahradiť blokom výmenného súboru z UB (všimnite si, že Digest1 súboru z UB sa vždy rovná "00000000000000000000000000000000"!! )
Uvedené činnosti sa musia vykonávať s mimoriadnou opatrnosťou, nesprávna postupnosť je spojená s úplnou nefunkčnosťou RIB. Preto je pred týmito akciami vytváranie záložných kópií POVINNÉ!
Inak vám môžem zaželať len veľa šťastia!
Chyby dynamickej aktualizácie (alebo iné chyby platformy) môžu byť príčinou chýb výmeny distribuovanej databázy:
"Údaje sa prijímajú z uzla, pre ktorý boli zaregistrované zmeny konfigurácie"
"Konfigurácia distribuovaného uzla IS nie je podľa očakávania"
Ako obnoviť výmenu?
Začnime však nie reštaurovaním, ale možnosťou utrácaťzmeniť "ručne", čo je dôležité počas dňa, pretože ako vždy, všetko by malo fungovať "včera" :) Môžete to urobiť pomocou úžasných kúr, ktoré si nepamätámNu, kde som stiahol (autori, odpovedzte - nechám odkazy na váš zdroj a z môjho, ak to bude potrebné, odstránim). Spracovanie umožňuje uvoľniť iba zaregistrované zmeny údajov v databáze (podľa zadaného plánu výmeny pre konkrétny uzol!) v XML bez uvoľnenia konfiguračných zmien, a ak sa konfiguračné objekty príliš nezmenili, potom je veľmi vysoká pravdepodobnosť načítavanie týchto údajov. Tie si môžete stiahnuť z odkazu na konci článku.
Čo sa týka obnovy. Existujú jednoduchšie spôsoby, ktoré nezahŕňajú všetky položky v zozname nižšie, ale nie vždy pomôžu, ako to bolo v jednom z mojich prípadov. Preto dávam metódu, ktorá mi pomohla, obchádza možné problémy komplexnejšie. Ďalej po schodoch.
Odporúča sa vykonať tieto kroky, keď v databáze nie sú žiadni pracujúci používatelia. Ak to nie je možné, potom budete musieť metódu "dokončiť" pre seba, a preto musíte najprv pochopiť jej logiku.
1. Všade zálohujte.
2. Pre klient-servery: deaktivujte databázy cez "administráciu servera" a ihneď sa spojte s inštaláciou blokovania naplánovaných úloh (tým sa vynuluje vyrovnávacia pamäť servera). Potom nezabudnite preniesť registračný denník do nového adresára.
3. Na všetkých počítačoch používaných na obnovu odstráňte databázu zo zoznamu štartovacích databáz 1C a vytvorte novú (vyrovnávacia pamäť používateľa sa vymaže)
4. V konfigurátore (v centrálnej databáze) pridajte novú konštantu na uloženie zmien konf.
5. Vyčistite všetky adresáre výmeny.
6. Vykonajte vykládky do všetkých pobočiek (zatiaľ len vykládky).
7. Pokúste sa nahrať (iba nahrať) prijaté dáta do všetkých pobočiek. Je prirodzené akceptovať zmeny konf.
Ak je všade všetko dobré, ideme ďalej, ak je všetko zlé, myslíme si, že môže pomôcť nahranie .cf z centrálnej databázy a jeho NAČÍTANIE do pobočky (nie porovnávacia únia). V slave uzle by ste mali odpojiť základňu od RIB (spracovanie s tým pomôže - stiahnite si z odkazu nižšie). Na stránke infostart.ru je k tejto téme článok.
8. Rušíme registráciu zmien pre pobočky v centrálnej banke (veď všetky zmeny sme už všade dostali). Je dôležité urobiť v tejto fáze, aby sa nahromadené zmeny z rôznych vetiev dostali do iných vetiev. (spracovanie na stiahnutie pre rozviazanie-viazanie z odkazu nižšie).
9. Robíme nakládku do centrálnej banky a ak je všetko v poriadku, tak nakládku a vykládku urobíme s každou pobočkou niekoľkokrát, aby sme výsledok skonsolidovali.
10. Všetko.
Môžete povoliť vykonávanie naplánovaných úloh pre databázy klient-server.
Aby sa predišlo problémom, ktoré spôsobujú túto chybu, odporúča sa nerobiť dynamickú aktualizáciu (aspoň niekoľkokrát za sebou – pred nahraním zmien do pobočiek) a taktiež je vhodné zaškrtnúť políčko „nahrať dáta až po úspešnom nahraní“ v nastaveniach výmeny.
Na začiatok uvádzam zoznam skratiek, ktoré používam:
- RIB - distribuovaná informačná základňa
- CB - centrálna báza, koreňový uzol RIB
- UB - vzdialená základňa, databáza vzdialeného uzla RIB
Z vlastnej skúsenosti môžem povedať, že som narazil na dva dôvody chyby:
- pri prijímaní súboru správ v UB „padla základňa“, v súvislosti s ktorou zrejme došlo k desynchronizácii medzi konf. centrálna banka a UB;
- pod MSSQL si klient načítal kópiu pracovnej databázy a nevypol ju v kópii reg. úlohy automatickej výmeny, v dôsledku čoho sa časť správ do vzdialených uzlov vytvorila z pracovnej databázy a časť z kópie, čo viedlo k desynchronizácii konfigurácií
Existuje tiež názor, že k tejto chybe vedie použitie mechanizmu dynamickej aktualizácie databázy. Sú tu pochybnosti, pretože na jednej strane dynamická aktualizácia nikdy neovplyvňuje štruktúru databázy a mechanizmy RIB stále pracujú so štruktúrou databázy a nie s jej aplikačnou časťou, napriek tomu RIB používa mechanizmus na generovanie digitálneho podpisu verziu konfigurácie (v skratke to nazvem hash) a keď sa zmení aplikačná časť, musí sa hash prirodzene prepočítať. Nebudem to popierať ani tvrdiť, pretože. ak som sa stretol s touto situáciou, nenašiel som o tom jasný dôkaz.
Na opravu používam 2 spôsoby, v závislosti od situácie.
PRVÁ METÓDA
Prvý (najbežnejší) sa opakovane spomína na partnerskej konferencii aj na iných internetových zdrojoch súvisiacich s 1C. Používa sa vo väčšine prípadov, keď sa aj napriek hláseniu o nezrovnalostiach konfigurácií pri manuálnom porovnaní ukazuje, že sú totožné.
Sekvenovanie:
- vyložiť súbor cf z centrálnej banky;
- odpojíme UB od RIB (metóda SetMainNode, hotové spracovanie nájdete v aplikácii alebo v iných publikáciách);
- nahradiť konf. UB na súbore cf uvoľnenom v prvom kroku, na tento účel použijeme menu "Načítať konfiguráciu zo súboru" (a nie pomocou Compare-union !!!);
- obnovme znamenie RIB pre UB.
Vo väčšine prípadov sú tieto akcie viac než dostatočné na obnovenie výmeny, ale nie vždy...
DRUHÝ SPÔSOB
Používa sa, ak prvá metóda nefungovala a uzol nie je možné znova vyložiť.
Pozadie: klient nastavoval kaskádový RIB a v prvej úrovni kaskády sa vyskytla chyba (druhá úroveň fungovala celý čas bezchybne). Konfigurácia bola vyvinutá spoločne s IT službou klienta a od vzniku chyby sa konfigurácia CB niekoľkokrát zmenila. O možnosti vrátenia zmien sa v zásade ani neuvažovalo, pretože strata časti dát a odstávka viacerých oddelení boli úplne neprijateľné. Prvá verzia opravy chýb nepriniesla žiadne hmatateľné výsledky. V dôsledku toho bolo potrebné nájsť iné riešenia.
Prišiel nápad skúsiť zmeniť hashe konfiguračných súborov priamo v XML súboroch výmeny. Opis štruktúry výmenného súboru z knihy „Profesionálny vývoj v systéme 1C:Enterprise 8“ poskytol zlú predstavu o vytváraní digitálnych podpisov konfigurácií a zmien v nich, ale určil smer vyhľadávania: Digest1 a Hodnoty Digest2. Na všetko ostatné som prišiel čisto empiricky (teda pokusom a omylom), ale podarilo sa mi stanoviť vzorec.
Testovacie experimenty dopadli dobre. Aj na základniach išlo všetko dobre.
Takže postupnosť akcií:
- vykonajte kroky 1 - 4 prvej techniky;
- uvoľnite súbor výmeny z UB, ale nenahrávajte ho do CB;
- vyložte výmenný súbor z centrálnej banky, ale nenahrávajte ho do UB;
- vo výmennom súbore z CB nahradíme blok obsahujúci informácie o zmenách konfigurácie a hashoch (Digest1 a Digest2) blokom hashov zo súboru UB (pozri príklad nižšie)
- nahráme súbor zo 4. bodu do UB;
- nezabudnite prepísať výmenný súbor z UB (2. odsek)! tento súbor sa nesmie načítať pri výmene v CB!
- pre kontrolu vykonáme niekoľko po sebe nasledujúcich výmen.
Ak sa pri výmene používa kompresia údajov, potom buď kompresiu vypnite, alebo súbor najskôr rozbaľte, zmeňte, potom zabaľte a odošlite.
Blokovať výmenu súborov z CB
...tu sú bloky popisujúce zmeny konfigurácie...
musí byť nahradený blokom výmenného súboru z UB (poznámka Digest1 súboru z UB je vždy "0000000000000000000000000000000"!!!)
Uvedené činnosti sa musia vykonávať s mimoriadnou opatrnosťou, nesprávna postupnosť je spojená s úplnou nefunkčnosťou RIB. Preto je pred týmito akciami vytváranie záložných kópií POVINNÉ!
Inak vám môžem zaželať len veľa šťastia!
Otázka: Chyba aktualizácie uzla RIB
Dobrý deň.
Aktualizovaný hlavný uzol Rarus-Retail na 2.2.5.27, vykonaná výmena s niekoľkými uzlami RIB - všetko je v poriadku.
Spustil som hromadnú aktualizáciu zvyšných uzlov (podobne ako pri „top pair“ (iné obchody v RIB)) – na strane klienta sa objaví chyba:
Distribúcia správ. Registrovať údaje na aktualizáciu zoznamu naplánovaných úloh"
obsluha odloženej aktualizácie
"Distribúcia správ. Aktualizujte zoznam naplánovaných úloh"
Došlo k chybe:
"(GeneralModule.GeneralPurpose.Module(3502)): Chyba pri volaní kontextovej metódy (obsahuje)
Return Metadata.InformationRegisters.Contains(MetadataObject);
kvôli:
Nesúlad typov (číslo parametra „1“).
Môže niekto naraziť? Už som skúšal aktualizovať platformu (maximálne do 8.3.10 a skontroloval som to na 32-64 počítačoch) ... nepomohlo. Ale koniec koncov, testovacie obchody 2 boli aktualizované bez problémov, nechápem ako.
odpoveď:() Takto nainštalujem hlavný uzol. Napísal som trochu o niečom inom: po rozpojení uzla spracovaním sa pri ďalšom spustení aktualizácia konf nespustí okamžite, ale najskôr 1C otvorí okno, v ktorom vás požiada o potvrdenie, že sa uzol odpája. Potom sa aktualizuje - po aktualizácii uzol už nie je v zozname.
V skutočnosti si 2.1 pamätám, že som to aktualizoval pomocou tejto metódy, ale niečo sa na 2.2. Možno v parku už vypichol nesprávnu postupnosť akcií)
PODĽA PREDMETU:
Pochopil, čo je. Ukázalo sa, že prehliadol:
"V jednom z vydaní 2.2 sa objavil adresár Distribuujeme správy s preddefinovaný prvok"Osobné údaje" - adresár s týmto prvkom bol aj 2.1.
Nuance je takáto: zárubne s aktualizačnými uzlami sú pozorované na tých základoch, ktoré boli vytvorené z centrálnej presne pri vydaní 2.1.9.18. Všetko, čo bolo vytvorené v predchádzajúcich vydaniach, bolo normálne aktualizované. To pravdepodobne vysvetľuje, prečo bolo úspešne aktualizovaných aj niekoľko základov pre TS a potom odišli zárubne.
S vytvorením nového prvku v adresári a jeho nastavením ako preddefinovaný som nič nevymyslel. Preniesol tento prvok z kópie centra do 2.1 cez vyloženie/načítanie XML a zopakoval aktualizáciu na problematickej "základni" - všetko prebehlo v poriadku.
() Takže použite metódu, ak ste ešte nenašli odpoveď.
Otázka: Chyba aktualizácie konfigurácie
Aktualizujem konfiguráciu Účtovníctva 2.0.64.14 na 2.0.64.24. nástupište 8.2.19
Okamžite sa vyskytne chyba:
Chyba pri prístupe k súboru... cesta... dočasný súbor.tmp.
Kde hľadať?
odpoveď: vyriešil tento problém čakaním na nové "stabilné" vydanie
Otázka: Chyba v používateľských právach na BSP
Pozdravujem!!! Píšem konf na základe BSP 2.2, zdá sa, že už mám skúsenosti a študoval som doky hore a dole, ale pri prvom spustení IB sa vyskytne chyba:(CommonModule.UsersService.Module(345)): Autorizácia zlyhala. Systém bude vypnutý.
Používateľ: Administrátor sa nenašiel v adresári „Používatelia“.Pri pokuse o pridanie používateľa do adresára sa vyskytla chyba:
"Aktualizácia informačnej databázy zlyhala.
Parameter obmedzenia prístupu nie je vyplnený:
"Možné práva pre nastavenie práv objektu".Pre vývojára: možno budete musieť aktualizovať podporné údaje,
ktoré ovplyvňujú fungovanie programu. Ak chcete vykonať aktualizáciu, môžete:
- využiť externé spracovanie
"Nástroje pre vývojárov: Aktualizácia údajov podpory",
- buď spustite program s parametrom príkazový riadok 1C:Podnik 8
"/C Startupdating Infobase",
- buď zvýšte číslo verzie konfigurácie tak, aby pri ďalšom spustení
boli dokončené postupy na aktualizáciu údajov informačnej databázy.“Kliknutím zobrazíte...
Rád by som počul odpovede „skúsených“, na následný aktívny dialóg, možno aj spoluprácu
odpoveď:
vdeg povedal:
Problém je vyriešený?
Mám problém s iným plánom: pridám používateľa do BSP 2.2.5.29 a ten má buď plné práva (ak ich pridáte ručne), alebo žiadne (vidí prázdne rozhranie bez jeden adresár a dokument). Pretože v typických rolách BSP neexistujú žiadne začiarkavacie políčka pre prístup k špecifickým (mojim) adresárom a dokumentom. Ako sa potom bude sledovať prístup na úrovni záznamu pre nového používateľa???
Kliknutím zobrazíte...
A ako by mal BSP zistiť, aké máte adresáre a ako chcete k nim nakonfigurovať prístup?
Asi by sme to mali urobiť sami.
Otázka: SendingDeliverableNotified Overenie vzdialeného hostiteľa zlyhalo
Až do minulého piatku fungoval nasledujúci kód dobre.
XdtoSubscriber = XDTO Factory.Create(XDTO Factory.Type(";));
xdtoSubscriber.DeviceID = ID zariadenia;
xdtoSubscriber.SubscriberType = XDTO Factory.Create(XDTO Factory.Type(";), "GCM");
NewXDTO Serializer = Nový XDTO Serializer (XDTO Factory);
Predplatiteľ = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
Notification=New DeliverableNotification;
Notification.Recipients.Add(Subscriber);
Notification.Text=Text;
Notification.SoundAlert=SoundAlert.Predvolené;
Notice.Sticker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Notification,AuzData,True);
Teraz je chybou Remote Host Failed Validation. Rozbil mi celú hlavu. Zachytil som volania servera - je to prázdne, že sa nikam neotáča ... Skúšal som na troch rôznych strojoch s rôznymi osami. vyčerpaný.. pomoc...
odpoveď: Hore
odpoveď: Rozhodol som sa teda urobiť obrázok uzla znova. Pri spúšťaní uzla sa píše, že ho treba spustiť s \c, aby sa začala aktualizácia infobázy
a re-image.
Ukazuje sa, že je to niečo kvôli skreslenej aktualizácii.
Pokúsil som sa spustiť s týmto kľúčom a vykonať výmenu s existujúcim uzlom. V uzle neboli spustené žiadne aktualizácie, nič nebolo požiadané o reštart.
Výsledkom bolo, že v hlavnom uzle nebola správa opäť prijatá s rovnakou chybou.
Čo sa dá robiť?
Dá sa zmeniť niečo fiktívne v hlavnom uzle v konf a uskutočniť výmenu? Alebo nebude aktualizovať celý conf, ale len to, čo zmením? Zatiaľ sa pokúsim urobiť uzol. Ale počkám si na vaše nápady.
Otázka: Distribuovaná databáza - chyba pri výmene nie je odstránená
Pekný deň všetkým!
Situácia je nasledovná.
Pri načítavaní výmeny z periférneho uzla dostávam hlásenie „Konfigurácia distribuovaného uzla IS nezodpovedá očakávanej“.
Potom postupujem podľa návodu.
Vyložím konfiguráciu z centrálnej databázy do CF, spracovaním odpojím periférnu databázu od centrálneho uzla, odstránim konfiguráciu v periférnej databáze z podpory, načítam konfiguráciu zo súboru.
Spracovaním naviažem centrálny uzol v periférnej databáze.
Uložiť, použiť.
Ešte raz stiahnem výmenu z centrálnej databázy.
Načítavam v periférii. Vyložím výmenu z databázy periférnych zariadení.
Nahrávanie do centrály. Opäť dostávam hlásenie "Konfigurácia distribuovaného uzla IS nezodpovedá očakávanému".
Ale to je riadny nezmysel - načítam konfiguráciu do centrálnej databázy a nikto nezmenil konfiguráciu v periférnej databáze.
Ako prekonať takúto chybu?
odpoveď: nikoho nenapadlo radiť takéto samozrejmé veci po dlhých rokoch nadávania na démonickú aktualizáciu :)
Otázka: RIB a aktualizácie
Ahojte všetci. Plánuje sa využitie distribuovanej informačnej bezpečnosti.
konfigurácia zmenená. Aktualizáciu konfigurácie centrálnej databázy vykonáva programátor. Potom sa s výmennými súbormi tieto zmeny prenesú do periférnych databáz.
Otázka znie: čo spustenie handlerov po aktualizácii konfigurácie databázy a prvom prihlásení v užívateľskom režime?
aktualizácia hlavnej konfigurácie - aktualizácia konfigurácie databázy - spustenie obslužných programov aktualizácie v užívateľskom režime
Napríklad, veľa vydaní bolo zmeškaných. Ak chcete aktualizovať na 3 vydania, musíte vykonať inováciu postupne. S aktualizáciou centrálnej databázy problémy nie sú, ale čo tie periférne? Taktiež je potrebné ich aktualizovať v 3 etapách (aktualizácia centrálnej databázy prvým vydaním, aktualizácia RIB, aktualizácia centrálnej databázy druhým vydaním, aktualizácia RIB atď.?)
Ďakujem vám všetkým za pomoc!
odpoveď:() strčiť nos, nemôžem nájsť kód, ktorý sa vykonáva pri registrácii zmien objektu.
Zdá sa, že ak použijete metódu OnSendingData, hlavný uzol bude stále akumulovať zmenené objekty na odoslanie do podriadeného uzla. A to sú ďalšie počítačové zdroje
Preto chcem, aby objekty v hlavnom uzle neboli zaregistrované na odoslanie okamžite v čase ich zmeny (napríklad On Write). Na akom mieste, napríklad v štandardnom Účtovníctve rev.3, sú tieto objekty evidované na odoslanie?
Otázka: [VYRIEŠENÉ] Chyba pri kontaktovaní podpory online
Vážení odborníci, povedzte mi, prosím!
1C:Enterprise 8.3 (8.3.11.2899)
Na serveri 1C sa točí niekoľko databáz rôznych konfigurácií, vo všetkých je pripojená internetová podpora a funguje dobre. Vrátane načítanie výmenných kurzov, banky, kontrola protistrán, SPARK atď.
Nastavenia proxy sú rovnaké pre všetky databázy.
Ale v databázach BP-3 CORP sa vždy vyskytne chyba:V registračnom denníku:
Nepodarilo sa získať overovací lístok v službe.
Nepodarilo sa načítať obsah(). (GeneralModule.InternetUserSupportClientServer.Module(362)): Chyba pri volaní kontextovej metódy (SendToProcess)
Response = Connection.SendForProcessing(HTTPRequest, ReceiveParameters.ResponseFileName);
kvôli:
Chyba internetu: Overenie vzdialeného hostiteľa zlyhaloKliknutím zobrazíte...
Vyskúšali si to rôzne verzie platformy (8.3.10..., 8.3.11...) a na rôznych verziách konfigurácie (3.0.54.15, 3.0.57.10).
Nepomáha ani testovanie a oprava.
Čo môže byť zlé?
Ide BP-CORP nejako špeciálne na internet?
Ďakujem.
odpoveď:
Odpoveď od 1C (to, čo je zvýraznené červenou farbou, mi pomohlo):Počas prechodu bol BSP aktualizovaný ako súčasť BP z 2.4.3 na 2.4.4.
V zozname zmien v BSP 2.4.4
Vylepšené zabezpečenie pri vytváraní zabezpečeného pripojenia k internetovým službám HTTPS. Pri detekcii rôzne problémy s certifikátom internetovej služby, s ktorou sa pokúšate o bezpečné pripojenie (certifikát je neplatný, zastaraný alebo nedôveryhodný), sa spojenie nevytvorí.
V 8.3.10 sa overenie certifikátu v systéme Windows vykonáva pomocou operačný systém." -
Nainštalujte najnovšie aktualizácie pre váš operačný systém, obsahujú dôležité aktualizácie systémové komponenty, ktoré sú zodpovedné za prácu s certifikátmi.
Prosím aj o inštaláciu najnovšia aktualizácia koreňové certifikáty distribuované spoločnosťou Microsoft v inštalovateľných balíkoch.
Vyžaduje verziu aspoň IE8.0. Obsahuje dôležité aktualizácie systémových komponentov, ktoré sú zodpovedné za prácu s certifikátmi.
Po nainštalovaní všetkých aktualizácií je problém spravidla vyriešený.
Skontrolujte, či sa odkaz otvorí, ak zadáte do vyhľadávacieho panela v programe Internet Explorer.
Používateľ, v mene ktorého pracujete, má prístup na internet.
Ak ide o databázu súborov na klientskom počítači, mala by sa na nej skontrolovať.
Ak ide o databázu klient-server, potom na serveri pod používateľom, pod ktorým beží server 1C.
Skontrolujte iba pomocou prehliadača IE.
Skontrolujte, či sú otvorené porty 443 a 80
Ak používate server proxy, skontrolujte, či sú nakonfigurované údaje v ponuke Osobné nastavenia.
Ak sa používa verzia klient-server, potom server by ste mali nakonfigurovať tak, aby na ňom správne fungovalo internetové pripojenie s prehliadačom IE pod používateľom, v mene ktorého server 1C beží.
Zaregistroval som proxy v nastaveniach IE používateľa, pod ktorým beží server 1C - všetko fungovalo.
Otázka: Aktualizujte boo 3
Dobrý deň
Účtovníctvo 3
vykonal aktualizáciu z 3.0.43.208 na 3.0.43.235
chyby
najprv
(GeneralModule.MessagingInternal.Module(381)): Chyba pri volaní kontextovej metódy (ThisNode)
kvôli:
Našiel sa viac ako jeden záznam
druhý
Pri volaní obslužného programu aktualizácie:
"MessagingInternal.SetThisEndPointCode()"
Došlo k chybe:
"(GeneralModule.MessagingInternal.Module(381)): Chyba pri volaní kontextovej metódy (ThisNode)
ReturnInterchangePlans.MessageExchange.ThisNode();
kvôli:
Našiel sa viac ako jeden záznam."Vážená platforma na zápis prevýšenia vyskúšaná na rôznych verziách platforiem
pokúsil sa o čistý konf Najnovšia verzia a len hlúpo kompletnú výmenu načítať
vobec nepomohlo, stale to iste. Povedz mi zrazu, kto narazil?
odpoveď:
uzol z pravdivého na nepravdivý
Načítava...