Strādājot programmā 1C:Enterprise, var tikt parādīts šāds ziņojums: “Lai strādātu ar jaunā versija 1C: uzņēmumiem ir jāveic pārveide informācijas bāze" 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 novecojusi versija platformas 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 vispirms ir ieteicams izveidot rezerves kopija datu bāze, 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 turpina parādīties 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īgi! Informācijas bāze 1C, pārveidots jaunākā versija programmas nevar atvērt iepriekšējās versijās.

Smilšu kaste

iestāde 2013. gada 18. septembris, pulksten 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 nolēma dalī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:
IZMANTOJIET 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):

UZ šo iespēju pievērsās pēdējam salmiņam. 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 pilntiesīgs kopienas loceklis. Ar autoru varēs sazināties tikai pēc tam, kad viņš saņems 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. Bet kādā brīdī kaut kas nogāja greizi - lietotāji sāka sūdzēties

lēns darbs

. 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:

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 datubā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.

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

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 tas tā 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ā arī būs 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 procesā a kritiska kļūda
sakarā ar:
Mēģinot ievietot neunikālu vērtību unikālā rādītājā:
Microsoft SQL serveris 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". iesim 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 taustiņu "F5". Šādam vajadzētu būt rezultātam:

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