Kako podesiti pametne telefone i računare. Informativni portal
  • Dom
  • Recenzije
  • Došlo je do kritične greške prilikom ažuriranja 1c. Greška konverzije infobaze

Došlo je do kritične greške prilikom ažuriranja 1c. Greška konverzije infobaze

Kada radite u 1C: Enterprise, može se pojaviti sljedeća poruka: "Da biste radili s novom verzijom 1C: Enterprise, baza podataka mora biti konvertirana." Zašto se pojavljuje ovaj prozor i kako mogu riješiti grešku?

U većini slučajeva razlog za pojavu prozora je nedavni prijelaz programa sa zastarjele verzije platforme na noviju. Različite platforme baza informacija 1C formira se na svoj način i poprima drugačiji sastav. Sve što treba uraditi je konvertovati bazu podataka (čija struktura odgovara zastarjeloj platformi) u najnoviji format.

Konverzija baze podataka

Ova procedura je jednostavna, međutim, prvo se preporučuje da napravite rezervnu kopiju baze podataka, u slučaju da dođe do greške tokom konverzije (na primer, računar se isključi, kao rezultat baza informacija 1C, kao i sam program, mogu biti oštećeni). Zatim primijenite sljedeći slijed radnji:

  • Otvorite bazu podataka u modu konfiguratora;
  • Vidjet ćete poruku u kojoj se traži da konvertujete bazu podataka. Kliknite potvrdu;

  • Zatvorite konfigurator.

Otvorite bazu podataka - trebalo bi da se pokrene bez problema. Ako se nakon konverzije prozor s greškom nastavi pojavljivati, možete ponoviti postupak. U slučaju kada to ne pomogne, trebate kontaktirati 1C programera. Ponekad, tokom izvođenja neke operacije, program se može zamrznuti. U ovom trenutku nema potrebe za preduzimanjem bilo kakvih radnji.

Bitan! Baza informacija 1C konvertovana najnovijom verzijom programa ne može se otvoriti na prethodnim verzijama.

Sandbox

autoritet 18. septembar 2013. u 15:24

1C, vraćanje konfiguracije infobaze pomoću MS SQL-a

Jednom sam naišao na problem: prilikom ažuriranja konfiguracije iz spremišta, došlo je do greške i 1C je zatvoren.

Kako se kasnije ispostavilo, konfiguracijsko spremište je uništeno, a kada je konfiguracija ažurirana, konfiguracija baze podataka je također odletjela iz spremišta. Slična greška se dogodila ranije s ažuriranjem dinamičke sigurnosti informacija.

Jer Ovaj problem se pojavio više puta.Odlučio sam podijeliti opciju liječenja.

Prilikom sljedećeg pokretanja konfiguratora pojavila se greška: „Pažnja !!! Došlo je do greške prilikom osvježavanja podataka od posljednjeg restrukturiranja. Želite li ponovo pokušati ažurirati?" ako je odgovor da, dobijamo poruku: „Otkrivena je nepotpuna operacija spremanja konfiguracije. Da biste nastavili s radom, morate dovršiti operaciju "nakon čega se aplikacija zatvara.

Prilikom analize ovog problema pronađeno je nekoliko opcija za rješavanje problema, svako rješenje funkcionira u različitim slučajevima.

Opcija 1 (ako imate SQL sigurnosnu kopiju s kopijom identične konfiguracije):

Kopija informacione sigurnosti se postavlja i izvršava se sljedeći upit:
KORISTI GO DELETE FROM .. GO INSERT IN .. SELECT * FROM .. GO
U ovom slučaju se ponovno popunjava tablica u kojoj je pohranjena IB konfiguracija. Preporučljivo je testirati i ispraviti sigurnost informacija nakon ove operacije.

Opcija 2 (u nedostatku sigurnosne kopije):

Ova opcija je tretirana kao posljednja kap. Jer konfiguracija je bila u razvoju i rezervna kopija je malo zaboravljena, oslanjajući se na spremište.
U bazi podataka, dva zapisa se brišu iz tabele "Config" po vrijednosti u koloni "FileName" - dbStruFinal i urezivanje

Izvršava se sljedeći upit:
KORISTI GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "urezivanje" GO
Začudo, baza oživljava.

Oznake: 1c enterprise 8.2, SQL, vraćanje konfiguracije

Ovaj članak nije podložan komentarisanju, jer njegov autor još nije punopravni član zajednice. Autora ćete moći kontaktirati tek nakon što primi

Pozadina

Trebali smo kreirati novi registar informacija "MessageTrackingLog". Dodato u konfiguraciju, učitao podatke. Tada su započeli radovi na optimizaciji. Morao sam da promenim strukturu registra. Ali nije ga bilo!

Ovde je sve jasno. Unosi su postali nejedinstveni, morate ih izbrisati!

Najlakši način je:

NewRecord = InformationRegisters.MessageTrackingLogin.CreateRecordSet (); NewWrite.Write ();

Ovom metodom ćemo vrlo brzo obrisati registar u 1C (ali to će biti i naša greška).

Greška

Čini se da je registar prazan i možete ažurirati 1C. Ne želim da vas iznenadim, ali opet će biti greške:


u čemu je greška:

Došlo je do kritične greške prilikom ažuriranja baze podataka
zbog:
Pokušaj umetanja nejedinstvene vrijednosti u jedinstveni indeks:
Microsoft SQL Server Native Client 11.0: Naredba CREATE UNIQUE INDEX je prekinuta jer je pronađen duplikat ključa za naziv objekta "dbo._InfoRgChngR34546NG" i naziv indeksa "_InfoR34546_ByNodeMsg_RNTSRRRRRRRNG". Duplicirana vrijednost ključa je (0x00000011, d7, , 27. septembar 4015 22:22, 768404.00,00,00,00,00,00).
HRESULT = 80040E2F, SQLSrvr: SQLSTATE = 23000, stanje = 1, ozbiljnost = 10, izvorno = 1505, red = 1

Objašnjenje

Hajde da razumemo strukturu SQL-a. Imamo registar "MessageTrackingLog", nalazi se u tabeli u SQL-u " _InfoR34546 ". Ovo možete provjeriti posebnim tretmanima ili kucanjem (nećemo to morati raditi, jer je naziv tabele već naznačen u tekstu greške).

Sad ću objasniti šta se dogodilo. Kada smo učitali podatke u registar, onda su u SQL-u ušli u tabelu " _InfoR34546 ". Kada smo obrisali tabelu sa kodom u 1C, ovi podaci su izbrisani iz tabele." _InfoR34546 "ali su kopirani u tabelu" _InfoRgChngR34546 ". Ovo je bio problem.

Rješenje

Da bismo riješili problem, moramo obrisati SQL tabelu "_InfoRgChngR34546".

Reći ću vam o primjeru "Microsoft SQL Server Management Studio". idemo u " Management Studio". Pronađite našu bazu, otvorite tabove tabela, kliknite na bilo koju i pritisnite dugme "Novi upit": Sada ukucavamo upit

Skratiti tabelu "_InfoRgChngR34546"

Možete imati i drugi sto! Nemoj zaboraviti!

I pritisnemo execute ili tipku "F5". Ovo bi trebao biti rezultat:

To je to, sada možete sigurno ažurirati 1C i neće biti grešaka!

Selili smo se na novi server. Ima SQL i 1C. U poređenju sa starim, bio je mnogo hladniji. I Gilevov test je to potvrdio: naspram 10-15 na starim serverima dao je 39. Stoga smo odmah nakon kupovine prenijeli bazu podataka i počeli s radom.

Ali u nekom trenutku nešto je pošlo po zlu - korisnici su počeli da se žale na spor rad. Napravili smo određena podešavanja za server i servise (što su tema posebnog posta) i odlučili da ponovo pokrenemo server, pošto je brzina ponovnog pokretanja 2 minuta (na ostalim serverima je bila do 10 minuta). Nakon toga, prilikom ulaska u 1C, dobijamo sljedeću poruku:

„Pažnja!!! Došlo je do greške prilikom osvježavanja podataka od posljednjeg restrukturiranja. Želite li ponovo pokušati ažurirati?" "Ne baš"

Nakon što kliknete na dugme "Da", pojavljuje se sledeće:

Otkrivena je nepotpuna operacija spremanja konfiguracije. Da biste nastavili s radom, morate dovršiti operaciju."

Prvo što sam odlučio da uradim - CHECKDB on u Managment Studio - nakon 2 sata čekanja (baza 500 GB) - sve je OK.

U prostranstvu mreže pronašao sam informaciju da se ista greška javlja kod dinamičkih ažuriranja.

Rješenja predložena na mreži nisu pomogla u potpunosti, ali su zajedno s drugim akcijama dala rezultat. Dakle, šta sam radio:

Rješenje:

  1. Šta je nedostajalo rešenjima sa mreže:

sp_configure 'dopusti ažuriranja', 1
rekonfigurirati sa nadjačavanjem
idi

2. Prebacujemo bazu podataka u način oporavka

izmijeniti skup baze podataka HITNO, SINGLE_USER

3. Vršimo testiranje baze:

dbcc checkdb ('db_name', REPAIR_ALLOW_DATA_LOSS)

4. Izvodimo bazu podataka iz načina oporavka:

alter baze podataka ONLINE, MULTI_USER

5. U principu, ako ste sigurni da je sve u redu sa samom bazom, onda možete preskočiti 2-4 boda. Zatim izvršavamo dva upita u SQL profileru:

izbriši iz konfiguracije gdje je FileName = 'uredi'
izbriši iz konfiguracije gdje je FileName = 'dbStruFinal'

Ovi zapisi su odgovorni za dinamičko ažuriranje - ne možete se bojati da ih izbrišete.

U radnim verzijama baza podataka, upiti:

odaberite * iz Config WHERE FileName = 'commit'

odaberite * iz Config WHERE FileName = 'dbStruFinal'

će biti prazan.

6. vraćanje postavki:

sp_configure 'dopusti ažuriranja', 0
idi

7. Nakon toga smo uspjeli pokrenuti konfigurator i baza podataka je proradila.

Također, baza može raditi nakon uklanjanja prve zastavice.

Top srodni članci