Når du arbeider i 1C:Enterprise, kan følgende melding dukke opp: "For å jobbe med den nye versjonen av 1C:Enterprise, må infobasen konverteres." Hvorfor vises dette vinduet, og hvordan kan jeg løse feilen?

I de fleste tilfeller er årsaken til vinduets utseende en nylig overgang av programmet fra en utdatert versjon av plattformen til en nyere. På forskjellige plattformer informasjonsbase 1C er formet på sin egen måte og får en annen sammensetning. Alt som må gjøres er å konvertere databasen (strukturen tilsvarer den utdaterte plattformen) til det nyeste formatet.

Databasekonvertering

Denne prosedyren er enkel, men det anbefales å først lage en sikkerhetskopi av databasen i tilfelle det oppstår en feil under konvertering (for eksempel hvis datamaskinen slår seg av, noe som resulterer i informasjonsbase 1C, som selve programmet, kan være skadet). Bruk deretter følgende handlingsalgoritme:

• Åpne databasen i konfiguratormodus;
• Du vil se en melding som ber deg om å konvertere infobasen. Klikk bekreftelse;

• Lukk konfiguratoren.

Åpne databasen - den skal starte uten problemer. Hvis feilvinduet fortsetter å vises etter konvertering, kan du prøve prosedyren på nytt. Hvis dette ikke hjelper, må du kontakte en 1C-programmerer. Noen ganger kan programmet fryse mens du utfører en operasjon. Det er ikke nødvendig å gjøre noe for øyeblikket.

Viktig! Informasjonsbase 1C konvertert av den nyeste versjonen av programmet kan ikke åpnes på tidligere versjoner.

Bakgrunn

Vi trengte å opprette et nytt informasjonsregister "MessageTrackingLog". Lagt til i konfigurasjonen, lastet inn dataene. Så kom optimeringsarbeidet. Jeg måtte endre registerstrukturen. Men det var ikke der!

Alt er klart her. Postene har blitt uunike, du må slette dem!

Den enkleste måten er:

NewRecord = InformationRegisters.MessageTrackingLog.CreateRecordSet(); NewRecord.Write();

Ved å bruke denne metoden vil vi tømme registeret i 1C veldig raskt (men dette vil også være vår feil).

Feil

Det ser ut til at registeret er tomt, og du kan oppdatere 1C. Jeg vil ikke overraske deg, men det kommer en feil igjen:

Hva representerer feilen:

Det oppstod en kritisk feil under infobaseoppdateringsprosessen
på grunn av:
Prøver å sette inn en ikke-unik verdi i en unik indeks:
Microsoft SQL Server Native Client 11.0: CREATE UNIQUE INDEX-setningen ble avsluttet fordi en duplikatnøkkel ble funnet for objektnavnet "dbo._InfoRgChngR34546NG" og indeksnavnet "_InfoR34546_ByNodeMsg_RNTSRRRRRRNG". Duplikatnøkkelverdien er (0x00000011,d7, , 27. september 4015 22:22, 768404,00,00,00,00,00,00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

Forklaring

La oss forstå strukturen til SQL. Vi har et register "MessageTrackingLog", i SQL ligger den i tabellen " _InfoR34546". Du kan sjekke dette ved å bruke spesialbehandling eller "poke"-metoden (vi trenger ikke å gjøre dette fordi navnet på tabellen allerede er angitt i feilteksten).

Nå skal jeg forklare hva som skjedde. Da vi lastet dataene inn i registeret, havnet de i SQL i tabellen" _InfoR34546". Da vi tømte tabellen med kode i 1C, ble disse dataene slettet fra tabellen" _InfoR34546", men de ble kopiert til tabellen" _InfoRgChngR34546". Dette ble problemet.

Løsning

For å løse dette problemet må vi slette SQL-tabellen "_InfoRgChngR34546".

Jeg skal fortelle deg ved å bruke eksempelet "Microsoft SQL Server Management Studio". La oss gå til " Management Studio". Finn databasen vår, åpne tabellfanen, klikk på hvilken som helst og klikk på "Ny spørring"-knappen: Nå skriver vi søket

Avkort tabellen "_InfoRgChngR34546 "

Du kan ha et annet bord! Ikke glem!

Og trykk utfør eller trykk "F5". Dette er hva resultatet skal være:

Det er det, nå kan du trygt oppdatere 1C, og det vil ikke være noen feil!

Vi flyttet til en ny server. Den kjører SQL og 1C. Sammenlignet med de gamle var det mye kulere. Og Gilevs test bekreftet også dette: mot 10-15 på de gamle serverne ga den 39. Derfor, umiddelbart etter kjøpet, overførte vi databasen og begynte å jobbe.

Men på et tidspunkt gikk noe galt - brukerne begynte å klage på sakte arbeid. Vi gjorde visse innstillinger for serveren og tjenestene (hvilke er temaet i et eget innlegg) og bestemte oss for å starte serveren på nytt, heldigvis var omstarthastigheten 2 minutter (på andre servere var den opptil 10). Etter dette, når vi logger på 1C, mottar vi følgende melding:

"Merk følgende!!! Det oppstod en feil under oppdatering av data etter siste omstrukturering. Bør jeg gjenta oppdateringen? "Ikke egentlig"

Etter å ha klikket "Ja" vises følgende:

"En ufullstendig lagringsoperasjon for konfigurasjonen ble oppdaget. Du må fullføre operasjonen for å fortsette."

Det første jeg bestemte meg for å gjøre var CHECKDB i Managment Studio - etter 2 timers venting (500 GB database) - var alt OK.

Jeg fant informasjon på Internett om at den samme feilen oppstår under dynamisk oppdatering.

Løsningene som ble foreslått på nett hjalp ikke umiddelbart, men sammen med andre handlinger ga de resultater. Så hva jeg gjorde:

Løsning:

1. Hva manglet for løsninger fra nettverket:

sp_configure 'tillat oppdateringer', 1
rekonfigurere med overstyring
gå

2. Sett databasen i gjenopprettingsmodus

endre databasesett EMERGENCY, SINGLE_USER

3. Vi utfører databasetesting:

dbcc checkdb('db_name', REPAIR_ALLOW_DATA_LOSS)

4. Avslutt databasen fra gjenopprettingsmodus:

endre databasesett ONLINE, MULTI_USER

5. I prinsippet, hvis du er sikker på at alt er ok med selve basen, trenger du ikke å gjøre punkt 2-4. Deretter kjører vi to spørringer i SQL-profiler:

slett fra config hvor filnavn = 'commit'
slett fra config der filnavn = 'dbStruFinal'

Disse postene er ansvarlige for dynamisk oppdatering - du trenger ikke å være redd for å slette dem.

I fungerende versjoner av databasene spørringer:

velg * fra Config WHERE FileName = 'commit'

velg * fra Config WHERE FileName = 'dbStruFinal'

vil være tom.

6. returner innstillingene:

sp_configure 'tillat oppdateringer', 0
gå

7. Etter dette klarte vi å starte konfiguratoren og databasen begynte å fungere.

Basen kan også begynne å fungere etter å ha fjernet det første flagget.

Sandkasse

autoritet 18. september 2013 kl. 15:24

1C, gjenoppretting av infobasekonfigurasjon ved hjelp av MS SQL

På et tidspunkt møtte jeg et problem: ved oppdatering av konfigurasjonen fra depotet, oppstod det en feil og 1C lukket.

Som det viste seg senere, ble konfigurasjonslageret ødelagt, og ved oppdatering av konfigurasjonen ble også databasekonfigurasjonen slettet fra lageret. En lignende feil oppstod tidligere under dynamiske oppdateringer av informasjonssikkerhet.

Fordi Dette problemet har oppstått mer enn én gang, og jeg bestemte meg for å dele et behandlingsalternativ.

Neste gang du startet konfiguratoren, dukket det opp en feilmelding: "Obs!!! Det oppstod en feil under oppdatering av data etter siste omstrukturering. Bør jeg gjenta oppdateringen? Hvis svaret er ja, får vi meldingen: «En ufullstendig lagringsoperasjon for konfigurasjonen ble oppdaget. For å fortsette å jobbe, må du fullføre operasjonen” hvoretter applikasjonen lukkes.

Ved analyse av dette problemet ble det funnet flere løsninger på problemet, hver løsning fungerer i forskjellige tilfeller.

Alternativ 1 (hvis du har en SQL-sikkerhetskopi med en kopi med identisk konfigurasjon):

En kopi av informasjonssikkerheten er distribuert, og følgende forespørsel utføres:
BRUK GÅ SLETT FRA .. GÅ INN INN I .. VELG * FRA .. GÅ
I dette tilfellet fylles tabellen der inforer lagret på nytt. Det anbefales å teste og korrigere informasjonssikkerheten etter denne operasjonen.

Alternativ 2 (hvis det ikke er noen sikkerhetskopi):

Dette alternativet ble snudd til som siste dråpen. Fordi konfigurasjonen var under utvikling, og de glemte å sikkerhetskopiere litt, avhengig av lagring.
I databasen slettes to poster fra "Config"-tabellen med verdien i "FileName"-kolonnen - dbStruFinal og commit

Følgende spørring utføres:
BRUK GO SLETT FRA . WHERE FileName = "dbStruFinal" GO SLETT FRA . WHERE FileName = "commit" GO
Merkelig nok kommer basen til live.

Tags: 1C Enterprise 8.2, SQL, konfigurasjonsgjenoppretting

Denne artikkelen kan ikke kommenteres fordi forfatteren ikke er det ennå fullverdig fellesskapsmedlem. Du vil først kunne kontakte forfatteren etter at han har mottatt