"A konfigurációs szerkezet integritása megsértve" hiba. Hiba "A konfigurációs struktúra integritása megsérült A konfigurációs struktúra integritása megsértődött 8.2 javítás módja

A hiba általában akkor fordul elő, ha a konfiguráció mentése során hiba történt. Ennek eredményeként a konfiguráció hibásan lett elmentve.

1. Próbálja meg ellenőrizni a tesztelést és a javítást vagy a ChDBFl.exe fájlt
2. Tekintse meg a probléma alábbi megoldásait:

Bizonyos esetekben a CACHE teljes törlése segít Windows 7-ben a C:\Users\Administrator\AppData\Roaming\1C\1Cv82 és a C:\Users\Administrator\AppData\Local\1C\1Cv82 (Win7x64).

vagy részletesebben:
1. Ugyanazon verzió tiszta konfigurációja szükséges - működik.
2. Teljes gyorsítótár-tisztítás (fentebb megadva).
3. Futtasson egy tiszta adatbázist konfigurátor módban, és nyissa meg a konfigurációt. Ezzel egyidejűleg az 1C létrehozza a gyorsítótárát a C:\Users\Administrator\AppData\Local\1C\1Cv82 mappában (a konfigurációs azonosítóval rendelkező mappában lévő fájlok és mappák halmaza.) Szükségünk van egy C:\Users\ gyorsítótárra is. Administrator\AppData\Roaming\1C\1Cv82. Az 1C bezárása után egyszerűen átnevezheti ezeket a mappákat.
4. Elindítjuk a nem működő adatbázisunkat konfigurátor módban, és megnézzük a gyorsítótárat. Ennek eredményeként két mappánk van konfigurációs azonosítóval (Live and Dead).
5. Bezárunk mindent, és a dead conf gyorsítótárát teljesen lecseréljük egy élőre. Azok. törölje az aktuális mappát, és cserélje ki a korábban átnevezett mappára.
6. Konfigurátor módban elindítunk egy nem működő adatbázist ÉS ITT az első siker - a konfigurációs fa megnyílt, a konfigurációkezelés menü részei aktívak.
7. A támogatási menedzsmenthez fordulunk, és teljesen kivonjuk a támogatásból. mentés, frissítés. A működő alap konfigurációs fájlon keresztül frissíthető.
8. Teljesen távolítsa el a gyorsítótárat.
9. Konfigurátor módban elindítunk egy nem működő adatbázist, megpróbáljuk megnyitni a konfigurációt - minden megnyílik, nincs hiba.
10. Elindítjuk az 1C-t. Minden elérhető. Adatok a helyükön.

Ugyanez az üzenet volt, amikor dinamikusan frissítettem a központi adatbázis konfigurációját és cseréltem a perifériásra, és hasonló üzenet jelent meg a periférián.
1. Mert Egyáltalán nem indultam el a konfigurátorban a periférián, törölnöm kellett a C:\Documents and Settings\Admin\Application Data\1C\1Cv81 mappát.
2. A konfigurátorhoz mentem, és a Konfiguráció - Adatbázis konfiguráció - Vissza az adatbázis-konfigurációhoz lehetőséget választottam.
3. MasterNode telepítve undefined.
4. Konfiguráció - Konfiguráció betöltése fájlból (központi konfiguráció).
5. A MasterNode telepítette a szükségeset.

Volt hasonló helyzetem, de a 8.1. A konfiguráció dinamikus frissítése során nyilvánvalóan hiba lépett fel, amely után a Main conf és a DB conf eltávolítására tett kísérlet, a fájl helyi adatbázisba való feltöltésének további kísérlete során „megsértették a konfigurációs struktúra integritását " kiesett. De az adatbázis működik. Sem a tesztelés és a javítás, sem a ChDBFl.exe nem hozott semmit.

A működő adatbázisról biztonsági másolatot készítettem és feltöltöttem egy tiszta adatbázisba. Hozzáadott csereterv
http://kb.mista.ru/article.php?id=7
és létrehozta a kezdeti képet. A képadatbázisban a konfiguráció javításra került.

Ha ez nem segít, akkor azt a lehetőséget tudom ajánlani, amelyet magamnak szerettem volna igénybe venni:
1. keresse meg a legközelebbi konfigurációs kiadást, töltse be egy tiszta adatbázisba (helyreállítható).
2. hozzon létre egy teljesen tiszta adatbázist (köztes)
3. nyissa meg a sérült adatbázis konfigurátorát.
4. copy-paste a legutóbbi kiadás óta megváltozott modulokat, objektumokat (esetemben ez sokkal egyszerűbb, mivel a változások csak modulokban és űrlapokban történtek, az adatstruktúra változatlan maradt és minden változást poszterek dokumentálnak) innen a sérült adatbázist a közteshez.
5. Töltse ki a köztes konfigurációt.
6. Egyesítse össze a visszaállítandó adatbázissal.
7. Töltse ki a visszaállított konfigurációt egy fájlba.
8. Töltse be a visszaállított konfigurációt a sérült adatbázisba.

Elméletileg a maximális közelítést kell elérni a munkaalaphoz, de a munka természetesen nem könnyű. De még mindig jobb, mint az egész alapot elveszíteni.

Egy másik megoldás a sérült szolgáltatói konfigurációval kapcsolatos problémára. Ha olyan konfigurációt frissít, amely szerkeszthető támogatással rendelkezik, és a szállítói konfiguráció integritása megsérül, a következő üzenet jelenhet meg:

Az én megoldásom az adatbázis-szállító konfigurációnk lecserélése.
A műveletek sorrendje a következő:
1. Távolítsa el a gyártó konfigurációját a támogatás eltávolításával (Konfiguráció->Támogatás->Támogatás beállítása-> Támogatás eltávolítása)
2. Hozzon létre egy konfigurációs kézbesítő fájlt (Konfiguráció->Konfiguráció kézbesítés->Konfigurációs kézbesítési és frissítési fájlok létrehozása). Ebben az esetben a fájlmunkát szállítási fájlnak nevezzük.cf
3. Konfigurációnkat kombináljuk az újonnan létrehozott kézbesítési fájllal (Konfiguráció->Összehasonlítás, egyesítjük a fájlból származó konfigurációval). Ebben az esetben ismét megjelenik egy javaslat a konfiguráció támogatására.
A megjelenő konfiguráció-összehasonlító ablakban kattintson a "Futtatás" gombra.
4. Frissítse az adatbázis konfigurációját (Konfiguráció->Adatbázis konfiguráció frissítése).
Elméletileg ezen lépések végrehajtásával átstrukturáltuk a szolgáltató konfigurációját.
Most megpróbálhatjuk a szokásos módon frissíteni konfigurációnkat a következő verzióra.

Ma elmondom, milyen lépéseket kell tenni, ha az 1C 8.2 konfiguráció frissítése után a „A konfigurációs struktúra integritását megsértették” hibaüzenet összeomlik.
Tehát a lényegre: megpróbálhatja megoldani a problémát a következőképpen (mielőtt bármelyik konfigurációs műveletet elindítaná, ne felejtsen el archív másolatot készíteni az adatbázisról, amint azt egy megjegyzésben írtam arról, hogyan kell ezt megtenni):

• Hozzon létre egy új üres adatbázist egy új mappában, és töltse be a konfigurációba a korábban feltöltött információs bázist, amelyet frissíteni kell.

Ha az opciót elvi megoldásként használod a probléma megoldására, akkor a kellemetlenség abban rejlik, hogy a többfelhasználós munka során át kell írni az adatbázis elérési útjait. Megpróbáljuk frissíteni ezt a konfigurációt, majd futni.

Ha a probléma megoldódott, akkor valószínűleg meg kell tisztítani az 1s cache mappát ( C:\Dokumentumok és beállítások\Felhasználó\Helyi beállítások\Alkalmazásadatok\1C\1Cv82). A mappa nagy valószínűséggel alapértelmezés szerint el van rejtve, ezért ha nem tudja, hogyan férhet hozzá a rejtett Windows fájlokhoz és mappákhoz, javasoljuk, hogy olvassa el a megjegyzést. Az 1Cv82 és 1Cv81 gyökérmappákban lévő fájlokat az aktuális/utolsó módosítás dátumával nem szabad megérinteni. A start ablakok beállításait tárolják. Ebben az esetben is minden beindul, de akkor az első indításnál várni kell.

A probléma megoldása után (amennyiben természetesen a javasolt módszer segít), azt javaslom, hogy készítsen ismét egy archív másolatot az adatbázisról, és ellenőrizze a konfigurációt hibákra a szabványos 1C Test and Fix eszközzel.

Az információbiztonság tesztelése és javítása

Lépjen a konfigurátorba, és az "Adminisztráció" menüpontban válassza a "Tesztelés és javítás" lehetőséget:

Az eszköz 2 üzemmódban működik

• A tesztelés egy olyan mód, amely csak a konfigurációs hibákat ellenőrzi.

• Tesztelés és javítás - olyan mód, amelyben a konfigurációs hibák ellenőrzése és javítása is megtörténik.

Amikor az információs bázis befut fájl verzióés munkalehetőség kliens-szerver, lehetőség van a logikai integritás, a hivatkozási integritás tesztelésére, javítására, az összegek újraszámítására Az infobázis fájlverziójához lehetőség van az adatbázis újraindexelésére és tömörítésére.

Az olyan elosztott információs bázisok (DRIB) esetében, amelyekből a tesztelt információs bázisban nem szereplő objektumokra mutató hivatkozásokat tartalmazó adatok érhetők el, törölje a jelölőnégyzet bejelölését. Egy információs bázis hivatkozási integritásának ellenőrzése lehetővé teszi a "nem létező" adatok létrehozásának letiltását, és ennek eredményeként nem vezet ezeknek az adatoknak az elosztott információs bázis más csomópontjaihoz való átviteléhez.

Lehetetlen engedélyezni az IS hivatkozási integritás ellenőrzését a logikai integritás ellenőrzésének letiltásával. Ezenkívül a hivatkozási integritás-ellenőrzés letiltása nem jelenti azt, hogy a hivatkozástípus-ellenőrzés le van tiltva.

A leggyengébb pont például a Számvitelnél a Mérleg, ezért a feldolgozás előtt és után javaslom a forgalom létrehozását és a tesztelés, korrekció előtti és utáni végösszegek összehasonlítását. Ez természetesen nem a tesztelés csúcsa, de legalább valami.

Ennyit akartam neked ma elmondani. Viszlát.

A dinamikus frissítés nem sikerült. A program Enterprise módban továbbra is elérhető maradt a felhasználók számára, de a konfigurátor megszakadt.

Kiinduló adatok: 1C Enterprise 8.3, kliens-szerver adatbázis, MS SQL 2012, MS SQL használatával konfigurált biztonsági mentés, a biztonsági mentések naponta egyszer, éjszaka készülnek.

A konfigurációt módosították és aktívan dolgoznak rajta, így volt egy második szerverbázisom, ahol a fejlesztés zajlott, plusz az előző napon mindkét bázisról volt feltöltés a dt-re. A cikkben szereplő munkabázis neve "MyBase", a készenléti szerverbázis neve pedig "MyTestBase"/

Az én esetemben a ConfigSave adatbázistábla üres volt, mint a leírt anyagokban, a Config és a Params táblák pedig "DynamicallyUpdated" értékű sorokat tartalmaztak a FileName mezőben.

A hálózatból származó anyagok, amelyeket a probléma megoldására használtam:

Az ügyfél úgy döntött, hogy a munkanap végén elvégzi a helyreállítási munkát, az aktuális napi adatvesztés kockázatával (a helyreállítási eljárás sikertelensége és az éjszakai biztonsági mentés szükségessége esetén).

A probléma megoldására a következő lépéseket tettük:

1. Az összes felhasználói munkamenet letiltása 1s

2. A szerverekkel ellátott felügyeleti konzolon 1 beállítható a munkamenetek kezdetének blokkolása és az ütemezett feladatok indításának törlése.

3. A működő adatbázisról biztonsági mentés készült MS SQL használatával, SQL Server Management Studio segítségével. lekérdezések táblákból

eltávolította a "DynamicallyUpdated" értékekkel rendelkező bejegyzéseket a Fájlnév mezőben a Config és a Params táblákból:

és
Törlés innen..
HOL MINT "Dinamikusan frissítve"

4. A konfigurátor segítségével az utolsó unloading.dt a működő adatbázisból (az előző nap este) betöltődött a biztonsági mentési adatbázisba, és az aktuális nap utolsó működő konfigurációja a meglévő .cf fájlból a tetejére (a a konfigurációs változások teljes előzménye külön fájlokban van tárolva verziószámokkal)

5. A feladatkezelőben le kellett tiltanom az 1s8 függő folyamatokat

6. Leállított szerverszolgáltatás 1c

7. Gyorsítótár 1C

Az én esetemben a C:\Users\Administrator\AppData\Local\1C\1сv8 mappák átnevezése volt.

C:\Users\Administrator\AppData\Roaming\1C\1CEStart

C:\Felhasználók\Rendszergazda\AppData\Roaming\1C\1Cv82

C:\Users\Administrator\AppData\Roaming\1C\1Cv8

8. A szerverszolgáltatás elindult

9. A gyorsítótár tisztítása után az 1C indításakor az adatbázisok listáját tartalmazó ablak üres, ezért hozzáadjuk a meglévő működő szerver adatbázist

10. Megnyílik a konfigurátor. Minden esetre kirakjuk a működő alapot .dt-be az aktuális "törött" állapotban, és bezárjuk a konfigurátort

11. Elindítjuk az SQL Server Management Studio programot, és egy lekérdezéssel töröljük a Config táblát a működő adatbázisban, és felülírjuk egy hasonló tábla tartalmával a biztonsági mentési adatbázisból:

Törlés innen..

BESZÁLLÍTÁS A ..-be: KIVÁLASZTÁS * FROM ..

A felhasznált anyagok (lásd a fenti linkeket) készítői számára az elvégzett műveletek után az adatbázis működőképes állapotba került. Az én esetemben a jelenlegi szakaszban a hiba megmaradt, nem lehetett megnyitni az adatbázis ablakot a konfigurátorban. A működő és a tartalék adatbázisok Params tábláiban található rekordok számát összevetve arra a következtetésre jutottam, hogy érdemes ezt is felülírni:

Törlés innen..

BESZÁLLÍTÁS A ..-be: KIVÁLASZTÁS * FROM ..

Ezek után sikerült elindítanom a konfigurátort és megnyitnom a konfigurációs ablakot. Minden esetre ki van töltve az aktuális állapotában .dt formátumban, és betöltve az aktuális nap utolsó működő konfigurációjában.

12. Tiltsa le a munkamenet indítási zárolását, és lépjen be vállalati módba

A teljesítmény teljesen helyreáll, adatvesztés nem történik.

13. Kapcsolja ki az ütemezett feladatok elindításának blokkolását.

A „Configuration Structure Integrity Violated” hiba számos megoldása közül az egyik.
Ha ezzel a hibával találkozik, egyértelműen forduljon az 1C szakemberéhez. Sokféle megoldás létezik, de a helyzettől és a probléma forrásától függően a megoldások teljesen eltérőek.

Felhívom a figyelmüket az egyik ilyen helyzetre.
Feladatleírás:
A konfiguráció frissítése automatikusan megtörtént. Az 1C konfigurátor mód elindításakor a "A konfigurációs struktúra integritása megsértődött" üzenetet kapjuk. Az automatikus frissítés során a szállítói konfigurációt nem sikerült megfelelően frissíteni. A felhasználói módban történő futás hibát jelez a konfigurációban lévő modulra hivatkozva.
Először is törölnie kell a gyorsítótárat. Windows 7 rendszeren a C:\Users\Administrator\AppData\Roaming\1C\1Cv82 és a C:\Users\Administrator\AppData\Local\1C\1Cv82 (Win7x64) található. A gyorsítótár törlése után az 1C konfigurátor módban indul el. Amikor megpróbálja megnyitni a konfigurációt, az 1C összeomlik. Töltse fel az információs bázist egy biztonsági mentési fájlba. A tesztelés és a javítás nem segít. A fájlbázis-ellenőrző segédprogram azt mondja, hogy nincsenek hibák. Menüpontok betöltéshez, kirakáshoz konfiguráció, támogatás stb. nyitott konfiguráció nélkül nem aktívak. Az adatkonfiguráció mentése elérhető - ez azt jelenti, hogy az adatok nem semmisülnek meg, ami a legfontosabb.
Ezenkívül a konfigurátorból a felhasználói módba hibakeresési módban elindulhat, vagy esetleg nem, ez nem befolyásolja a helyzetet.
Az infobázis SQL-be ​​való betöltésére tett kísérlet nem vezet pozitív eredményre.

És akkor felvetődik a gondolat, hogy le lehetne vetni a bázist ... felemelkedni az ősi mentésből, ha van ilyen ... és megfeszíteni a kézi adatvisszaállítással.

Megoldás:
1. Ugyanazon verzió tiszta konfigurációja szükséges - működik.
2. Teljes gyorsítótár-tisztítás (fentebb megadva).
3. Futtasson egy tiszta adatbázist konfigurátor módban, és nyissa meg a konfigurációt. Ezzel egyidejűleg az 1C létrehozza a gyorsítótárát a C:\Users\Administrator\AppData\Local\1C\1Cv82 mappában (a konfigurációs azonosítóval rendelkező mappában lévő fájlok és mappák halmaza.) Szükségünk van egy C:\Users\ gyorsítótárra is. Administrator\AppData\Roaming\1C\1Cv82. Az 1C bezárása után egyszerűen átnevezheti ezeket a mappákat.
4. Elindítjuk a nem működő adatbázisunkat konfigurátor módban, és megnézzük a gyorsítótárat. Ennek eredményeként két mappánk van konfigurációs azonosítóval (Live and Dead).
5. Bezárunk mindent, és a dead conf gyorsítótárát teljesen lecseréljük egy élőre. Azok. törölje az aktuális mappát, és cserélje ki a korábban átnevezett mappára.
6. Konfigurátor módban elindítunk egy nem működő adatbázist ÉS ITT az első siker - a konfigurációs fa megnyílik, a konfigurációkezelés menü részei aktívak.
7. A támogatási menedzsmenthez fordulunk, és teljesen kivonjuk a támogatásból. mentés, frissítés. A működő alap konfigurációs fájlon keresztül frissíthető.
8. Teljesen távolítsa el a gyorsítótárat.
9. Konfigurátor módban elindítunk egy nem működő adatbázist, megpróbáljuk megnyitni a konfigurációt - minden megnyílik, nincs hiba.
10. Elindítjuk az 1C-t. Minden elérhető. Adatok a helyükön.

Íme egy másik mentési lehetőség, amelyet Tavalik infostar felhasználó javasolt:

1. "Konfiguráció" - "Adatbázis konfiguráció" - "Vissza az adatbázis konfigurációjához"
2. "Konfiguráció" - "Az adatbázis konfigurációjának frissítése"