Strādājot programmā 1C:Enterprise, var tikt parādīts šāds ziņojums: “Lai strādātu ar jauno 1C:Enterprise versiju, informācijas bāze ir jākonvertē.” Kāpēc parādās šis logs un kā es varu novērst kļūdu?

Vairumā gadījumu loga parādīšanās iemesls ir nesenā programmas pāreja no novecojušas platformas versijas uz jaunāku. Uz dažādām platformām informācijas bāze 1C veidojas savā veidā un iegūst citu sastāvu. Viss, kas jādara, ir datu bāze (kuras struktūra atbilst novecojušajai platformai) jāpārvērš jaunākajā formātā.

Datu bāzes konvertēšana

Šī procedūra ir vienkārša, tomēr ieteicams vispirms izveidot datu bāzes rezerves kopiju, ja konvertēšanas laikā rodas kļūda (piemēram, dators izslēdzas, kā rezultātā informācijas bāze 1C, tāpat kā pati programma, var tikt bojāta). Pēc tam izmantojiet šādu darbību algoritmu:

• Atveriet datu bāzi konfiguratora režīmā;
• Tiks parādīts ziņojums ar aicinājumu konvertēt informācijas bāzi. Noklikšķiniet uz apstiprinājuma;

• Aizveriet konfiguratoru.

Atveriet datu bāzi - tai vajadzētu sākt bez problēmām. Ja kļūdas logs joprojām parādās pēc konvertēšanas, varat mēģināt vēlreiz. Ja tas nepalīdz, jums jāsazinās ar 1C programmētāju. Dažkārt programma var sastingt darbības laikā. Šobrīd nav jāveic nekādas darbības.

Svarīgs! Informācijas bāze 1C kuras ir konvertētas ar jaunāko programmas versiju, nevar atvērt iepriekšējās versijās.

Fons

Mums bija nepieciešams izveidot jaunu informācijas reģistru “MessageTrackingLog”. Pievienots konfigurācijai, ielādēts dati. Tad sekoja optimizācijas darbs. Man bija jāmaina reģistra struktūra. Bet tā tur nebija!

Šeit viss ir skaidrs. Ieraksti ir kļuvuši neunikāli, tie ir jāizdzēš!

Vienkāršākais veids ir:

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

Izmantojot šo metodi, mēs ļoti ātri izdzēsīsim reģistru 1C (bet tā būs arī mūsu kļūda).

Kļūda

Šķiet, ka reģistrs ir tukšs, un jūs varat atjaunināt 1C. Es nevēlos jūs pārsteigt, bet atkal būs kļūda:

Ko nozīmē kļūda:

Informācijas bāzes atjaunināšanas procesa laikā radās kritiska kļūda
tāpēc ka:
Mēģinot ievietot neunikālu vērtību unikālā rādītājā:
Microsoft SQL Server Native Client 11.0: priekšraksts CREATE UNIQUE INDEX tika pārtraukts, jo tika atrasta atslēgas dublikāts objekta nosaukumam "dbo._InfoRgChngR34546NG" un indeksa nosaukumam "_InfoR34546_ByNodeMsg_RNTSRRRRRRNG". Atslēgas dublikāta vērtība ir (0x00000011,d7, , 27. septembris 4015 22:22, 768404,00,00,00,00,00,00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, stāvoklis=1, nopietnība=10, native=1505, rinda=1

Paskaidrojums

Izpratīsim SQL struktūru. Mums ir reģistrs "MessageTrackingLog", SQL tas atrodas tabulā " _InfoR34546". To var pārbaudīt, izmantojot īpašu apstrādi vai "poke" metodi (mums tas nav jādara, jo kļūdas tekstā jau ir norādīts tabulas nosaukums).

Tagad es paskaidrošu, kas notika. Kad mēs ielādējām datus reģistrā, SQL tie nonāca tabulā" _InfoR34546". Kad mēs notīrījām tabulu ar kodu 1C, šie dati tika izdzēsti no tabulas" _InfoR34546", bet tie tika kopēti tabulā" _InfoRgChngR34546". Tā radās problēma.

Risinājums

Lai atrisinātu šo problēmu, mums ir jānotīra SQL tabula "_InfoRgChngR34546".

Es jums pastāstīšu, izmantojot piemēru "Microsoft SQL Server Management Studio". Ejam uz " Management Studio". Atrodiet mūsu datu bāzi, atveriet tabulu cilni, noklikšķiniet uz jebkura un noklikšķiniet uz pogas "Jauns vaicājums": Tagad mēs ierakstām vaicājumu

Saīsināt tabulu "_InfoRgChngR34546"

Jums var būt cits galds! Neaizmirsti!

Un nospiediet izpildīt vai nospiediet "F5". Šādam vajadzētu būt rezultātam:

Tas ir viss, tagad varat droši atjaunināt 1C, un kļūdu nebūs!

Mēs pārcēlāmies uz jaunu serveri. Tas darbina SQL un 1C. Salīdzinājumā ar vecajiem bija daudz foršāk. Un Gilev’s tests arī to apstiprināja: pret 10-15 vecajos serveros tas deva 39. Tāpēc uzreiz pēc pirkuma pārsūtījām datu bāzi un sākām strādāt.

Taču kādā brīdī kaut kas nogāja greizi – lietotāji sāka sūdzēties par lēnu darbu. Mēs veicām noteiktus iestatījumus serverim un pakalpojumiem (par kuriem ir atsevišķa ieraksta tēma) un nolēmām restartēt serveri, par laimi pārstartēšanas ātrums bija 2 minūtes (citos serveros tas bija līdz 10). Pēc tam, piesakoties 1C, mēs saņemam šādu ziņojumu:

"Uzmanību!!! Atjauninot datus pēc pēdējās pārstrukturēšanas, radās kļūda. Vai man vajadzētu atkārtot atjauninājumu? "Ne īsti"

Pēc noklikšķināšanas uz "Jā" parādās sekojošais:

“Tika konstatēta nepilnīga konfigurācijas saglabāšanas darbība. Lai turpinātu, operācija ir jāpabeidz."

Pirmais, ko nolēmu izdarīt, bija CHECKDB Managment Studio - pēc 2 stundu gaidīšanas (500 GB datubāze) - viss bija kārtībā.

Internetā atradu informāciju, ka dinamiskās atjaunināšanas laikā rodas tāda pati kļūda.

Tiešsaistē piedāvātie risinājumi nepalīdzēja uzreiz, taču kopā ar citām darbībām deva rezultātus. Tātad, ko es izdarīju:

Risinājums:

1. Kas trūka risinājumiem no tīkla:

sp_configure 'atļaut atjauninājumus', 1
pārkonfigurēt ar ignorēšanu
aiziet

2. Ievietojiet datu bāzi atkopšanas režīmā

mainīt datu bāzes kopu EMERGENCY, SINGLE_USER

3. Veicam datu bāzes testēšanu:

dbcc checkdb ('db_name', REPAIR_ALLOW_DATA_LOSS)

4. Izejiet no datu bāzes no atkopšanas režīma:

mainīt datu bāzes kopu ONLINE, MULTI_USER

5. Principā, ja esi pārliecināts, ka ar pašu bāzi viss ir kārtībā, tad 2.-4.punkts nav jādara. Pēc tam SQL profilētājā izpildām divus vaicājumus:

dzēst no konfigurācijas, kur FileName = 'commit'
dzēst no konfigurācijas, kur FileName = 'dbStruFinal'

Šie ieraksti ir atbildīgi par dinamisku atjaunināšanu — jums nav jābaidās tos dzēst.

Datu bāzu darba versijās vaicājumi:

atlasiet * no konfigurācijas WHERE FileName = 'commit'

atlasiet * no konfigurācijas WHERE FileName = 'dbStruFinal'

būs tukšs.

6. atgriezt iestatījumus:

sp_configure 'atļaut atjauninājumus', 0
aiziet

7. Pēc tam mums izdevās palaist konfiguratoru un datubāze sāka darboties.

Arī bāze var sākt darboties pēc pirmā karoga noņemšanas.

Smilšu kaste

iestāde 2013. gada 18. septembris, 15:24

1C, informācijas bāzes konfigurācijas atjaunošana, izmantojot MS SQL

Vienā reizē es saskāros ar problēmu: atjauninot konfigurāciju no repozitorija, radās kļūme un 1C tika aizvērts.

Kā vēlāk izrādījās, konfigurācijas krātuve tika iznīcināta un, atjauninot konfigurāciju, no krātuves tika izdzēsta arī datu bāzes konfigurācija. Līdzīga kļūda radās iepriekš, veicot dinamiskus informācijas drošības atjauninājumus.

Jo Šī problēma ir radusies vairāk nekā vienu reizi, un es nolēmu padalīties ar ārstēšanas iespēju.

Nākamajā reizē, kad startējat konfiguratoru, parādījās kļūda: “Uzmanību!!! Atjauninot datus pēc pēdējās pārstrukturēšanas, radās kļūda. Vai man vajadzētu atkārtot atjauninājumu? Ja atbilde ir jā, mēs saņemam ziņojumu: “Tika konstatēta nepilnīga konfigurācijas saglabāšanas darbība. Lai turpinātu darbu, jums ir jāpabeidz darbība”, pēc kuras lietojumprogramma tiek aizvērta.

Analizējot šo problēmu, tika atrasti vairāki problēmas risinājumi, katrs risinājums darbojas dažādos gadījumos.

1. iespēja (ja jums ir SQL dublējums ar kopiju ar identisku konfigurāciju):

Tiek izvietota informācijas drošības kopija, un tiek izpildīts šāds pieprasījums:
IZMANTOT GO DELETE FROM .. GO INSERT INTO .. SELECT * FROM .. GO
Šajā gadījumā tabula, kurā tiek glabāta informācijas drošības konfigurācija, tiek aizpildīta atkārtoti. Pēc šīs operācijas ieteicams pārbaudīt un labot informācijas drošību.

2. iespēja (ja nav rezerves kopijas):

Šī iespēja tika izmantota kā pēdējais piliens. Jo konfigurācija tika izstrādāta, un viņi nedaudz aizmirsa par dublēšanu, paļaujoties uz krātuvi.
Datu bāzē divi ieraksti tiek dzēsti no tabulas “Config” ar vērtību kolonnā “FileName” - dbStruFinal un commit

Tiek izpildīts šāds vaicājums:
IZMANTOJIET GO DELETE NO. WHERE FileName = "dbStruFinal" GO DELETE NO . WHERE FileName = "commit" GO
Savādi, bet bāze atdzīvojas.

Birkas: 1C Enterprise 8.2, SQL, konfigurācijas atjaunošana

Šis raksts nav komentējams, jo tā autors vēl nav pilnvērtīgs kopienas loceklis. Ar autoru varēs sazināties tikai pēc tam, kad viņš saņems