Sandbox

1C, konfiguráció visszaállítása információs bázis MS SQL használatával

Egyszer egy problémába ütköztem: a konfiguráció frissítésekor a tárolóból hiba történt, és az 1C bezárult.

Mint később kiderült, a konfigurációs tároló megsemmisült, majd a konfiguráció frissítésekor az adatbázis konfigurációja is kirepült a tárolóból. Hasonló hiba történt korábban az IB dinamikus frissítésekor.

Mert Ez a probléma többször is felmerült, és úgy döntött, hogy megosztja a kezelési lehetőséget.

A konfigurátor következő futtatásakor hiba történt: „Figyelem!!! Hiba történt az adatok frissítése során az utolsó átalakítás után. Megpróbálja újra a frissítést?" Ha a válasz igen, a következő üzenetet kapjuk: „Hiányos konfigurációs mentési művelet észlelve. A munka folytatásához be kell fejeznie a műveletet ”, majd az alkalmazás bezárul.

A probléma elemzése során több megoldás is született a problémára, mindegyik megoldás más-más esetekben működik.

1. lehetőség (ha van egy SQL biztonsági másolata azonos konfigurációjú másolattal):

A rendszer az IB másolatát telepíti, és a következő konstrukciót kéri:
HASZNÁLATA GO DELETE FROM .. GO INSERT INTO ..>SELECT * FROM .. GO
Ezzel egyidejűleg a táblázat, amelyben az IS-konfigurációt tárolja, újratöltésre kerül. E művelet után célszerű IS tesztelést és korrekciót végezni.

2. lehetőség (ha nincs biztonsági mentés):

Ez a lehetőség az utolsó csepp a pohárban. Mert a konfiguráció fejlesztés alatt állt, és egy kicsit megfeledkeztek a mentésről, a tárhelyre hagyatkozva.
Az adatbázisban két rekord törlődik a "Config" táblából a "FileName" oszlopban lévő értékkel - dbStruFinal és véglegesítés

A következő kérés érkezik:
HASZNÁLATA GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "commit" GO
Furcsa módon az alap életre kel.

Címkék: 1s enterprise 8.2, SQL, konfiguráció visszaállítás

Ez a cikk nem kommentálható, mivel a szerzője még nem teljes jogú tagja a közösségnek. A szerzővel csak azután léphet kapcsolatba, miután megkapta

Új szerverre költöztünk. Rajta SQL és 1C. A régiekhez képest sokkal menőbb volt. És Gilev tesztje is ezt igazolta: a régi szervereken 10-15 ellenében 39-et adott ki. Ezért a vásárlás után azonnal átvittük az adatbázist és elkezdtük a munkát.

De valamikor valami elromlott - a felhasználók panaszkodni kezdtek lassú munka. Elvégeztük a szerver és a szolgáltatások bizonyos beállításait (melyek egy külön bejegyzés témája), és úgy döntöttünk, hogy újraindítjuk a szervert, mivel az újraindítási sebesség 2 perc volt (más szervereken elérte a 10-et). Ezt követően az 1C beírásakor a következő üzenetet kapjuk:

"Figyelem!!! Hiba történt az adatok frissítése során az utolsó átalakítás után. Megpróbálja újra a frissítést?" "Nem igazán"

Az "Igen" gombra kattintás után a következő jelenik meg:

"Hiányos konfiguráció mentési műveletet észleltünk. A folytatáshoz be kell fejeznie a műveletet."

Az első dolog, ami mellett döntöttem, a CHECKDB volt a Managment Studio-ban – 2 óra várakozás után (500 GB adatbázis) – minden rendben van.

A hálózat szélességében olyan információt találtam, hogy ugyanez a hiba történik a dinamikus frissítéseknél is.

A hálózaton javasolt megoldások nem segítettek azonnal, de más akciókkal együtt eredményt hoztak. Szóval amit csináltam:

Megoldás:

1. Ami hiányzott a hálózatból származó megoldásokhoz:

sp_configure 'frissítések engedélyezése', 1
konfigurálja újra felülbírálással
megy

2. Vigye át az adatbázist helyreállítási módba

adatbázis-készlet módosítása EMERGENCY, SINGLE_USER

3. Adatbázis tesztelést végzünk:

dbcc checkdb('db_name', REPAIR_ALLOW_DATA_LOSS)

4. Kihozzuk az adatbázist a helyreállítási módból:

adatbázis-készlet módosítása ONLINE, MULTI_USER

5. Elvileg, ha biztos vagy benne, hogy magával az alappal minden rendben van, akkor nem tehetsz 2-4 pontot. Ezután két lekérdezést hajtunk végre az SQL-profilozóban:

törlés a konfigurációból ahol FileName = 'commit'
törlés a konfigurációból, ahol FileName = 'dbStruFinal'

Ezek a bejegyzések felelősek a dinamikus frissítésért – nem félhet törölni őket.

Az adatbázisok működő verzióiban a lekérdezések:

válassza ki a *-ot a Config-ból WHERE FileName = 'commit'

válassza ki a * elemet a konfigurációból WHERE FileName = 'dbStruFinal'

üres lesz.

6. állítsa vissza a beállításokat:

sp_configure 'frissítések engedélyezése', 0
megy

7. Ezt követően sikerült elindítani a konfigurátort és az adatbázis működni kezdett.

Az alap az első zászló eltávolítása után is működhet.

Amikor az 1C:Enterprise alkalmazásban dolgozik, a következő üzenet jelenhet meg: „To work with új verzió 1C:Enterprise, az információs bázist át kell alakítani. Miért jelenik meg ez az ablak, és hogyan javíthatom ki a hibát?

A legtöbb esetben az ablak megjelenésének oka a program legutóbbi átállása elavult verzió platformokat egy újabbra. Különböző platformokon információs bázis 1C a maga módján formálódik és más összetételt vesz fel. Nem kell mást tenni, mint az adatbázist (amelynek szerkezete megfelel az elavult platformnak) a legújabb formátumra konvertálni.

DB átalakítás

Ez az eljárás egyszerű, azonban ajánlott először létrehozni biztonsági mentés alap, ha hiba történik az átalakítás során (például a számítógép kikapcsol információs bázis 1C, valamint maga a program is megsérülhet). Ezután alkalmazza a következő műveleti algoritmust:

• Nyissa meg az adatbázist konfigurátor módban;
• Megjelenik egy üzenet, amely arra kéri, hogy konvertálja az információs bázist. Nyomja meg a megerősítést;

• Zárja be a konfigurátort.

Nyissa meg az adatbázist - gond nélkül el kell indulnia. Ha a hibaablak továbbra is megjelenik az átalakítás után, megpróbálhatja újra az eljárást. Abban az esetben, ha ez nem segít, lépjen kapcsolatba az 1C programozóval. Előfordulhat, hogy a program lefagy egy művelet végrehajtása közben. Jelenleg nincs szükség semmilyen intézkedésre.

Fontos! Információs bázis 1C, átalakult legújabb verzió a programok nem nyithatók meg a korábbi verziókon.

háttér

Létre kellett hoznunk egy új „MessageTrackingLog” információs regisztert. Hozzáadva a konfigurációhoz, betöltve az adatokat. Aztán jött az optimalizálási munka. Változtatnom kellett a nyilvántartás szerkezetén. De nem volt ott!

Itt minden világos. A bejegyzések nem egyediek lettek, törölni kell őket!

A legegyszerűbb módja a következő:

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

Ezzel a módszerrel nagyon gyorsan töröljük a regisztert 1C-ben (de ez is a mi hibánk lesz).

Hiba

Úgy tűnik, hogy a regiszter üres, és frissítheti az 1C-t. Nem akarlak meglepni, de ismét hiba lesz:

Mi a hiba:

Az infobázis frissítése során hiba történt. kritikus hiba
mert:
Nem egyedi érték beszúrása egy egyedi indexbe:
Microsoft SQL Szerver Native Client 11.0: A CREATE UNIQUE INDEX utasítás leállt, mert a rendszer a „dbo._InfoRgChngR34546NG” objektumnévhez és a „_InfoR34546_ByNodeMsg_RNTSRRRRRRNG” indexnévhez duplikált kulcsot talált. A duplikált kulcs értéke (0x00000011,d7, , 4015. szeptember 27. 22:22, 768404.00.00.00.00.00.00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, állapot=1, Súlyosság=10, natív=1505, sor=1

Magyarázat

Ismerjük meg az SQL szerkezetét. Van nyilvántartásunk "MessageTrackingLog", SQL-ben a "táblázatban van" _InfoR34546". Ezt speciális feldolgozással vagy "poke" metódussal ellenőrizheti (ezt nem kell megtennünk, mert a hibaszövegben már szerepel a táblázat neve).

Most hadd magyarázzam el, mi történt. Amikor betöltöttük az adatokat a regiszterbe, akkor SQL-ben a táblázatba kerültek " _InfoR34546". Amikor töröltük a táblát a kóddal az 1C-ben, ez az adat törölve lett a " táblázatból _InfoR34546", de át lettek másolva a " táblázatba _InfoRgChngR34546". Ez lett a probléma.

Megoldás

A probléma megoldásához törölnünk kell a "_InfoRgChngR34546" SQL táblát.

Elmondom a "Microsoft SQL Server Management Studio" példáján. Megyünk " Menedzsment Stúdió". Megkeressük az adatbázisunkat, megnyitjuk a táblázatok lapot, kattintson bármelyikre, és nyomjuk meg az "Új lekérdezés" gombot: Most beírjuk a lekérdezést

"_InfoRgChngR34546" táblázat csonkolása

Lehet még egy asztalod is! Ne felejtsd el!

És nyomja meg a Futtatást vagy az F5 billentyűt. Ez legyen az eredmény:

Mindent, most már biztonságosan frissítheti az 1C-t, és nem lesz hiba!