Dynamische updatefouten (of andere platformstoringen) kunnen de oorzaak zijn van fouten bij het uitwisselen van gedistribueerde infobases:
"Er worden gegevens ontvangen van het knooppunt waarvoor de configuratiewijzigingen zijn geregistreerd"
"De configuratie van het gedistribueerde IS-knooppunt komt niet overeen met de verwachte"
Hoe een uitwisseling herstellen?
Maar laten we niet beginnen met de restauratie, maar met de mogelijkheid om over te voerenbmen "handmatig", wat overdag belangrijk is, want zoals altijd zou alles "gisteren" moeten werken :) Dit kan met behulp van prachtige behandelingen die ik me niet herinnerwaar ik het heb gedownload (auteurs, reageer - ik zal links naar uw bron achterlaten en van de mijne, indien nodig, zal ik verwijderen). Verwerking maakt het mogelijk om alleen geregistreerde gegevenswijzigingen in de database (volgens het opgegeven uitwisselingsplan voor een specifiek knooppunt!) in XML te uploaden zonder configuratiewijzigingen te uploaden en, als de configuratieobjecten niet veel zijn veranderd, dan is de kans zeer groot het laden van deze gegevens. Deze kunnen worden gedownload via de link aan het einde van het artikel.
Wat betreft het herstel. Er zijn eenvoudigere methoden die niet alle items in de onderstaande lijst bevatten, maar ze helpen niet altijd, zoals bijvoorbeeld in een van mijn gevallen. Daarom noem ik de methode die me heeft geholpen; het omzeilt mogelijke problemen op een meer omvattende manier. Stap voor stap verder.
Het is raadzaam om deze stappen te nemen als er geen werkende gebruikers in de database zijn. Als dit niet mogelijk is, moet je de methode voor jezelf "afmaken", en daarom moet je eerst de logica ervan begrijpen.
1. Maak overal back-ups.
2. Voor client-servers: koppel de databases los via "serverbeheer" en verbind ze onmiddellijk met de instelling van het blokkeren van geplande taken (hierdoor wordt de servercache gereset). Vergeet daarna niet om het registratielogboek naar de nieuwe map over te brengen.
3. Op alle computers die voor herstel worden gebruikt, verwijdert u de basis in de lijst met 1C-starterbases en maakt u een nieuwe (de cache van de gebruiker wordt gewist)
4. Voeg in de configurator (in de centrale database) een nieuwe constante toe om de wijzigingen in de conf.
5. Wis alle uitwisselingsmappen.
6. Maak lossen naar alle vestigingen (voorlopig alleen lossen).
7. Probeer de ontvangen gegevens naar alle vestigingen te downloaden (alleen downloaden). Het is normaal om de wijzigingen in de configuratie te accepteren.
Als alles overal goed is, gaan we verder, als alles slecht is, denken we dat het misschien zal helpen om.cf van de centrale basis en zijn UPLOAD naar de vertakking (niet vergelijkend samenvoegen) te lossen. In het slave-knooppunt moet u de basis losmaken van de RIB (verwerking zal hierbij helpen - download via de onderstaande link). Een artikel over dit onderwerp is beschikbaar op infostart.ru.
8. Wij annuleren de registratie van wijzigingen voor vestigingen bij de Centrale Bank (we hebben alle wijzigingen immers al overal ontvangen). Het is belangrijk om in dit stadium te doen, zodat de verzamelde wijzigingen van verschillende takken naar andere takken gaan. (downloadverwerking voor unbind-bind via de onderstaande link).
9. We uploaden naar de Centrale Bank en als alles goed is, uploaden en downloaden we met elk filiaal meerdere keren om het resultaat te consolideren.
10. Alles.
U kunt de uitvoering van geplande taken in client-serverdatabases inschakelen.
Om problemen te voorkomen die deze fout veroorzaken, wordt het aanbevolen om geen dynamische update uit te voeren (minstens meerdere keren achter elkaar - voordat de wijzigingen in de takken worden gedownload), en het is ook raadzaam om het vakje "gegevens alleen uploaden na succesvolle download" aan te vinken " in de uitwisselingsinstellingen.
Eerst een lijst met gebruikte afkortingen:
- RIB - gedistribueerde informatiebank
- Centrale Bank - centrale basis, RIB-rootknooppunt
- UB - externe basis, database van het externe RIB-knooppunt
Uit eigen ervaring kan ik zeggen dat ik twee redenen voor de fout ben tegengekomen:
- tijdens de ontvangst van het berichtenbestand in de UB is de basis "gevallen", waarbij er blijkbaar een missynchronisatie was tussen de conf. Centrale Bank en UB;
- onder MSSQL heeft de client een kopie van de werkende database gedownload en deze niet uitgeschakeld in de kopie van de regl. automatische uitwisselingstaken, als resultaat werden sommige berichten naar externe knooppunten gegenereerd vanuit de werkende database en sommige vanuit een kopie, wat leidde tot desynchronisatie van configuraties
Er is ook een mening dat deze fout wordt veroorzaakt door het gebruik van het dynamische database-updatemechanisme. Er zijn hier twijfels, omdat enerzijds dynamische update nooit de databasestructuur aantast, en de RIB-mechanismen nog steeds werken met de databasestructuur, en niet met het toegepaste deel, niettemin gebruikt de RIB een mechanisme voor het genereren van een digitale handtekening van de configuratieversie (in het vervolg noem ik het hash voor verkorting), en wanneer het toegepaste deel verandert, moet de hash natuurlijk opnieuw worden berekend. Ik zal het niet ontkennen, noch beweren, tk. als ik deze situatie tegenkwam, vond ik daar geen duidelijk bewijs van.
Voor correctie gebruik ik 2 technieken, afhankelijk van de situatie.
EERSTE METHODE
De eerste (meest voorkomende) wordt herhaaldelijk genoemd, zowel in de partnerconferentie als op andere internetbronnen met betrekking tot 1C. Het wordt in de meeste gevallen gebruikt wanneer, ondanks de melding over verschillen in configuraties, handmatige vergelijking aantoont dat ze identiek zijn.
Volgorde aanbrengen in:
- we lossen het cf-bestand op bij de centrale bank;
- we maken de UB los van de RIB (de SetMainNode-methode, de voltooide verwerking is te vinden in de bijlage of in andere publicaties);
- vervang conf. UB naar het cf-bestand dat in de eerste stap is verwijderd, hiervoor gebruiken we het menu "Configuratie laden uit bestand" (en niet ter vergelijking-merge !!!);
- we herstellen het RIB-bord voor UB.
In de meeste gevallen zijn deze acties meer dan voldoende om de uitwisseling te herstellen, maar niet altijd ...
TWEEDE METHODE:
Het wordt gebruikt als de eerste techniek niet werkte en het niet mogelijk is om het knooppunt opnieuw te ontladen.
Achtergrond: de klant had een cascade-RIB en er is een fout opgetreden in het eerste niveau van de cascade (het tweede niveau werkte al die tijd foutloos). De ontwikkeling van de configuratie is uitgevoerd in samenwerking met de IT-service van de klant en sinds de fout is opgetreden, is de configuratie van de centrale bank verschillende keren gewijzigd. De optie om wijzigingen terug te draaien werd zelfs in principe niet overwogen, aangezien het verlies van een deel van de gegevens en de sluiting van verschillende afdelingen waren volstrekt onaanvaardbaar. De eerste optie om de fout te herstellen gaf geen tastbare resultaten. In dit verband moest ik op zoek naar andere oplossingen.
Ik kwam op het idee om te proberen de hashes van de configuratiebestanden rechtstreeks in de XML-uitwisselingsbestanden te vervangen. De beschrijving van de structuur van het uitwisselingsbestand uit het boek "Professionele ontwikkeling in het 1C: Enterprise 8-systeem" gaf een slecht idee van de vorming van digitale handtekeningen van configuraties en wijzigingen daarin, maar bepaalde de richting van de zoekopdracht: de waarden van Digest1 en Digest2. Ik ontdekte de rest puur empirisch (dat wil zeggen met vallen en opstaan), maar ik slaagde erin een patroon vast te stellen.
Testexperimenten waren succesvol. Ook op de werkvloer ging alles goed.
Dus de volgorde van acties:
- we voeren stappen 1 - 4 van de eerste techniek uit;
- we halen het uitwisselingsbestand uit de UB, maar uploaden het niet naar de Centrale Bank;
- we halen het uitwisselingsbestand uit de Centrale Bank, maar laden het niet in de UB;
- vervang in het uitwisselingsbestand van de Centrale Bank het blok met informatie over configuratiewijzigingen en hashes (Digest1 en Digest2) door een blok hashes uit het UB-bestand (zie voorbeeld hieronder)
- we downloaden het bestand van het 4e punt naar de UB;
- overschrijf zeker het uitwisselingsbestand van de UB (2e punt)! dit bestand mag niet worden geüpload bij het uitwisselen in de Centrale Bank!
- om te controleren, doen we verschillende opeenvolgende uitwisselingen.
Als gegevenscompressie wordt gebruikt tijdens de uitwisseling, schakel dan de compressie uit of pak het bestand eerst uit, wijzig het, pak het dan in en verzend het.
Exchange-bestandsblok van de Centrale Bank
... er zijn blokken die configuratiewijzigingen beschrijven ...
je moet het vervangen door het blok van het uitwisselingsbestand van de UB (merk op dat Digest1 van het bestand van de UB altijd "000000000000000000000000000000000000" is!!!)
De vermelde acties moeten met uiterste voorzichtigheid worden uitgevoerd, een onjuiste volgorde is beladen met de volledige onbruikbaarheid van de RIB. Daarom is het maken van back-ups vóór deze stappen VERPLICHT!
