- Meldingsfilen er allerede lastet inn i mottakerdatabasen. Du må laste den ned fra kildedatabasen på nytt.
Feil "Feil ved kopiering av en fil fra en FTP-ressurs... Feil ved arbeid med Internett: Tidsavbrudd ble nådd"
- Det er ikke mulig å kopiere den nødvendige filen fra nettstedet som utvekslingen skjer gjennom. Dette kan skyldes at Internett er tregt eller problemer med selve siden.
- Du må prøve å gjenta byttet etter 15-30 minutter.
Feil: Redigering av data for denne perioden er forbudt. Endringer kan ikke registreres..."
- De nedlastede dataene inneholder dokumenter fra den lukkede perioden.
- Det er nødvendig å gjennomføre utvekslingen under brukere som har rett til å endre dokumenter i denne perioden.
Feil: Datmå utføres. Oppdateringen kan utføres i konfiguratormodus"
Årsak: Programmererne endret konfigurasjonen i senteret. Løsning: Oppdater den endrede konfigurasjonen i den perifere databasen. For dette:- Gå til konfiguratoren.
- Kjør menypunktet "Konfigurator / Oppdater databasekonfigurasjon".
- Hvis et spørsmål vises med svarene bare "Gjenta", "Avbryt", "Oppdater dynamisk", klikk på "Oppdater dynamisk"-knappen.
- Hvis et spørsmål er gitt med bare "Gjenta" og "Avbryt" svar.
- alle brukere logger ut av 1C.
- trykk på "Gjenta"-knappen.
- Svar bekreftende på de resterende spørsmålene: "Ja", "Godta", "OK".
- Lukk konfiguratoren.
- Gjenta lasting fra midten.
Feil: "Konfigurasjonen er ikke som forventet", "Forsøker å godta endringer fra en ukjent konfigurasjon"
- Database feil.
- Det er nødvendig å kontakte spesialister.
For 1C 8.x-plattformer, når feilen "Konfigurasjonen av den distribuerte informasjonssikkerhetsnoden samsvarer ikke med forventet" oppstår
Metodikk for å løse problemet
Liste over forkortelser jeg bruker:
RIB - distribuert informasjonsgrunnlag
CB - sentral base, rotnode til RIB
UB - ekstern base, database for en ekstern RIB-node
Fra min egen erfaring kan jeg si at jeg har støtt på to årsaker til feilen:
Under mottak av meldingsfilen "falt" databasen i styringssystemet, og derfor var det tilsynelatende en desynkronisering mellom conf. sentralbanken og UB;
under MSSQL lastet klienten ned en kopi av arbeidsdatabasen og slo ikke av reg. auto-utvekslingsoppgaver, som et resultat ble noen meldinger til eksterne noder generert fra arbeidsdatabasen, og noen fra en kopi, noe som førte til desynkronisering av konfigurasjoner
Det er også en oppfatning at denne feilen er forårsaket av bruken av en dynamisk databaseoppdateringsmekanisme. Det er tvil her, for på den ene siden påvirker dynamisk oppdatering aldri databasestrukturen, og RIB-mekanismene fungerer fortsatt med databasestrukturen, og ikke med dens anvendte del likevel, RIB bruker en mekanisme for å generere en digital signatur av konfigurasjonsversjonen (i fremtiden vil jeg kalle det en hash for kort), og når applikasjonsdelen endres, må hashen naturligvis beregnes på nytt. Jeg vil verken benekte dette eller bekrefte det, fordi... Hvis jeg møtte denne situasjonen, fant jeg ingen klare bevis på det.
For å rette det bruker jeg 2 metoder, avhengig av situasjonen.
FØRSTE TEKNIKK
Den første (mest vanlige) er gjentatte ganger nevnt både i partnerkonferansen og på andre Internett-ressurser relatert til 1C. Den brukes i de fleste tilfeller når, til tross for meldingen om avvik i konfigurasjoner, en manuell sammenligning viser at de er identiske.
Sekvensering:
1. last ned cf-filen fra sentralbanken;
2. koble fra UB fra RIB (Set MainNode-metoden, ferdige prosesser finnes i vedlegget eller i andre publikasjoner);
3. erstatte konf. UB til cf-filen lastet opp i det første trinnet, for dette bruker vi menyen "Last inn konfigurasjon fra fil" (og ikke sammenligning-fletting!!!);
4. gjenopprett RIB-attributtet for UX.
I de fleste tilfeller er disse handlingene mer enn nok til å gjenopprette utvekslingen, men ikke alltid...
ANDRE METODE
Den brukes hvis den første metoden ikke fungerte, og det ikke er mulig å laste ut noden igjen.
Så rekkefølgen av handlinger:
1. utfør trinn 1 - 4 i den første metoden;
2. last ut utvekslingsfilen fra UB, men ikke last den inn i sentralbanken;
3. last ut utvekslingsfilen fra sentralbanken, men ikke last den inn i MB;
4. i utvekslingsfilen fra sentralbanken erstatter vi blokken som inneholder informasjon om konfigurasjonsendringer og hashes (Digest1 og Digest2) med en blokk med hashes fra UB-filen (se eksempel nedenfor)
5. Vi laster opp filen fra 4. punkt til UB;
Sørg for å overskrive utvekslingsfilen fra UB (2. punkt)! denne filen skal ikke lastes ned ved utveksling med sentralbanken!
For å sjekke, gjør vi flere påfølgende utvekslinger.
Hvis datakomprimering brukes under utvekslingen, deaktiverer vi enten komprimering, eller først pakker vi ut filen, endrer den, pakker den tilbake og sender den.
Bytt filblokk fra sentralbanken
må erstattes med en blokk av utvekslingsfilen fra UB (merk at Digest1 for en fil fra UB alltid er lik "00000000000000000000000000000000000"!!!)
De oppførte handlingene må utføres med ekstrem forsiktighet. En feil rekkefølge kan resultere i fullstendig ubrukbarhet av RIB. Derfor, før disse handlingene, er det OBLIGATORISK å lage sikkerhetskopier!
En distribuert informasjonsbase (DIB) brukes ofte til å organisere arbeidet til grener og divisjoner, noe som muliggjør rask utveksling av informasjon samtidig som den nødvendige graden av autonomi opprettholdes. Til tross for at denne teknologien er ganske pålitelig, bryter den ned fra tid til annen. I dag skal vi se på en av de ganske vanlige feilene: Vi vil fortelle deg om årsakene til dens forekomst og metoder for å håndtere det.
La oss starte, som alltid, fra begynnelsen. Etter at du har opprettet RIB, kan alle endringer i infobasekonfigurasjonen kun gjøres i hovednoden. Deretter, under neste utveksling, vil alle endringer bli overført til slavenodene og automatisk brukt der. Men det var glatt på papiret...
I praksis skjer det noen ganger at mellom utvekslingsøktene, spesielt hvis kanalen i periferien er dårlig, klarer konfigurasjonen av hovednoden å endre seg to ganger. For eksempel gjorde de endringer, lastet dem opp, den perifere databasen mottok endringene, men har ennå ikke tatt i bruk dem, noe som kan ta litt tid, og har ennå ikke sendt bekreftelse. Hvis du gjør endringer igjen i løpet av denne perioden og laster opp sentralen på nytt, viser det seg at senteret forventer å se konfigurasjon nr. 1 i den perifere noden og vil prøve å oppdatere den til konfigurasjon nr. 3, men vil faktisk møte konfigurasjon nr. 2 der. Noen ganger oppstår en lignende situasjon under dynamisk oppdatering av den sentrale databasen. Som et resultat vil utvekslingen bli umulig, og du vil motta en melding om det Konfigurasjonen av den distribuerte informasjonssikkerhetsnoden samsvarer ikke med den forventede!
Generelt er moralen i denne historien enkel - ikke aktivt avgrens arbeidsdatabasen, og hvis du gjør det, fullfør alle utvekslingsøkter før du gjør de neste endringene. Men hva om en slik plage skjer?
Den enkle løsningen er å lage et nytt bilde av slavenoden, men i praksis er dette vanligvis ikke aktuelt. Som regel oppdages ikke forekomsten av en alvorlig feil under utvekslingen umiddelbart, men en tid etter at driftsdata fra perifere databaser har sluttet å ankomme. Avhengig av kommunikasjonsplanen kan det gå en hel arbeidsdag eller mer mellom det tidspunktet problemet oppstår og det oppdages.
Her er det verdt å kaste en stein på utviklerne, som rapporterer det som en feil og markerer situasjonen i rødt på samme måte Meldingsnummeret er mindre enn eller lik nummeret til en tidligere mottatt melding, som generelt er ganske normalt. Som et resultat blir brukernes oppfatning av feil sløvet, og de slutter ganske enkelt å lese meldingene som vises, og tror at alt er i orden og at den andre parten ennå ikke har foretatt utvekslingen.
Men la oss gå tilbake til feilen vår. Løsningen er ganske enkel og ligger på overflaten: bring konfigurasjonen av den perifere basen til den forventede, dvs. bringe den i tråd med konfigurasjonen av den sentrale noden. Men i praksis er ikke dette så lett. Hvis vi åpner den perifere databasen i konfiguratoren, vil vi se at endringer blokkeres av RIB-administrasjonsverktøyene.
For å endre konfigurasjonen av en slavenode, må du midlertidig koble den fra den sentrale databasen. For disse formålene kan du bruke et av behandlingsalternativene, som er rikelig tilgjengelig på nettverket, eller koble fra informasjonssikkerheten fra den sentrale noden ved å bruke konfiguratorstartparameteren/ResetMasterNode.
Åpne en ledetekst og skriv inn (ta hensyn til plattformversjonen og den faktiske installasjonsbanen):
"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNodeEtter å ha utført denne kommandoen vil det vanlige startvinduet vises, velg ønsket base der og klikk på knappen Konifgurator.
Lansering av informasjonssikkerhet samtidig vil ikke skje, dvs. det kan se ut til at ingenting har skjedd, men ved å åpne databasen igjen i konfiguratoren kan du sørge for at den er koblet fra hovednoden og er tilgjengelig for å gjøre endringer.
Merk følgende! På plattformene 8.3.7 - 8.3.9 resulterer utførelse av denne kommandoen i en krasj. Feilen ble rettet i plattform 8.3.10.
Hvis du ikke vil rote rundt med kommandolinjen, kan du bruke en av behandlingene nedenfor, den ble funnet på Internett, og vi har kun gjort kosmetiske endringer i den. Vær oppmerksom på at behandling kun er egnet for en vanlig applikasjon for konfigurasjoner på en administrert applikasjon, bruk Configurator-startnøkkelen.
Å jobbe med det er ekstremt enkelt, vi lanserer det i 1C:Enterprise-modus, via Fil - Åpne, og trykk deretter på ønsket knapp, i vårt tilfelle Deaktiver hovednoden.
Nå trenger vi den siste konfigurasjonen fra den sentrale noden. For dette vil vi åpne sentral informasjonssikkerhet i konfiguratoren og utfør Konfigurasjon - Lagre konfigurasjon til fil. Den resulterende filen med utvidelsen jfr må sendes til en perifer node.
Deretter, i den perifere noden, starter vi informasjonssikkerheten (som tidligere har koblet den fra hovednoden) i konfiguratoren og fjerner den fra støtten. For å gjøre dette, velg: Konfigurasjon - Støtte - Støtteoppsett.
Aktiver først redigeringsalternativene i vinduet som åpnes.
Og så fjerner vi konfigurasjonen fra støtten.
Nå kan du laste inn konfigurasjonen fra en fil, for å gjøre dette, velg Konfigurasjon - Last inn konfigurasjon fra fil og indikerer ikke sendt fra den sentrale noden jfr-fil. Deretter vil du motta en advarsel om at gjeldende konfigurasjon ikke er tom. Vær oppmerksom på at manipulasjonene vi utfører er potensielt farlige og kan føre til irreversibel skade på informasjonssikkerheten, så før du fortsetter, sørg for at du har en oppdatert sikkerhetskopi.
Først, her er en liste over forkortelser jeg bruker:
- RIB - distribuert informasjonsgrunnlag
- CB - sentral base, rotnode til RIB
- UB - ekstern base, database for en ekstern RIB-node
Fra min egen erfaring kan jeg si at jeg har støtt på to årsaker til feilen:
- Mens du mottok meldingsfilen, "falt" databasen i styringssystemet, og derfor var det tilsynelatende en desynkronisering mellom conf. sentralbanken og UB;
- under MSSQL lastet klienten ned en kopi av arbeidsdatabasen og slo ikke av reg. automatiske utvekslingsoppgaver, som et resultat ble noen meldinger til eksterne noder generert fra arbeidsdatabasen, og noen fra en kopi, noe som førte til desynkronisering av konfigurasjoner
Det er også en oppfatning at denne feilen er forårsaket av bruken av en dynamisk databaseoppdateringsmekanisme. Det er tvil her, for på den ene siden påvirker dynamisk oppdatering aldri databasestrukturen, og RIB-mekanismene fungerer fortsatt med databasestrukturen, og ikke med dens anvendte del likevel, RIB bruker en mekanisme for å generere en digital signatur av konfigurasjonsversjonen (i fremtiden vil jeg kalle det en hash for kort), og når applikasjonsdelen endres, må hashen naturligvis beregnes på nytt. Jeg vil verken benekte dette eller bekrefte det, fordi... Hvis jeg møtte denne situasjonen, fant jeg ingen klare bevis på det.
For å rette det bruker jeg 2 metoder, avhengig av situasjonen.
FØRSTE TEKNIKK
Den første (mest vanlige) er gjentatte ganger nevnt både i partnerkonferansen og på andre Internett-ressurser relatert til 1C. Den brukes i de fleste tilfeller når, til tross for meldingen om avvik i konfigurasjoner, en manuell sammenligning viser at de er identiske.
Sekvensering:
- last ut cf-filen fra sentralbanken;
- vi kobler UB fra RIB (Set MainNode-metoden, ferdigbehandling kan finnes i applikasjonen eller i andre publikasjoner);
- erstatter konf. UB til cf-filen lastet opp i det første trinnet, for dette bruker vi menyen "Last inn konfigurasjon fra fil" (og ikke sammenligning-fletting!!!);
- La oss gjenopprette RIB-tegnet for UX.
I de fleste tilfeller er disse handlingene mer enn nok til å gjenopprette utvekslingen, men ikke alltid...
ANDRE METODE
Den brukes hvis den første metoden ikke fungerte, og det ikke er mulig å laste ut noden igjen.
Bakgrunn: klienten satte opp en kaskade RIB og det oppstod en feil i det første nivået av kaskaden (det andre nivået fungerte feilfritt hele denne tiden). Konfigurasjonen er utviklet i fellesskap med kundens IT-tjeneste, og siden feilen oppsto har konfigurasjonen av sentralbanken endret seg flere ganger. Muligheten for å rulle tilbake endringer ble ikke vurdert engang i prinsippet, fordi tap av noen data og nedleggelse av flere avdelinger var helt uakseptabelt. Det første alternativet for å rette feilen ga ingen konkrete resultater. Derfor måtte vi se etter andre løsninger.
Ideen kom til å prøve å erstatte hashen til konfigurasjonsfiler direkte i XML-utvekslingsfilene. Beskrivelsen av strukturen til utvekslingsfilen fra boken "Profesjonell utvikling i 1C:Enterprise 8-systemet" ga en svak idé om dannelsen av digitale signaturer av konfigurasjoner og endringer i dem, men bestemte retningen for søk: verdiene til Digest1 og Digest2. Jeg fant ut alt annet rent empirisk (det vil si ved prøving og feiling), men det var mulig å etablere et mønster.
Testeksperimentene var vellykkede. På arbeidsbasene gikk også alt bra.
Så rekkefølgen av handlinger:
- utfør trinn 1 - 4 i den første metoden;
- Vi laster ut utvekslingsfilen fra UB, men laster den ikke inn i sentralbanken;
- Vi laster ut utvekslingsfilen fra sentralbanken, men laster den ikke inn i UB;
- i utvekslingsfilen fra sentralbanken erstatter vi blokken som inneholder informasjon om konfigurasjonsendringer og hasher (Digest1 og Digest2) med en blokk med hashes fra UB-filen (se eksempel nedenfor)
- Vi laster opp filen fra 4. punkt til UB;
- Sørg for å overskrive utvekslingsfilen fra UB (2. punkt)! denne filen skal ikke lastes ned ved utveksling med sentralbanken!
- For å sjekke, gjør vi flere påfølgende utvekslinger.
Hvis datakomprimering brukes under utvekslingen, deaktiverer vi enten komprimering, eller først pakker vi ut filen, endrer den, pakker den tilbake og sender den.
Bytt filblokk fra sentralbanken
må erstattes med en blokk av utvekslingsfilen fra UB (merk at Digest1 for en fil fra UB alltid er lik "00000000000000000000000000000000000"!!!)
De oppførte handlingene må utføres med ekstrem forsiktighet. En feil rekkefølge kan resultere i fullstendig ubrukbarhet av RIB. Derfor, før disse handlingene, er det OBLIGATORISK å lage sikkerhetskopier!
For resten kan jeg bare ønske deg lykke til!
