Vraag: RIB node update fout
Goedemiddag.
Het belangrijkste Rarus-Retail-knooppunt bijgewerkt naar 2.2.5.27, een uitwisseling gemaakt met een paar RIB-knooppunten - alles is in orde.
Ik ben begonnen met een massale update van de resterende knooppunten (vergelijkbaar met het "toppaar" (andere winkels in RIB)) - er verschijnt een fout aan de clientzijde:
Distributie van rapporten. Registreer gegevens voor het bijwerken van de lijst met geplande taken"
uitgestelde update-handler
"Distributie van rapporten. Werk de lijst met geplande taken bij"
Er is een fout opgetreden:
"(GeneralModule.GeneralPurpose.Module(3502)): Fout bij aanroepen van contextmethode (bevat)
Retourneer Metadata.InformationRegisters.Contains(MetadataObject);
omdat:
Typ mismatch (parameternummer "1").
Kan iemand tegen komen? Ik heb al geprobeerd het platform bij te werken (tot het maximum 8.3.10, en gecontroleerd op 32-64 computers) ... het heeft niet geholpen. Maar test 2-winkels zijn tenslotte zonder problemen bijgewerkt, ik begrijp niet hoe.
Antwoord:() Dit is hoe ik het hoofdknooppunt installeer. Ik schreef iets anders over iets anders: nadat je het knooppunt hebt losgemaakt door verwerking, start de conf-update de volgende keer dat je het start niet onmiddellijk, maar eerst opent 1C een venster waarin het je vraagt om te bevestigen dat het knooppunt wordt ontbonden . Daarna wordt het bijgewerkt - na de update staat het knooppunt niet meer in de lijst.
Op 2.1 herinner ik me zelfs dat ik het met deze methode heb bijgewerkt, maar iets ging niet van de grond op 2.2. Misschien heeft hij in het park al de verkeerde volgorde in acties geprikt)
PER ONDERWERP:
Begrepen wat is. Het bleek dat hij over het hoofd had gezien:
"In een van de 2.2 releases verscheen een Report Distribution-directory met een vooraf gedefinieerd element "Persoonlijke gegevens"" - een directory met dit element stond ook op 2.1.
De nuance is deze: stijlen met updateknooppunten worden waargenomen op die bases die precies bij release 2.1.9.18 vanuit de centrale zijn gemaakt. Alles wat in eerdere releases is gemaakt, is normaal bijgewerkt. Dit verklaart waarschijnlijk waarom een paar bases voor de TS ook met succes werden bijgewerkt, en toen gingen de stijlen weg.
Ik heb niets uitgevonden met het maken van een nieuw element in de map en het instellen als vooraf gedefinieerd. Dit element overgebracht van de kopie van het centrum naar 2.1 via het ontladen/laden van XML en de update op de problematische "basis" herhaald - alles ging goed.
() Gebruik dus de methode als je het antwoord nog niet hebt gevonden.
Vraag: Configuratie-updatefout
Ik werk de configuratie van Boekhouding 2.0.64.14 bij naar 2.0.64.24. platform 8.2.19
Er treedt onmiddellijk een fout op:
Fout bij toegang tot bestand... pad... tijdelijk bestand.tmp.
Waar moet je kijken?
Antwoord: loste dat probleem op door te wachten op een nieuwe "stabiele" release
Vraag: Fout in gebruikersrechten op de BSP
Groeten!!! Ik ben een conf aan het schrijven op basis van BSP 2.2, het lijkt erop dat ik al ervaring heb en de docks op en neer heb bestudeerd, maar de eerste keer dat ik IB start, treedt er een fout op:(CommonModule.UsersService.Module(345)): Autorisatie mislukt. Het systeem wordt uitgeschakeld.
Gebruiker: de beheerder is niet gevonden in de map "Gebruikers".Er is een fout opgetreden bij het toevoegen van een gebruiker aan de directory:
"Infobase-update mislukt.
De parameter toegangsbeperking is niet gevuld:
"Mogelijke rechten voor het instellen van objectrechten".Voor de ontwikkelaar: u moet mogelijk de ondersteunende gegevens bijwerken,
die de werking van het programma beïnvloeden. Om een update uit te voeren, kunt u:
- gebruik externe verwerking
"Ontwikkelaarstools: ondersteuningsgegevens bijwerken",
- ofwel voer het programma uit met de opdrachtregelparameter 1C:Enterprise 8
"/C Startupdating Infobase",
- ofwel het versienummer van de configuratie verhogen zodat bij de volgende start
de procedures voor het bijwerken van de infobase-gegevens zijn voltooid."Klik om te onthullen...
Ik hoor graag de antwoorden van de "ervaren", voor een volgende actieve dialoog, misschien zelfs samenwerking
Antwoord:
vdeg zei:
Probleem opgelost?
Ik heb een probleem met een ander plan: ik voeg een gebruiker toe aan BSP 2.2.5.29 en hij heeft ofwel volledige rechten (als je ze handmatig toevoegt), of helemaal geen (ziet een lege interface zonder een enkele map en document). Omdat er in typische BSP-rollen helemaal geen selectievakjes zijn voor toegang tot specifieke (mijn) mappen en documenten. Hoe zal dan de toegang op recordniveau voor de nieuwe gebruiker worden getraceerd???
Klik om te onthullen...
En hoe moet de BSP erachter komen wat voor mappen u heeft en hoe u de toegang daartoe wilt configureren?
Waarschijnlijk moeten we het zelf doen.
Vraag: VerzendenDeliverableNotified De verificatie van de externe host is mislukt
Tot afgelopen vrijdag werkte de volgende code prima..
XdtoSubscriber = XDTO Factory.Create(XDTO Factory.Type(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = XDTO Factory.Create(XDTO Factory.Type(";), "GCM");
NewXDTO-serializer = Nieuwe XDTO-serializer (XDTO-fabriek);
Abonnee = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
Notification=Nieuwe DeliverableNotification;
Melding.Ontvangers.Toevoegen (abonnee);
Notification.Text=Tekst;
Notification.SoundAlert=SoundAlert.Default;
Opmerking.Sticker=1;
DATAAuz=TOKEN;
VerzendenDeliverableNotifications.Send (Notification,AuzData,True);
Nu is de fout validatie van externe host mislukt. Mijn hele hoofd gebroken. Ik heb serveroproepen opgevangen - het voelt leeg dat het nergens heen gaat ... Ik probeerde op drie verschillende machines met verschillende assen. uitgeput.. help...
Antwoord: Omhoog
Antwoord: Dus besloot ik de knooppuntafbeelding opnieuw te maken. Bij het starten van het knooppunt zegt het dat het moet worden gestart met \c om te beginnen met het bijwerken van de infobase
en opnieuw in beeld brengen.
Het blijkt dat dit iets is vanwege een scheve update.
Ik heb geprobeerd om met deze sleutel te werken en een uitwisseling te maken met een bestaand knooppunt. Er zijn geen updates gestart in het knooppunt, er is niets gevraagd om opnieuw te worden gestart.
En als gevolg daarvan werd het bericht in het hoofdknooppunt opnieuw niet geaccepteerd met dezelfde fout.
Wat gedaan kan worden?
Kan fictief iets in het hoofdknooppunt in de conf worden gewijzigd en een uitwisseling maken? Of zal hij niet de hele conf updaten, maar alleen wat ik zal veranderen? Ik zal proberen een knoop te maken voor nu. Maar ik wacht op je ideeën.
Vraag: Gedistribueerde database - de fout tijdens de uitwisseling wordt niet geëlimineerd
Goedendag aan iedereen!
De situatie is de volgende.
Bij het laden van een centrale vanaf een randknooppunt krijg ik de melding "De configuratie van het gedistribueerde IS-knooppunt komt niet overeen met de verwachte".
Dan volg ik de instructies.
Ik ontlaad de configuratie van de centrale database naar CF, maak de perifere database los van het centrale knooppunt door verwerking, verwijder de configuratie in de perifere database uit de ondersteuning, laad de configuratie uit een bestand.
Ik bind het centrale knooppunt in de perifere database door verwerking.
Opslaan, toepassen.
Ik ontlaad de centrale opnieuw uit de centrale database.
Ik laad in het randapparaat. Ik ontlaad de centrale uit de perifere database.
Uploaden naar centraal. Opnieuw krijg ik de melding "De configuratie van het gedistribueerde IS-knooppunt komt niet overeen met de verwachte".
Maar dit is echte onzin - ik laad de configuratie in de centrale database en niemand heeft de configuratie in de randdatabase gewijzigd.
Hoe een dergelijke fout te verhelpen?
Antwoord: het kwam nooit bij iemand op om zulke voor de hand liggende dingen te adviseren na vele jaren vloeken bij de demonische update :)
Vraag: RIB en updates
Hallo. Het is de bedoeling om gedistribueerde informatiebeveiliging te gebruiken.
configuratie gewijzigd. Het bijwerken van de configuratie van de centrale database wordt uitgevoerd door de programmeur. Vervolgens worden deze wijzigingen met de uitwisselingsbestanden overgebracht naar perifere databases.
De vraag is: hoe zit het met de lancering van handlers na het updaten van de databaseconfiguratie en de eerste login in gebruikersmodus?
hoofdconfiguratie bijwerken - databaseconfiguratie bijwerken - update-handlers uitvoeren in gebruikersmodus
Er zijn bijvoorbeeld veel releases gemist, u moet achtereenvolgens upgraden om te upgraden naar 3 releases. Er zijn geen problemen met het updaten van de centrale database, maar hoe zit het met de randapparatuur? Het is ook noodzakelijk om ze in 3 fasen bij te werken (update de centrale database met de eerste release, update de RIB, update de centrale database met de tweede release, update de RIB, enz.?)
Bedankt allemaal voor jullie hulp!
Antwoord:() steek je neus, ik kan de code die wordt uitgevoerd bij het registreren van objectwijzigingen niet vinden.
Het lijkt erop dat als u de OnSendingData-methode gebruikt, het masterknooppunt nog steeds gewijzigde objecten verzamelt voor verzending naar het slave-knooppunt. En dit zijn extra computerbronnen
Daarom wil ik dat de objecten in het hoofdknooppunt niet onmiddellijk worden geregistreerd voor verzending op het moment dat ze worden gewijzigd (bijvoorbeeld bij schrijven). Op welke plaats, bijvoorbeeld in standaard Boekhouding rev.3, worden deze objecten geregistreerd voor verzending?
Vraag: [OPGELOST] Fout bij contact opnemen met online ondersteuning
Beste experts, vertel het me alsjeblieft!
1C:Onderneming 8.3 (8.3.11.2899)
Verschillende databases met verschillende configuraties draaien op de 1C-server, in al deze is internetondersteuning aangesloten en werkt het prima. Incl. het laden van wisselkoersen, banken, controlerende tegenpartijen, SPARK, enz.
Proxy-instellingen zijn hetzelfde voor alle databases.
Maar in de BP-3 CORP-databases treedt altijd een fout op:In het registratielogboek:
Kan geen authenticatieticket in de service krijgen.
Kan inhoud() niet laden. (GeneralModule.InternetUserSupportClientServer.Module(362)): Fout bij aanroepen van contextmethode (SendToProcess)
Response = Connection.SendForProcessing (HTTPRequest, ReceiveParameters.ResponseFileName);
omdat:
Internetfout: verificatie van externe host misluktKlik om te onthullen...
Geprobeerd zowel op verschillende platformversies (8.3.10..., 8.3.11...), en op verschillende configuratieversies (3.0.54.15, 3.0.57.10).
Testen en repareren helpt ook niet.
Wat kan er mis zijn?
Gaat BP-CORP op de een of andere manier op een speciale manier naar internet?
Bedankt.
Antwoord:
Antwoord van 1C (wat rood is gemarkeerd heeft me geholpen):Tijdens de overgang is de BSP als onderdeel van de BP bijgewerkt van 2.4.3 naar 2.4.4
In de lijst met wijzigingen in BSP 2.4.4
Verbeterde beveiliging bij het tot stand brengen van een beveiligde verbinding met HTTPS-internetservices. Als er verschillende problemen zijn met het certificaat van de internetdienst waarmee de beveiligde verbinding wordt geprobeerd (het certificaat is niet geldig, verouderd of niet vertrouwd), wordt de verbinding niet tot stand gebracht.
In 8.3.10 wordt certificaatverificatie in Windows uitgevoerd door middel van het besturingssysteem." -
Installeer de laatste updates voor uw besturingssysteem, deze bevatten belangrijke updates voor systeemcomponenten die verantwoordelijk zijn voor het werken met certificaten.
Installeer ook de laatste update van rootcertificaten die door Microsoft worden gedistribueerd in installeerbare pakketten.
Vereist een versie van minimaal IE8.0. Het bevat belangrijke updates voor systeemcomponenten die verantwoordelijk zijn voor het werken met certificaten.
In de regel is het probleem na het installeren van alle updates opgelost.
Controleer of als u in de zoekbalk in Internet Explorer invoert, de link wordt geopend.
De gebruiker namens wie u werkt, heeft toegang tot internet.
Als dit een bestandsdatabase op de computer van de klant is, moet deze daarop worden gecontroleerd.
Als dit een client-serverdatabase is, dan op de server onder de gebruiker waaronder de 1C-server draait.
Controleer alleen met IE-browser.
Controleer of poorten 443 en 80 open zijn
Als u een proxyserver gebruikt, controleer dan of de gegevens in het menu Persoonlijke instellingen zijn geconfigureerd.
Als de client-serverversie wordt gebruikt, dan: je moet de server zo configureren dat de internetverbinding met de IE-browser er correct op werkt onder de gebruiker namens wie de 1C-server draait.
Ik heb de proxy geregistreerd in de IE-instellingen van de gebruiker waaronder de 1C-server draait - het werkte allemaal.
Vraag: Update boo 3
Goede dag
Boekhouding 3
deed een update van 3.0.43.208 naar 3.0.43.235
fouten
eerst
(GeneralModule.MessagingInternal.Module(381)): Fout bij aanroepen van contextmethode (ThisNode)
omdat:
Meer dan één vermelding gevonden
seconde
Bij het aanroepen van de update-handler:
"MessagingInternal.SetThisEndPointCode()"
Er is een fout opgetreden:
"(GeneralModule.MessagingInternal.Module(381)): Fout bij aanroepen van contextmethode (ThisNode)
ReturnInterchangePlans.MessageExchange.ThisNode();
omdat:
Meer dan één record gevonden."Gewaardeerd schrijf-kantelplatform geprobeerd op verschillende versies van platforms
Ik heb geprobeerd een schone conf van de nieuwste versie te nemen en deze gewoon stom te laden met een volledige vervanging
hielp helemaal niet, altijd hetzelfde. Vertel me plotseling wie er tegenkwam?
Antwoord:
knooppunt van waar naar onwaar
Een gedistribueerde informatiebank (DIB) wordt vaak gebruikt om het werk van vestigingen en divisies te organiseren, zodat u snel informatie kunt uitwisselen met behoud van de gewenste mate van autonomie. Ondanks dat deze technologie redelijk betrouwbaar is, gaat hij ook af en toe stuk. Vandaag zullen we kijken naar een van de vrij veel voorkomende fouten: laten we het hebben over de oorzaken van het optreden ervan en de methoden om ermee om te gaan.
Laten we, zoals altijd, bij het begin beginnen. Nadat u de RIB hebt gemaakt, kunnen alle wijzigingen in de configuratie van de infobase alleen in het hoofdknooppunt worden aangebracht. Vervolgens worden bij de volgende uitwisseling alle wijzigingen overgedragen naar de slave-knooppunten en daar automatisch toegepast. Maar op papier was het glad...
In de praktijk komt het soms voor dat tussen uitwisselingssessies, vooral als het kanaal in de periferie slecht is, de configuratie van het hoofdknooppunt de tijd heeft om twee keer te veranderen. Ze hebben bijvoorbeeld wijzigingen aangebracht, geüpload, de randapparatuur heeft de wijzigingen ontvangen, maar heeft ze nog niet toegepast, wat enige tijd kan duren, en heeft nog geen bevestiging gestuurd. Als u dit interval opnieuw wijzigt en de centrale opnieuw ontlaadt, blijkt dat het centrum configuratie nr. 1 in het perifere knooppunt verwacht en probeert deze bij te werken naar configuratie nr. 3, maar in feite zal het configuratie nr. 2 daar. Soms doet zich een vergelijkbare situatie voor wanneer de centrale database dynamisch wordt bijgewerkt. Als gevolg hiervan wordt de uitwisseling onmogelijk en ontvangt u een bericht waarin staat dat: Configuratie van gedistribueerde IS-knooppunten is niet zoals verwacht!
Over het algemeen is de moraal van dit verhaal eenvoudig: verfijn de werkbasis niet actief, en als u dat wel doet, beëindig dan alle uitwisselingssessies voordat u de volgende wijzigingen aanbrengt. Maar wat als er toch zo'n overlast zou zijn?
De brute-force-oplossing is om een nieuwe afbeelding van de slave-node te maken, maar in de praktijk is dit meestal niet van toepassing. In de regel wordt het optreden van een ernstige fout tijdens de uitwisseling niet onmiddellijk verholpen, maar enige tijd nadat de operationele gegevens van de perifere bases niet meer binnenkomen. Afhankelijk van het uitwisselingsschema kan het een volledige werkdag of langer duren tussen het moment dat een probleem zich voordoet en het moment waarop het wordt ontdekt.
Hier is het de moeite waard een steen naar de tuin van de ontwikkelaar te gooien, die het als een fout afgeeft en de situatie op dezelfde manier in het rood markeert Het berichtnummer is kleiner dan of gelijk aan het eerder ontvangen berichtnummer. wat over het algemeen heel normaal is. Als gevolg hiervan wordt de perceptie van fouten door gebruikers afgestompt en stoppen ze gewoon met het lezen van de weergegeven berichten, in de overtuiging dat alles in orde is en dat de andere kant thuis nog geen uitwisseling heeft gedaan.
Maar terug naar onze fout. De oplossing is vrij eenvoudig en ligt aan de oppervlakte: breng de configuratie van de perifere basis naar de verwachte, d.w.z. breng het in lijn met de configuratie van het centrale knooppunt. Maar in de praktijk is dit niet zo eenvoudig om te doen. Als we de perifere database openen in de configurator, zullen we zien dat de wijzigingen worden geblokkeerd door de RIB-beheertools.
Om de configuratie van een slave-node te wijzigen, moet u deze tijdelijk loskoppelen van de centrale basis. Voor deze doeleinden kunt u een van de verwerkingen gebruiken, die voldoende vertegenwoordigd zijn op het netwerk, of de informatiebeveiliging uitschakelen vanaf het centrale knooppunt met behulp van de startparameter van de configurator/ResetMasterNode.
Open een opdrachtprompt en typ (rekening houdend met de platformversie en het echte installatiepad):
"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNodeNa het uitvoeren van deze opdracht verschijnt het gebruikelijke startvenster, selecteer daar de gewenste basis en klik op de knop configurator.
IB tegelijkertijd starten zal niet gebeuren, d.w.z. het lijkt misschien alsof er niets is gebeurd, maar door de database opnieuw te openen in de Configurator, kunt u ervoor zorgen dat deze is losgekoppeld van het hoofdknooppunt en beschikbaar is voor het aanbrengen van wijzigingen.
Aandacht! Op platforms 8.3.7 - 8.3.9 crasht deze opdracht. De bug is opgelost in platform 8.3.10.
Als u niet met de opdrachtregel wilt knoeien, kunt u een van de verwerkingen gebruiken, hieronder is degene die we gebruiken, deze is op internet gevonden en we hebben er alleen cosmetische wijzigingen in aangebracht. Houd er rekening mee dat verwerking alleen geschikt is voor een reguliere applicatie; gebruik voor configuraties op een beheerde applicatie de startsleutel van de Configurator.
Er mee werken is uiterst eenvoudig, we starten het in 1C: Enterprise-modus, via Bestand - Openen, druk dan gewoon op de gewenste knop, in ons geval Hoofdknooppunt uitschakelen.
Nu hebben we de daadwerkelijke configuratie van het centrale knooppunt nodig. Om dit te doen, open centrale IS in de configurator en voer uit Configuratie - Configuratie opslaan in bestand. Het resulterende bestand met de extensie zie naar het perifere knooppunt moeten worden verzonden.
Vervolgens starten we in het perifere knooppunt de IS (nadat we deze eerder hadden losgekoppeld van het hoofdknooppunt) in de configurator en verwijderen we deze uit de ondersteuning. Kies hiervoor: Configuratie - Ondersteuning - Ondersteuningsinstelling.
Schakel in het geopende venster eerst de wijzigingsopties in.
En dan verwijderen we de configuratie uit de ondersteuning.
Nu kunt u de configuratie uit een bestand laden, hiervoor selecteert u Configuratie - Configuratie laden uit bestand en specificeer niet doorgegeven vanaf het centrale knooppunt zie-het dossier. Daarna krijgt u een waarschuwing dat de huidige configuratie niet leeg is. Houd er rekening mee dat de manipulaties die we uitvoeren potentieel gevaarlijk zijn en kunnen leiden tot onomkeerbare schade aan IS, dus zorg voordat u verdergaat dat u een up-to-date back-upkopie heeft.
Deze fout is typisch voor . De fout "Gedistribueerde IS-knooppuntconfiguratie komt niet overeen met verwacht" is een systeemfout. Het treedt voornamelijk op als gevolg van een crash tijdens de gegevensuitwisseling via de URIB.
Dit kan op een vrij eenvoudige manier worden opgelost. Laten we het overwegen.
Instructie
1. Maak kopieën van de databases waaraan gewerkt moet worden (In de configurator "Beheer - Infobase leegmaken").
2. Voer de configurator uit voor de hoofddatabase van het RIB-knooppunt.
3. Sla de configuratie van het centrale knooppunt op in een databasebestand (“Configuratie - Configuratie opslaan in bestand…”)
4. Open de slave-node-basisconfigurator.
Krijg gratis 267 1C-videolessen:
5. De-configureer het slave-knooppunt vanuit ondersteuning (Configuratie - Ondersteuning - Ondersteuningsinstellingen - De-ondersteuning):
6. Laad de databaseconfiguratie ("Configuratie - Configuratie laden uit bestand...").
8. Na de herstructurering moet u naar de bedrijfsmodus gaan en het configuratiemasterknooppunt installeren. Dit kan worden gedaan met behulp van speciale verwerking -. De verwerking werkt in zowel de beheerde app-modus als de reguliere app-modus.
9. Selecteer tijdens de verwerking het hoofdknooppunt en klik op "Uitvoeren":
10. Klaar! Probeer de uitwisseling te starten, het systeem zou de uitwisseling correct moeten uitvoeren.
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 configuratiewijzigingen zijn geregistreerd"
"Gedistribueerde IS-knooppuntconfiguratie niet zoals verwacht"
Hoe de uitwisseling herstellen?
Maar laten we niet beginnen met restaureren, maar met de mogelijkheid om te bestedenverander "handmatig", wat belangrijk is gedurende de dag, want zoals altijd zou alles "gisteren" moeten werken :) Je kunt dit doen met behulp van prachtige behandelingen die ik me niet kan herinnerenNu waar ik 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 lossen zonder configuratiewijzigingen te lossen, en als de configuratieobjecten niet veel zijn veranderd, is de kans groot dat het laden van deze gegevens. Deze kunnen worden gedownload via de link aan het einde van het artikel.
Wat betreft herstel. Er zijn eenvoudigere manieren die niet alle items in de onderstaande lijst bevatten, maar ze helpen niet altijd, zoals het geval was in een van mijn gevallen. Daarom geef ik de methode die mij heeft geholpen, het omzeilt mogelijke problemen uitgebreider. Verder op stappen.
Het is raadzaam om deze stappen uit te voeren als er geen werkende gebruikers in de database zijn. Als dit niet mogelijk is, moet u de methode voor uzelf "afmaken", en daarom moet u eerst de logica ervan begrijpen.
1. Maak overal back-ups.
2. Voor client-servers: schakel de databases uit via het "serverbeheer" en maak onmiddellijk verbinding met de installatie van het blokkeren van geplande taken (zo wordt de servercache gereset). Vergeet daarna niet om het registratielogboek naar de nieuwe map over te brengen.
3. Verwijder op alle computers die worden gebruikt voor herstel de database in de lijst met 1C-startdatabases en maak een nieuwe aan (de cache van de gebruiker wordt gewist)
4. Voeg in de configurator (in de centrale database) een nieuwe constante toe om wijzigingen in de conf.
5. Ruim alle uitwisselingsmappen op.
6. Lossingen uitvoeren naar alle vestigingen (tot nu toe alleen lossingen).
7. Probeer de ontvangen gegevens te uploaden (alleen uploaden) naar alle vestigingen. Het is normaal om de wijzigingen van de conf.
Als alles overal goed is, gaan we verder, als alles slecht is, denken we dat het uploaden van .cf uit de centrale database en het LADEN ervan naar de branch (geen vergelijkingsvereniging) kan helpen. In het slave-knooppunt moet u de basis losmaken van de RIB (verwerking zal hierbij helpen - download via de onderstaande link). Er is een artikel over dit onderwerp 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. (download verwerking voor ontbinden-binding van de onderstaande link).
9. We doen het laden in de Centrale Bank en als alles in orde is, doen we het laden en lossen met elk filiaal meerdere keren om het resultaat te consolideren.
10. Alles.
U kunt de uitvoering van geplande taken voor client-serverdatabases inschakelen.
Om problemen die deze fout veroorzaken te voorkomen, wordt aanbevolen om geen dynamische update uit te voeren (minstens meerdere keren achter elkaar - voordat wijzigingen naar branches worden geüpload), en het is ook raadzaam om het selectievakje "gegevens alleen uploaden na succesvolle upload" aan te vinken in de uitwisselingsinstellingen.
Om te beginnen is hier een lijst van de afkortingen die ik gebruik:
- RIB - gedistribueerde informatiebank
- CB - centrale basis, RIB-rootknooppunt
- UB - externe basis, database van het externe knooppunt RIB
Uit eigen ervaring kan ik zeggen dat ik twee redenen voor de fout ben tegengekomen:
- tijdens het ontvangen van het berichtenbestand in de UB, "viel de basis" in verband waarmee er blijkbaar een desynchronisatie was tussen de conf. Centrale Bank en UB;
- onder MSSQL laadde de client een kopie van de werkende database en schakelde deze niet uit in de kopie van de reg. automatische uitwisselingstaken, als resultaat werd een deel van de berichten naar externe knooppunten gevormd vanuit de werkende database en een deel van de kopie, wat leidde tot desynchronisatie van de configuraties
Er is ook een mening dat het gebruik van het dynamische database-updatemechanisme tot deze fout leidt. Er zijn hier twijfels, omdat enerzijds dynamisch bijwerken nooit de databasestructuur beïnvloedt, en de RIB-mechanismen nog steeds werken met de databasestructuur, en niet met het toepassingsgedeelte, niettemin gebruikt de RIB het mechanisme voor het genereren van een digitale handtekening van de configuratieversie (in kort noem ik het een hash), en wanneer het applicatiegedeelte verandert, moet de hash natuurlijk opnieuw worden berekend. Ik zal dit niet ontkennen, noch bevestigen, omdat. als ik met deze situatie werd geconfronteerd, heb ik daar geen duidelijk bewijs van gevonden.
Ik gebruik 2 methoden om het te repareren, afhankelijk van de situatie.
EERSTE METHODE
De eerste (de 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 de discrepanties van de configuraties, wanneer ze handmatig worden vergeleken, blijkt dat ze identiek zijn.
Volgorde aanbrengen in:
- het cf-bestand uitladen bij de Centrale Bank;
- we maken de UB los van de RIB (de SetMainNode-methode, kant-en-klare verwerking vind je in de applicatie of in andere publicaties);
- vervang conf. UB op het cf-bestand dat in de eerste stap is verwijderd, hiervoor gebruiken we het menu "Laad configuratie uit bestand" (en niet door vergelijkingsvereniging !!!);
- laten we het teken van RIB voor UB herstellen.
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 methode niet werkte en het niet mogelijk is om het knooppunt opnieuw te ontladen.
Achtergrond: de klant was een trapsgewijze RIB aan het opzetten en er is een fout opgetreden in het eerste niveau van de cascade (het tweede niveau werkte al die tijd foutloos). De configuratie is samen met de IT-service van de klant ontwikkeld en sinds de fout is opgetreden, is de CB-configuratie meerdere keren gewijzigd. De mogelijkheid om wijzigingen terug te draaien werd in principe niet eens overwogen, omdat het verlies van een deel van de gegevens en het stilleggen van een aantal afdelingen waren volstrekt onaanvaardbaar. De eerste versie van de foutcorrectie gaf geen tastbare resultaten. Er moesten dus andere oplossingen worden gevonden.
Het idee kwam om te proberen de hashes van de configuratiebestanden rechtstreeks in de uitwisselings-XML-bestanden te veranderen. 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: Digest1- en Digest2-waarden. Ik ontdekte al het andere puur empirisch (dat wil zeggen met vallen en opstaan), maar ik slaagde erin een patroon vast te stellen.
Testexperimenten gingen goed. Ook op de honken ging alles goed.
Dus de volgorde van acties:
- voer de stappen 1 - 4 van de eerste techniek uit;
- het uitwisselbestand uit de UB halen, maar niet uploaden naar het CB;
- haal het uitwisselingsbestand uit de Centrale Bank, maar upload het niet naar de UB;
- in het uitwisselingsbestand van de CB vervangen we het blok met informatie over configuratiewijzigingen en hashes (Digest1 en Digest2) door het blok met hashes uit het UB-bestand (zie een voorbeeld hieronder)
- we uploaden het bestand vanaf het 4e punt naar de UB;
- overschrijf zeker het uitwisselingsbestand van de UB (2e alinea)! dit bestand mag niet worden geladen bij het uitwisselen in de CB!
- om te controleren, doen we verschillende opeenvolgende uitwisselingen.
Als tijdens de uitwisseling gegevenscompressie wordt gebruikt, moet u de compressie uitschakelen of eerst het bestand uitpakken, wijzigen, inpakken en verzenden.
Bestandsuitwisseling van CB . blokkeren
vervangen moeten worden door een blok van het uitwisselingsbestand van de UB (merk op dat de Digest1 van het bestand van de UB altijd gelijk is aan "00000000000000000000000000000000"!! !)
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 acties VERPLICHT!
Anders kan ik je alleen maar veel succes wensen!
