Ky gabim është tipik për. Gabimi "Konfigurimi i nyjës së shpërndarë IS nuk përputhet me pritjen" është një gabim i sistemit. Kryesisht ndodh për shkak të një përplasjeje gjatë shkëmbimit të të dhënave mbi URIB.
Kjo mund të zgjidhet në një mënyrë mjaft të thjeshtë. Le ta konsiderojmë atë.
Udhëzim
1. Bëni kopje të bazave të të dhënave për t'u punuar (Në konfiguruesin "Administrimi - Ngarko infobazë").
2. Ekzekutoni konfiguruesin për bazën e të dhënave kryesore të nyjës RIB.
3. Ruani konfigurimin e nyjës qendrore në një skedar bazë të dhënash (“Konfigurimi - Ruaje konfigurimin në skedar…”)
4. Hapni konfiguruesin bazë të nyjeve skllav.
Merrni mësime video 267 1C falas:
5. De-konfiguroni nyjen skllav nga mbështetja (Konfigurimi - Mbështetja - Cilësimet e mbështetjes - De-mbështetja):
6. Ngarko konfigurimin e bazës së të dhënave ("Configuration - Load configuration from file...").
8. Pas ristrukturimit, duhet të hyni në modalitetin e ndërmarrjes dhe të instaloni nyjen kryesore të konfigurimit. Kjo mund të bëhet duke përdorur përpunim special -. Përpunimi funksionon si në modalitetin e aplikacionit të menaxhuar ashtu edhe në modalitetin e rregullt të aplikacionit.
9. Në përpunim, zgjidhni nyjen kryesore dhe klikoni "Run":
10. U krye! Përpiquni të filloni shkëmbimin, sistemi duhet të kryejë shkëmbimin në mënyrë korrekte.
Për të filluar, këtu është një listë e shkurtesave që përdor:
- RIB - baza e informacionit e shpërndarë
- CB - baza qendrore, nyja rrënjë RIB
- UB - baza e largët, baza e të dhënave e nyjes së largët RIB
Nga përvoja ime, mund të them se kam hasur dy arsye për gabimin:
- gjatë marrjes së skedarit të mesazhit në UB, baza "ra", në lidhje me të cilën, me sa duket, pati një desinkronizim midis konf. Banka Qendrore dhe UB;
- nën MSSQL, klienti ngarkoi një kopje të bazës së të dhënave të punës dhe nuk e çaktivizoi atë në kopjen e reg. detyrat e shkëmbimit automatik, si rezultat, një pjesë e mesazheve në nyjet e largëta u formuan nga baza e të dhënave të punës, dhe një pjesë nga një kopje, gjë që çoi në desinkronizimin e konfigurimeve
Ekziston gjithashtu një mendim se përdorimi i mekanizmit dinamik të përditësimit të bazës së të dhënave çon në këtë gabim. Këtu ka dyshime, sepse, nga njëra anë, azhurnimi dinamik nuk ndikon kurrë në strukturën e bazës së të dhënave, dhe mekanizmat RIB ende punojnë me strukturën e bazës së të dhënave, dhe jo me pjesën e saj të aplikimit, megjithatë, RIB përdor mekanizmin për gjenerimin e një nënshkrimi dixhital. të versionit të konfigurimit (në vijim, do ta quaja shkurtimisht hash), dhe kur pjesa e aplikacionit ndryshon, hash-i duhet të rillogaritet natyrshëm. Këtë nuk do ta mohoj, as pohoj, sepse. nëse ballafaqohesha me këtë situatë, atëherë nuk gjeta prova të qarta për këtë.
Unë përdor 2 metoda për ta rregulluar atë, në varësi të situatës.
METODA E PARË
E para (më e zakonshme) përmendet vazhdimisht si në konferencën e partnerit ashtu edhe në burime të tjera të Internetit që lidhen me 1C. Përdoret në shumicën e rasteve, kur pavarësisht mesazhit për mospërputhjet e konfigurimeve, kur krahasohen manualisht, duket se ato janë identike.
Renditja:
- shkarkoj dosjen cf nga Banka Qendrore;
- ne e zgjidhim UB-në nga RIB (metoda SetMainNode, përpunimi i gatshëm mund të gjendet në aplikacion ose në botime të tjera);
- zëvendësoj conf. UB në skedarin cf të shkarkuar në hapin e parë, për këtë përdorim menynë "Konfigurimi i ngarkimit nga skedari" (dhe jo nga krahasimi-bashkimi !!!);
- le të rivendosim shenjën e RIB për UB.
Në shumicën e rasteve, këto veprime janë më se të mjaftueshme për të rivendosur shkëmbimin, por jo gjithmonë...
METODA E DYTË
Përdoret nëse metoda e parë nuk funksionoi dhe nuk është e mundur të shkarkohet përsëri nyja.
Sfondi: klienti po krijonte një RIB kaskadë dhe ndodhi një gabim në nivelin e parë të kaskadës (niveli i dytë funksionoi pa të meta gjatë gjithë kësaj kohe). Konfigurimi është zhvilluar së bashku me shërbimin e IT të klientit dhe që kur ka ndodhur gabimi, konfigurimi CB ka ndryshuar disa herë. Opsioni i rikthimit të ndryshimeve as që u konsiderua në parim, sepse humbja e një pjese të të dhënave dhe mbyllja e disa departamenteve ishin krejtësisht të papranueshme. Versioni i parë i korrigjimit të gabimit nuk dha ndonjë rezultat të prekshëm. Si rezultat, duheshin gjetur zgjidhje të tjera.
Ideja erdhi në përpjekje për të ndryshuar hash-et e skedarëve të konfigurimit direkt në skedarët e shkëmbimit XML. Përshkrimi i strukturës së skedarit të shkëmbimit nga libri " Zhvillim profesional në sistemin 1C: Enterprise 8" dha një ide të dobët të formimit nënshkrimet dixhitale konfigurimet dhe ndryshimet në to, por përcaktuan drejtimin e kërkimit: vlerat Digest1 dhe Digest2. Unë kuptova gjithçka tjetër thjesht në mënyrë empirike (d.m.th., me provë dhe gabim), por arrita të krijoj një model.
Eksperimentet e testimit shkuan mirë. Edhe në baza, gjithçka shkoi mirë.
Pra, sekuenca e veprimeve:
- kryeni hapat 1 - 4 të teknikës së parë;
- shkarkoni skedarin e shkëmbimit nga UB, por mos e ngarkoni atë në CB;
- shkarkoni skedarin e këmbimit nga Banka Qendrore, por mos e ngarkoni atë në UB;
- në skedarin e shkëmbimit nga CB, ne zëvendësojmë bllokun që përmban informacione rreth ndryshimeve të konfigurimit dhe hasheve (Digest1 dhe Digest2) me një bllok hashesh nga skedari UB (shih një shembull më poshtë)
- ne ngarkojmë skedarin nga pika e 4-të në UB;
- sigurohuni që të mbishkruani skedarin e shkëmbimit nga UB (paragrafi 2)! ky skedar nuk duhet të ngarkohet gjatë shkëmbimit në CB!
- për të kontrolluar, ne bëjmë disa shkëmbime të njëpasnjëshme.
Nëse kompresimi i të dhënave përdoret gjatë shkëmbimit, atëherë ose çaktivizoni kompresimin, ose së pari shpaketoni skedarin, ndryshoni atë, pastaj paketoni përsëri dhe dërgojeni.
Blloko shkëmbimin e skedarëve nga CB
duhet të zëvendësohet me një bllok të skedarit të shkëmbimit nga UB (vini re se Digest1 i skedarit nga UB është gjithmonë i barabartë me "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"!!
Veprimet e listuara duhet të kryhen me kujdes ekstrem, një sekuencë e pasaktë është e mbushur me mosfunksionim të plotë të RIB. Prandaj, para këtyre veprimeve, krijimi i kopjeve rezervë është i detyrueshëm!
Përndryshe, nuk mund të të uroj vetëm fat!
Gabimet dinamike të përditësimit (ose gabimet e tjera të platformës) mund të jenë shkaqet e gabimeve të shkëmbimit të bazës së informacionit të shpërndarë:
"Të dhënat po merren nga nyja për të cilën janë regjistruar ndryshimet e konfigurimit"
"Konfigurimi i nyjës IS i shpërndarë jo siç pritej"
Si të rivendosni shkëmbimin?
Por le të fillojmë jo me restaurimin, por me mundësinë për të shpenzuarndërroni "manualisht", gjë që është e rëndësishme gjatë ditës, sepse, si gjithmonë, gjithçka duhet të funksionojë "dje" :) Këtë mund ta bëni me ndihmën e trajtimeve të mrekullueshme që nuk më kujtohenNu u shkarkua (autorë, përgjigjuni - Unë do të lë lidhje me burimin tuaj, dhe nga imi, nëse është e nevojshme, do të fshij). Përpunimi bën të mundur shkarkimin e vetëm ndryshimeve të regjistruara të të dhënave në bazën e të dhënave (sipas planit të specifikuar të shkëmbimit për një nyje specifike!) në XML pa shkarkuar ndryshimet e konfigurimit, dhe nëse objektet e konfigurimit nuk kanë ndryshuar shumë, atëherë ka shanse shumë të larta për ngarkimi i këtyre të dhënave. Këto mund të shkarkohen nga lidhja në fund të artikullit.
Sa i përket rimëkëmbjes. Ka metoda më të thjeshta që nuk përfshijnë të gjithë artikujt në listën e mëposhtme, por jo gjithmonë ndihmojnë, siç ishte rasti në një nga rastet e mia. Prandaj, unë jap metodën që më ndihmoi, ajo i anashkalon problemet e mundshme në mënyrë më gjithëpërfshirëse. Më tej në hapa.
Këshillohet që këto hapa të kryhen kur nuk ka përdorues që punojnë në bazën e të dhënave. Nëse kjo nuk është e mundur, atëherë do t'ju duhet ta "përfundoni" metodën për veten tuaj, dhe për këtë arsye së pari duhet të kuptoni logjikën e saj.
1. Bëni kopje rezervë kudo.
2. Për klient-serverët: çaktivizoni bazat e të dhënave përmes "administrimit të serverit" dhe lidheni menjëherë me instalimin e bllokimit të detyrave të planifikuara (kështu do të rivendoset cache e serverit). Pas kësaj, mos harroni të transferoni regjistrin e regjistrimit në drejtorinë e re.
3. Në të gjithë kompjuterët e përdorur për rikuperim, fshini bazën e të dhënave në listën e bazave të të dhënave fillestare 1C dhe krijoni një të re (cache e përdoruesit do të pastrohet)
4. Në konfiguruesin (në bazën qendrore të të dhënave) shtoni një konstante të re për të ruajtur ndryshimet në konf.
5. Pastroni të gjitha drejtoritë e shkëmbimit.
6. Bëni shkarkime në të gjitha degët (deri tani vetëm shkarkime).
7. Mundohuni të ngarkoni (vetëm ngarkoni) të dhënat e marra në të gjitha degët. Është e natyrshme të pranohen ndryshimet e konf.
Nëse gjithçka është mirë kudo, shkojmë më tej, nëse gjithçka është e keqe, mendojmë se ngarkimi i .cf nga baza e të dhënave qendrore dhe LOADING i tij në degë (jo krahasim-bashkim) mund të ndihmojë. Në nyjen skllav, duhet të zgjidhësh bazën nga RIB (përpunimi do të ndihmojë me këtë - shkarkoni nga lidhja më poshtë). Ekziston një artikull mbi këtë temë në infostart.ru.
8. Anulojmë regjistrimin e ndryshimeve për degët në Bankën Qendrore (në fund të fundit, të gjitha ndryshimet i kemi marrë kudo). Është e rëndësishme të bëhet në këtë fazë në mënyrë që ndryshimet e grumbulluara nga degë të ndryshme të kalojnë në degë të tjera. (shkarkoni përpunimin për çlidhje-lidhje nga lidhja më poshtë).
9. Ne bëjmë ngarkimin në Bankën Qendrore dhe nëse gjithçka është në rregull, atëherë ngarkimin dhe shkarkimin e bëjmë me çdo degë disa herë për të konsoliduar rezultatin.
10. Gjithçka.
Mund të aktivizoni ekzekutimin e detyrave të planifikuara për bazat e të dhënave klient-server.
Për të parandaluar problemet që shkaktojnë këtë gabim, rekomandohet të mos bëni një përditësim dinamik (të paktën disa herë radhazi - përpara se të ngarkoni ndryshimet në degë), dhe gjithashtu këshillohet që të kontrolloni kutinë "Ngarkoni të dhënat vetëm pas ngarkimit të suksesshëm". në cilësimet e shkëmbimit.
Për të filluar, këtu është një listë e shkurtesave që përdor:
- RIB - baza e informacionit e shpërndarë
- CB - baza qendrore, nyja rrënjë RIB
- UB - baza e largët, baza e të dhënave e nyjes së largët RIB
Nga përvoja ime, mund të them se kam hasur dy arsye për gabimin:
- gjatë marrjes së skedarit të mesazhit në UB, baza "ra", në lidhje me të cilën, me sa duket, pati një desinkronizim midis konf. Banka Qendrore dhe UB;
- nën MSSQL, klienti ngarkoi një kopje të bazës së të dhënave të punës dhe nuk e çaktivizoi atë në kopjen e reg. detyrat e shkëmbimit automatik, si rezultat, një pjesë e mesazheve në nyjet e largëta u formuan nga baza e të dhënave të punës, dhe një pjesë nga një kopje, gjë që çoi në desinkronizimin e konfigurimeve
Ekziston gjithashtu një mendim se përdorimi i mekanizmit dinamik të përditësimit të bazës së të dhënave çon në këtë gabim. Këtu ka dyshime, sepse, nga njëra anë, azhurnimi dinamik nuk ndikon kurrë në strukturën e bazës së të dhënave, dhe mekanizmat RIB ende punojnë me strukturën e bazës së të dhënave, dhe jo me pjesën e saj të aplikimit, megjithatë, RIB përdor mekanizmin për gjenerimin e një nënshkrimi dixhital. të versionit të konfigurimit (në vijim, do ta quaja shkurtimisht hash), dhe kur pjesa e aplikacionit ndryshon, hash-i duhet të rillogaritet natyrshëm. Këtë nuk do ta mohoj, as pohoj, sepse. nëse ballafaqohesha me këtë situatë, atëherë nuk gjeta prova të qarta për këtë.
Unë përdor 2 metoda për ta rregulluar atë, në varësi të situatës.
METODA E PARË
E para (më e zakonshme) përmendet vazhdimisht si në konferencën e partnerit ashtu edhe në burime të tjera të Internetit që lidhen me 1C. Përdoret në shumicën e rasteve, kur pavarësisht mesazhit për mospërputhjet e konfigurimeve, kur krahasohen manualisht, duket se ato janë identike.
Renditja:
- shkarkoj dosjen cf nga Banka Qendrore;
- ne e zgjidhim UB-në nga RIB (metoda SetMainNode, përpunimi i gatshëm mund të gjendet në aplikacion ose në botime të tjera);
- zëvendësoj conf. UB në skedarin cf të shkarkuar në hapin e parë, për këtë përdorim menynë "Konfigurimi i ngarkimit nga skedari" (dhe jo nga krahasimi-bashkimi !!!);
- le të rivendosim shenjën e RIB për UB.
Në shumicën e rasteve, këto veprime janë më se të mjaftueshme për të rivendosur shkëmbimin, por jo gjithmonë...
METODA E DYTË
Përdoret nëse metoda e parë nuk funksionoi dhe nuk është e mundur të shkarkohet përsëri nyja.
Sfondi: klienti po krijonte një RIB kaskadë dhe ndodhi një gabim në nivelin e parë të kaskadës (niveli i dytë funksionoi pa të meta gjatë gjithë kësaj kohe). Konfigurimi është zhvilluar së bashku me shërbimin e IT të klientit dhe që kur ka ndodhur gabimi, konfigurimi CB ka ndryshuar disa herë. Opsioni i rikthimit të ndryshimeve as që u konsiderua në parim, sepse humbja e një pjese të të dhënave dhe mbyllja e disa departamenteve ishin krejtësisht të papranueshme. Versioni i parë i korrigjimit të gabimit nuk dha ndonjë rezultat të prekshëm. Si rezultat, duheshin gjetur zgjidhje të tjera.
Ideja erdhi në përpjekje për të ndryshuar hash-et e skedarëve të konfigurimit direkt në skedarët e shkëmbimit XML. Përshkrimi i strukturës së skedarit të shkëmbimit nga libri "Zhvillimi profesional në sistemin 1C: Enterprise 8" dha një ide të dobët për formimin e nënshkrimeve dixhitale të konfigurimeve dhe ndryshimeve në to, por përcaktoi drejtimin e kërkimit: Vlerat Digest1 dhe Digest2. Unë kuptova gjithçka tjetër thjesht në mënyrë empirike (d.m.th., me provë dhe gabim), por arrita të krijoj një model.
Eksperimentet e testimit shkuan mirë. Edhe në baza, gjithçka shkoi mirë.
Pra, sekuenca e veprimeve:
- kryeni hapat 1 - 4 të teknikës së parë;
- shkarkoni skedarin e shkëmbimit nga UB, por mos e ngarkoni atë në CB;
- shkarkoni skedarin e këmbimit nga Banka Qendrore, por mos e ngarkoni atë në UB;
- në skedarin e shkëmbimit nga CB, ne zëvendësojmë bllokun që përmban informacione rreth ndryshimeve të konfigurimit dhe hasheve (Digest1 dhe Digest2) me një bllok hashesh nga skedari UB (shih një shembull më poshtë)
- ne ngarkojmë skedarin nga pika e 4-të në UB;
- sigurohuni që të mbishkruani skedarin e shkëmbimit nga UB (paragrafi 2)! ky skedar nuk duhet të ngarkohet gjatë shkëmbimit në CB!
- për të kontrolluar, ne bëjmë disa shkëmbime të njëpasnjëshme.
Nëse kompresimi i të dhënave përdoret gjatë shkëmbimit, atëherë ose çaktivizoni kompresimin, ose së pari shpaketoni skedarin, ndryshoni atë, pastaj paketoni përsëri dhe dërgojeni.
Blloko shkëmbimin e skedarëve nga CB
...këtu janë blloqe që përshkruajnë ndryshimet e konfigurimit...
Duhet të zëvendësohet me një bllok të skedarit të këmbimit nga UB (shënimi Digest1 i skedarit nga UB është gjithmonë "0000000000000000000000000000000000" !!!)
Veprimet e listuara duhet të kryhen me kujdes ekstrem, një sekuencë e pasaktë është e mbushur me mosfunksionim të plotë të RIB. Prandaj, para këtyre veprimeve, krijimi i kopjeve rezervë është i detyrueshëm!
Përndryshe, nuk mund të të uroj vetëm fat!
Pyetje: Gabim i përditësimit të nyjës RIB
Mirembrema.
Përditësoi nyjen kryesore Rarus-Retail në 2.2.5.27, bëri një shkëmbim me disa nyje RIB - gjithçka është në rregull.
Fillova një përditësim masiv të nyjeve të mbetura (i ngjashëm me "çiftin kryesor" (dyqane të tjera në RIB)) - shfaqet një gabim në anën e klientit:
Shpërndarja e raporteve. Të dhënat e regjistrimit për përditësimin e listës së detyrave të planifikuara"
mbajtës i përditësimit të shtyrë
"Shpërndarja e raporteve. Përditëso listën e detyrave të planifikuara"
Një gabim ka ndodhur:
"(GeneralModule.GeneralPurpose.Module(3502)): Gabim gjatë thirrjes së metodës së kontekstit (Përmban)
Kthehu Metadata.InformationRegisters.Contains(MetadataObject);
për arsye të:
Lloji mospërputhje (numri i parametrit "1")".
A mund të hasë dikush? Unë kam provuar tashmë të përditësoj platformën (deri në maksimum 8.3.10, dhe e kontrollova atë në 32-64 kompjuterë) ... nuk më ndihmoi. Por në fund të fundit, dyqanet e testit 2 u përditësuan pa probleme, nuk mund ta kuptoj se si.
Përgjigje:() Kështu instaloj nyjen kryesore. Kam shkruar pak për diçka tjetër: pasi ta zgjidhësh nyjen duke përpunuar, herën tjetër që e nis, përditësimi i konf nuk fillon menjëherë, por së pari 1C hap një dritare në të cilën të kërkon të konfirmosh që nyja është duke u shkëputur . Pas kësaj, ajo përditësohet - pas përditësimit, nyja nuk është më në listë.
Në fakt, në 2.1, mbaj mend që e përditësova duke përdorur këtë metodë, por diçka nuk u ngrit në 2.2. Ndoshta, në park, ai tashmë ka vendosur sekuencën e gabuar në veprime)
SIPAS TEMAVE:
Kuptoi se çfarë është. Doli që ai shpërfilli:
"Në një nga publikimet 2.2, u shfaq një direktori duke shpërndarë raporte me element i paracaktuar"Të dhënat personale" - një direktori me këtë element ishte gjithashtu në 2.1.
Nuanca është kjo: bllokimet me nyje përditësuese vërehen në ato baza që u krijuan nga ajo qendrore pikërisht në lëshimin 2.1.9.18. Gjithçka që u krijua në versionet e mëparshme u përditësua normalisht. Kjo, me siguri, shpjegon pse disa baza për TS u përditësuan gjithashtu me sukses, dhe më pas bllokimet shkuan.
Nuk kam shpikur asgjë me krijimin e një elementi të ri në drejtori dhe vendosjen e tij si të paracaktuar. Ky element u transferua nga kopja e qendrës në 2.1 përmes shkarkimit/ngarkimit të XML dhe përsëriti përditësimin në "bazën" problematike - gjithçka shkoi mirë.
() Pra, përdorni metodën nëse nuk e keni gjetur ende përgjigjen.
Pyetje: Gabim i përditësimit të konfigurimit
Po përditësoj konfigurimin e Kontabilitetit 2.0.64.14 në 2.0.64.24. platforma 8.2.19
Një gabim ndodh menjëherë:
Gabim gjatë qasjes në skedar... shteg... skedar i përkohshëm.tmp.
Ku të shikoni?
Përgjigje: e zgjidhi atë problem duke pritur për një lëshim të ri "të qëndrueshëm".
Pyetje: Gabim në të drejtat e përdoruesit në BSP
pershendetje!!! Unë po shkruaj një konf bazuar në BSP 2.2, duket se tashmë kam përvojë dhe kam studiuar doket lart e poshtë, por herën e parë që nis IB, ndodh një gabim:(CommonModule.UsersService.Module(345)): Autorizimi dështoi. Sistemi do të mbyllet.
Përdoruesi: Administratori nuk u gjet në drejtorinë "Përdoruesit".Ndodhi një gabim gjatë përpjekjes për të shtuar një përdorues në drejtori:
"Përditësimi i bazës së informacionit dështoi.
Parametri i kufizimit të hyrjes nuk plotësohet:
"Të drejtat e mundshme për vendosjen e të drejtave të objektit".Për zhvilluesin: mund t'ju duhet të përditësoni të dhënat mbështetëse,
që ndikojnë në funksionimin e programit. Për të kryer një përditësim, mund të:
- perfitoj përpunimi i jashtëm
"Mjetet e zhvilluesit: Përditëso të dhënat e mbështetjes",
- ose ekzekutoni programin me parametrin linja e komandës 1C: Ndërmarrja 8
"/C Fillimi i përditësimit të bazës së informacionit",
- ose rrisni numrin e versionit të konfigurimit në mënyrë që në fillimin tjetër
kanë përfunduar procedurat për përditësimin e të dhënave të infobazës."Klikoni për të zbuluar...
Do të doja të dëgjoja përgjigjet e "me përvojë", për një dialog aktiv të mëvonshëm, ndoshta edhe bashkëpunim
Përgjigje:
vdeg ka thënë:
Problemi u zgjidh?
Unë kam një problem të një plani tjetër: unë shtoj një përdorues në BSP 2.2.5.29 dhe ai ose ka të drejta të plota (nëse i shtoni ato manualisht) ose asnjë (shikon një ndërfaqe boshe pa direktorium i vetëm dhe dokument). Sepse në rolet tipike të BSP nuk ka fare kuti kontrolli për të hyrë në drejtoritë dhe dokumentet specifike (të miat). Si atëherë do të gjurmohet qasja në nivel rekord për përdoruesin e ri???
Klikoni për të zbuluar...
Dhe si duhet të zbulojë BSP se çfarë lloj drejtorish keni dhe si dëshironi të konfiguroni aksesin në to?
Ndoshta duhet ta bëjmë vetë.
Pyetje: SendingDeliverableNotified Verifikimi i hostit në distancë dështoi
Deri të premten e kaluar, kodi i mëposhtëm funksionoi mirë..
XdtoSubscriber = XDTO Factory.Create(XDTO Factory.Type(";));
xdtoSubscriber.DeviceID = ID e pajisjes;
xdtoSubscriber.SubscriberType = XDTO Factory.Create(XDTO Factory.Type(";), "GCM");
NewXDTO Serializer = Serializer i ri XDTO (Fabrika XDTO);
Subscriber = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
Njoftim=Njoftim i ri i dorëzueshëm;
Njoftimi.Marrësit.Add(Abonent);
Njoftim.Text=Tekst;
Notification.SoundAlert=SoundAlert.Default;
Njoftim.Sticker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Njoftim,AuzData,True);
Tani gabimi është Vërtetimi i dështuar i hostit në distancë. Ma theu gjithë kokën. Kam kapur thirrjet e serverit - ndihet bosh që nuk kthehet askund ... Provova tre makina të ndryshme me akse të ndryshme. i rraskapitur.. ndihmë...
Përgjigje: Lart
Përgjigje: Kështu, vendosa të bëj përsëri imazhin e nyjës. Kur fillon nyjen, ai thotë se duhet të fillohet me \c për të filluar përditësimin e bazës së informacionit
dhe ri-imazhi.
Rezulton se kjo është diçka për shkak të një përditësimi të gabuar.
Unë u përpoqa të ekzekutoja me këtë çelës dhe të bëja një shkëmbim me një nyje ekzistuese. Asnjë përditësim nuk u nis në nyje, asgjë nuk u kërkua të rifillohej.
Dhe si rezultat, në nyjen kryesore, mesazhi nuk u pranua përsëri me të njëjtin gabim.
Çfarë mund të bëhet?
A mund të ndryshojë diçka fiktive në nyjen kryesore në konf dhe të bëjë një shkëmbim? Apo nuk do të përditësojë të gjithë konficionin, por vetëm atë që unë do të ndryshoj? Do të përpiqem të krijoj një nyjë tani për tani. Por unë do të pres për idetë tuaja.
Pyetje: Baza e të dhënave të shpërndara - gabimi gjatë shkëmbimit nuk eliminohet
Ditë të mbarë për të gjithë!
Situata është si vijon.
Kur ngarkoj një shkëmbim nga një nyje periferike, marr mesazhin "Konfigurimi i nyjës IS të shpërndarë nuk përputhet me atë të pritur".
Pastaj ndjek udhëzimet.
Unë shkarkoj konfigurimin nga baza e të dhënave qendrore në CF, zgjidh bazën e të dhënave periferike nga nyja qendrore duke përpunuar, heq konfigurimin në bazën e të dhënave periferike nga mbështetja, ngarkoj konfigurimin nga një skedar.
Unë lidh nyjen qendrore në bazën e të dhënave periferike duke përpunuar.
Ruaj, apliko.
Unë shkarkoj edhe një herë shkëmbimin nga baza e të dhënave qendrore.
Unë ngarkoj në periferik. Unë shkarkoj shkëmbimin nga baza e të dhënave periferike.
Ngarkimi në qendër. Përsëri marr mesazhin "Konfigurimi i nyjës IS të shpërndarë nuk përputhet me atë të pritur".
Por kjo është një marrëzi e vërtetë - e ngarkoj konfigurimin në bazën e të dhënave qendrore dhe askush nuk e ndryshoi konfigurimin në bazën e të dhënave periferike.
Si të kapërceni një gabim të tillë?
Përgjigje: Askujt nuk i ka shkuar kurrë në mendje të këshillojë gjëra kaq të dukshme pas shumë vitesh sharje për përditësimin demonik :)
Pyetje: RIB dhe përditësimet
Pershendetje te gjitheve. Është planifikuar të përdoret siguria e informacionit të shpërndarë.
konfigurimi ka ndryshuar. Përditësimi i konfigurimit të bazës së të dhënave qendrore kryhet nga programuesi. Më pas, me skedarët e shkëmbimit, këto ndryshime do të transferohen në bazat e të dhënave periferike.
Pyetja është: po në lidhje me nisjen e mbajtësve pas përditësimit të konfigurimit të bazës së të dhënave dhe hyrjes së parë në modalitetin e përdoruesit?
përditësimi i konfigurimit kryesor - përditësimi i konfigurimit të bazës së të dhënave - ekzekutimi i mbajtësve të përditësimeve në modalitetin e përdoruesit
Për shembull, shumë lëshime kanë munguar, ju duhet të përmirësoni në mënyrë sekuenciale për të përmirësuar në 3 lëshime. Nuk ka probleme me përditësimin e bazës së të dhënave qendrore, por çfarë ndodh me ato periferike? Është gjithashtu e nevojshme t'i përditësoni ato në 3 faza (përditësoni bazën e të dhënave qendrore me versionin e parë, përditësoni RIB, përditësoni bazën e të dhënave qendrore me lëshimin e dytë, përditësoni RIB, etj.?)
Faleminderit të gjithëve për ndihmën tuaj!
Përgjigje:() fut hundën, nuk mund të gjej kodin që ekzekutohet kur regjistrohen ndryshimet e objektit.
Duket se nëse përdorni metodën OnSendingData, atëherë nyja kryesore do të grumbullojë akoma objekte të ndryshuara për t'i dërguar në nyjen skllav. Dhe këto janë burime shtesë kompjuterike
Prandaj, dua që objektet në nyjen kryesore të mos regjistrohen për dërgim menjëherë në momentin e ndryshimit të tyre (Për shembull, On Write). Në cilin vend, për shembull, në standardin e Kontabilitetit rev. 3, janë regjistruar këto objekte për dërgim?
Pyetje: [ZGJIDHUR] Gabim gjatë kontaktimit me mbështetjen në internet
Të dashur ekspertë, më tregoni, ju lutem!
1C: Ndërmarrja 8.3 (8.3.11.2899)
Disa baza të dhënash të konfigurimeve të ndryshme po rrotullohen në serverin 1C, në të gjitha mbështetja e Internetit është e lidhur dhe funksionon mirë. Përfshirë ngarkimi i kurseve të këmbimit, bankave, kundërpalëve kontrolluese, SPARK, etj.
Cilësimet e proxy janë të njëjta për të gjitha bazat e të dhënave.
Por në bazat e të dhënave BP-3 CORP, gjithmonë ndodh një gabim:Në regjistrin e regjistrimit:
Marrja e një bilete vërtetimi në shërbim dështoi.
Ngarkimi i përmbajtjes (). (GeneralModule.InternetUserSupportClientServer.Module(362)): Gabim gjatë thirrjes së metodës së kontekstit (SendToProcess)
Response = Connection.SendForProcessing(HTTPRequest, ReceiveParameters.ResponseFileName);
për arsye të:
Gabim në internet: Autentifikimi i hostit në distancë dështoiKlikoni për të zbuluar...
E provova versione të ndryshme platformat (8.3.10..., 8.3.11...), dhe në versione të ndryshme të konfigurimit (3.0.54.15, 3.0.57.10).
Testimi dhe rregullimi nuk ndihmon as.
Çfarë mund të jetë e gabuar?
A shkon disi BP-CORP në internet në një mënyrë të veçantë?
Faleminderit.
Përgjigje:
Përgjigja nga 1C (ajo që është theksuar me të kuqe më ndihmoi):Gjatë tranzicionit, BSP u përditësua si pjesë e PB nga 2.4.3 në 2.4.4
Në listën e ndryshimeve në BSP 2.4.4
Siguria e përmirësuar kur krijoni një lidhje të sigurt me shërbimet e internetit HTTPS. Pas zbulimit probleme të ndryshme me certifikatën e shërbimit të internetit me të cilin po tentohet një lidhje e sigurt (certifikata jo e vlefshme, e vjetëruar ose e pabesueshme), lidhja nuk do të krijohet.
Në 8.3.10, verifikimi i certifikatës në Windows kryhet duke përdorur sistemi operativ." -
Instaloni përditësimet më të fundit për OS tuaj, Ato përmbajnë përditësime të rëndësishme komponentët e sistemit, të cilat janë përgjegjëse për punën me certifikatat.
Ju lutemi instaloni gjithashtu përditësimi më i fundit Certifikatat rrënjësore të shpërndara nga Microsoft në paketa të instalueshme.
Kërkon një version të të paktën IE8.0. Ai përmban përditësime të rëndësishme për komponentët e sistemit që janë përgjegjës për të punuar me certifikatat.
Si rregull, pas instalimit të të gjitha përditësimeve, problemi zgjidhet.
Kontrolloni që nëse futni në shiritin e kërkimit në Internet Explorer, lidhja të hapet.
Përdoruesi në emër të të cilit punoni ka akses në internet.
Nëse kjo është një bazë të dhënash skedari në makinën e klientit, duhet të kontrollohet në të.
Nëse kjo është një bazë të dhënash klient-server, atëherë në serverin nën përdoruesin nën të cilin po funksionon serveri 1C.
Kontrolloni vetëm me shfletuesin IE.
Kontrolloni që portat 443 dhe 80 të jenë të hapura
Nëse jeni duke përdorur një Proxy Server, kontrolloni nëse të dhënat në menynë Personal Settings janë të konfiguruara.
Nëse përdoret versioni klient-server, atëherë duhet ta konfiguroni serverin në mënyrë të tillë që lidhja e internetit me shfletuesin IE të funksionojë siç duhet në të nën përdoruesin në emër të të cilit funksionon serveri 1C.
Kam regjistruar përfaqësuesin në cilësimet IE të përdoruesit nën të cilin po funksionon serveri 1C - gjithçka funksionoi.
Pyetje: Përditëso boo 3
Diten e mire
Kontabiliteti 3
bëri një përditësim nga 3.0.43.208 në 3.0.43.235
gabimet
së pari
(GeneralModule.MessagingInternal.Module(381)): Gabim gjatë thirrjes së metodës së kontekstit (ThisNode)
për arsye të:
U gjetën më shumë se një hyrje
e dyta
Kur telefononi mbajtësin e përditësimeve:
"MessagingInternal.SetThisEndPointCode()"
Një gabim ka ndodhur:
"(GeneralModule.MessagingInternal.Module(381)): Gabim gjatë thirrjes së metodës së kontekstit (ThisNode)
ReturnInterchangePlans.MessageExchange.ThisNode();
për arsye të:
U gjetën më shumë se një rekord."Platforma e nderuar e shkrimit nuk mund të provohet në versione të ndryshme të platformave
u përpoq të merrte një konficion të pastër Versioni i fundit dhe thjesht marrëzi e plotë zëvendësimin për të ngarkuar
nuk ndihmoi fare, gjithmonë e njëjta gjë. Më thuaj papritmas kush e ka hasur?
Përgjigje:
nyja nga e vërteta në e gabuar
Po ngarkohet...