Când lucrați în 1C:Enterprise, poate apărea următorul mesaj: „Pentru a funcționa cu noua versiune de 1C:Enterprise, baza de informații trebuie convertită”. De ce apare această fereastră și cum pot remedia eroarea?

În cele mai multe cazuri, motivul apariției ferestrei este tranziția recentă a programului de la o versiune învechită a platformei la una mai nouă. Pe diferite platforme baza de informații 1C se formează în felul său și capătă o compoziție diferită. Tot ce trebuie făcut este să convertiți baza de date (a cărei structură corespunde platformei învechite) în cel mai nou format.

Conversie DB

Această procedură este simplă, totuși, se recomandă să creați mai întâi o copie de rezervă a bazei de date, în cazul în care apare o eroare în timpul conversiei (de exemplu, computerul se oprește, ca rezultat baza de informații 1C, precum și programul în sine, pot fi deteriorate). Apoi aplicați următorul algoritm de acțiuni:

• Deschide baza de date în modul configurator;
• Veți vedea un mesaj care vă cere să convertiți baza de informații. Confirmare prin presa;

• Închide configuratorul.

Deschideți baza de date - ar trebui să pornească fără probleme. Dacă fereastra de eroare continuă să apară după conversie, puteți încerca din nou procedura. În cazul în care acest lucru nu ajută, trebuie să contactați programatorul 1C. Uneori, programul se poate bloca în timpul efectuării unei operații. Nu este nevoie să luați nicio măsură în acest moment.

Important! Baza de informații 1C, convertit de cea mai recentă versiune a programului, nu poate fi deschis pe versiunile anterioare.

Cutie cu nisip

1C, restabilirea configurației bazei de informații folosind MS SQL

La un moment dat, am întâlnit o problemă: la actualizarea configurației din depozit, a apărut o eroare și 1C s-a închis.

După cum s-a dovedit mai târziu, memoria de configurare a fost distrusă, iar când configurația a fost actualizată, configurația bazei de date a zburat și ea din stocare. O eroare similară a mai apărut cu o actualizare dinamică a IB.

pentru că Această problemă a apărut de mai multe ori a decis să împărtășească opțiunea de tratament.

Data viitoare când rulați configuratorul, a apărut o eroare: „Atenție!!! A apărut o eroare la actualizarea datelor după ultima restructurare. Reîncercați actualizarea?" dacă răspunsul este da, primim mesajul: „A fost detectată operațiune de salvare a configurației incomplete. Pentru a continua munca, trebuie să finalizați operațiunea ”apoi aplicația se închide.

La analiza acestei probleme s-au găsit mai multe soluții la problemă, fiecare soluție funcționând în cazuri diferite.

Opțiunea 1 (dacă aveți o copie de rezervă SQL cu o copie cu o configurație identică):

O copie a IB este implementată și este solicitat următorul construct:
UTILIZAȚI GO DELETE FROM .. GO INSERT INTO .. ​​​​SELECT * FROM .. GO
În același timp, se reumple tabelul în care este stocată configurația IS. Este recomandabil să efectuați testarea și corectarea IS după această operație.

Opțiunea 2 (dacă nu există backup):

Această opțiune a fost tratată ca ultima picătură. pentru că configurația era în curs de dezvoltare și au uitat puțin de backup, bazându-se pe stocare.
În baza de date, două înregistrări sunt șterse din tabelul „Config” cu valoarea din coloana „FileName” - dbStruFinal și commit

Se face urmatoarea cerere:
UTILIZAȚI GO DELETE FROM . WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "commit" GO
Destul de ciudat, baza prinde viață.

Etichete: 1s enterprise 8.2, SQL, restaurare configurație

Acest articol nu face obiectul comentariilor, deoarece autorul său nu este încă un membru cu drepturi depline al comunității. Veți putea contacta autorul numai după ce acesta va primi

fundal

Trebuie să creăm un nou registru de informații „MessageTrackingLog”. Adăugat la configurație, au încărcat datele. Apoi a venit munca de optimizare. A trebuit să schimb structura registrului. Dar nu era acolo!

Totul este clar aici. Intrările au devenit neunice, trebuie să le ștergeți!

Cea mai simplă cale este:

NewRecord =RegistersInfo.MessageTrackingLog.CreateRecordSet(); NewRecord.Record();

Cu această metodă, vom șterge foarte repede registrul în 1C (dar aceasta va fi și greșeala noastră).

Greşeală

S-ar părea că registrul este gol și puteți actualiza 1C. Nu vreau să vă surprind, dar va apărea din nou o eroare:

Care este eroarea:

A apărut o eroare critică la actualizarea bazei de informații
din cauza:
Încercarea de a insera o valoare non-unica într-un index unic:
Microsoft SQL Server Native Client 11.0: Instrucțiunea CREATE UNIQUE INDEX sa încheiat deoarece a fost găsită o cheie duplicată pentru numele obiectului „dbo._InfoRgChngR34546NG” și numele indexului „_InfoR34546_ByNodeMsg_RNTSRRRRRRNG”. Valoarea cheii duplicate este (0x00000011,d7, , 27 sept 4015 22:22, 768404.00.00.00.00.00.00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, stare=1, severitate=10, nativ=1505, linie=1

Explicaţie

Să înțelegem structura SQL. Avem un registru „MessageTrackingLog”, în SQL este în tabelul „ _InfoR34546". Puteți verifica acest lucru cu procesare specială sau metoda „poke” (nu trebuie să facem acest lucru, deoarece numele tabelului este deja indicat în textul de eroare).

Acum hai să explic ce s-a întâmplat. Când am încărcat datele în registru, apoi în SQL au intrat în tabel " _InfoR34546". Când am șters tabelul cu codul din 1C, aceste date au fost șterse din tabelul " _InfoR34546", dar au fost copiate în tabelul " _InfoRgChngR34546". Aceasta a devenit problema.

Soluţie

Pentru a rezolva problema, trebuie să ștergem tabelul SQL „_InfoRgChngR34546”.

Vă voi spune despre exemplul „Microsoft SQL Server Management Studio”. Mergem la " Management Studio". Găsim baza noastră de date, deschidem fila tabele, facem clic pe oricare și apăsăm butonul „New Query”: Acum introducem interogarea

Trunchiați tabelul „_InfoRgChngR34546”

Poți avea și o altă masă! Nu uita!

Și apăsați Run sau apăsați F5. Iată care ar trebui să fie rezultatul:

Totul, acum puteți actualiza în siguranță 1C și nu va exista nicio eroare!

Ne-am mutat pe un nou server. Pe el SQL și 1C. În comparație cu cele vechi, era mult mai rece. Și testul lui Gilev a confirmat și asta: a dat 39 față de 10-15 pe serverele vechi.De aceea, imediat după cumpărare, am transferat baza de date și am început să lucrăm.

Dar, la un moment dat, ceva a mers prost - utilizatorii au început să se plângă de munca lentă. Am făcut anumite setări pentru server și servicii (care fac subiectul unei postări separate) și am decis să repornim serverul, deoarece viteza de repornire a fost de 2 minute (pe alte servere a ajuns la 10). După aceea, la intrarea în 1C, primim următorul mesaj:

"Atenţie!!! A apărut o eroare la actualizarea datelor după ultima restructurare. Reîncercați actualizarea?" "Nu chiar"

După ce faceți clic pe butonul „Da”, apare următoarele:

„A fost detectată o operație de salvare a configurației incomplete. Trebuie să finalizați operațiunea pentru a continua.”

Primul lucru pe care m-am hotărât să-l fac a fost CHECKDB în Managment Studio - după 2 ore de așteptare (bază de date de 500 GB) - totul este OK.

În vastitatea rețelei am găsit informații că aceeași eroare se întâmplă cu actualizările dinamice.

Soluțiile propuse în rețea nu au ajutat imediat, dar, împreună cu alte acțiuni, au dat un rezultat. Deci ce am facut:

Soluţie:

1. Ce lipsea pentru soluțiile din rețea:

sp_configure „permite actualizări”, 1
reconfigurare cu override
merge

2. Transferați baza de date în modul de recuperare

modificați setul de baze de date EMERGENCY, SINGLE_USER

3. Efectuăm testarea bazei de date:

dbcc checkdb('nume_db', REPAIR_ALLOW_DATA_LOSS)

4. Scoatem baza de date din modul de recuperare:

modificați setul de baze de date ONLINE, MULTI_USER

5. În principiu, dacă ești sigur că totul este în regulă cu baza în sine, atunci nu poți face 2-4 puncte. În continuare, executăm două interogări în profiler SQL:

ștergeți din config unde FileName = 'commit'
ștergeți din config unde FileName = 'dbStruFinal'

Aceste intrări sunt responsabile pentru actualizarea dinamică - nu vă puteți teme să le ștergeți.

În versiunile de lucru ale bazelor de date, interogările:

selectați * din Config WHERE FileName = 'commit'

selectați * din Config WHERE FileName = 'dbStruFinal'

va fi goală.

6. întoarceți setările:

sp_configure „permite actualizări”, 0
merge

7. După aceea, am reușit să lansăm configuratorul și baza de date a început să funcționeze.

De asemenea, baza poate funcționa după îndepărtarea primului steag.