Hiba az 1c táblázat indexfájljának megnyitásakor 7.7. Egyetlen indexfájl átalakítása címkévé

Bevezetés

Napsütéses nyári nap volt, nyoma sem volt a bajnak, amikor megcsörrent a telefon, és a másik végén lévő alkalmazott azt mondta: "Úgy tűnik, megöltem az ügyfélkört." A részleges lekérdezés után a következők derültek ki: egy rendes távoli asztalon (RDP) konfigurációs frissítést hajtottak végre az adatbázis átszervezésével, az ilyen frissítéseket naponta ezerötszázszor hajtják végre. Ezúttal azonban valami elromlott, és az adatbázis összeomlott.

Nál nél újraindít a program üzenetet adott

és utána beesett a Windowsba. A biztonsági másolat birtoklása lehetővé tette volna az adatbázis rövid időn belüli helyreállítását, de a munkavállaló emberi gondatlansága, aki nem szán több percet az elkészítésére, azt eredményezte, hogy a javítás körülbelül négy napot vett igénybe a problémát, több helytelen lépést tettek, amelyek nem vezettek jelentős eredményhez. Az alábbiakban leírom a helyes módszert.

Az alap helyreállítása

Az interneten végzett keresés olyan oldalakra vezetett, amelyek ezeket a problémákat leírják megoldás nélkül, de hamarosan két fontos linkre bukkantak, amelyek a pontos helyreállítás kiindulópontját jelentették:

1. lépés.Mi igen biztonsági mentés elrontott alap

A táblázatok listájának megtekintése mellett van egy fontos funkció a konfiguráció kiürítéséhez. Elindítjuk a segédprogramot, megnyitjuk az adatbázist. A bázis hibaüzenetek nélkül nyílt meg, ez jó jel!

3. lépés. A sérült adatbázis fájl szerkezetének elemzése

Tehát, mint tudják, a CD -fájl lényegében a táblafájlok tárolója. Nyissa meg a Hex szerkesztőt (például nyílt forráskódú http://en.wikipedia.org/wiki/HxD), kövesse a 0x4000 linket. Van egy táblázat a fő adatbázis és a konfigurációs táblák eltolásához.

Lírai kitérő

Minden cím abszolút címzésben van tárolva, ami megnehezíti a helyesbítést kézi üzemmód, ha valamelyik tábla megsérült, nem az első a listában. Másrészt leegyszerűsíti az 1C programozók munkáját, és felgyorsítja a szükséges táblázatok memóriába való betöltésének folyamatát.

Nézzük tehát a táblázatot a HEX szerkesztőből:

Ez a bal oldali kép a Tool_1CD segédprogram táblázatlistájának jobb oldalán lévő HEX szerkesztőt mutatja. Ezek ugyanabban a sorrendben vannak, mint a CD -fájlban. Itt látjuk, hogy a CONFIG táblázat 0x5000 -nél kezdődik és 0x31F0FFF -nél végződik, ahol a táblázat kezdődik CONFIGSAVE 0x31F1000 (azoknak, akik még soha nem programoztak az összeszerelésben, azt mondom, hogy a gépi kódokban szereplő számok jobbról balra vannak írva - a cári rendszer ereklyéje). Szigorúan véve, 0x5000 a táblázat fejléce CONFIG, amely még egy fejlécre utal, majd maga a táblázat következik (lásd a fájlformátum leírását a fenti linken). Joggal feltételezhető, hogy ha az 1C esküszik a konfigurációra, akkor ezt a táblázatot kell kijavítanunk, ehhez ki kell húznunk a CONFIG táblát a mentett konfigurációból (vagy ha nem mentettük, akkor közelítsük meg a konfigurációt lehetőleg a sérültnek) és helyettesítse a címen 0x5000, de a táblázat nem lépheti túl a 0x31F0FFF értéket.

Frissítés 2012.10.10

Fontos jegyzet :

Az 1C név szerint táblázatokra utal, és nem mindegy, hogy melyik táblázat szerepel a listában először, melyik a második stb.Csak egy új adatbázis létrehozásakor az 1C egymás után hozza létre a szükséges táblákat abban a sorrendben, ahogy ezt az alkotást az 1C programozói írták. Ezért mindig kiderül, hogy a CONFIG az első, a CONFIGSAVE a második, stb. De ha az első táblázat néhány _REFERENCE152 lenne, és a CONFIG a tizenhetedik lenne a listában, az 1C csendesen működne egy ilyen bázissal.

4a. Lépés. Töltse be a ki nem töltött konfigurációt az üres konfigurációba (elnézést a szójátékért)

Töltött. Leírták. Megnézzük a HEX szerkesztőt

Tehát valami nincs rendben, új táblázat került hozzáadásra. Ezért a következtetés: A helyreállítást ugyanazon a platformon kell elvégezni, mint a sérült adatbázist.

5b. Lépés. Ugyanazon platformverzió ki nem töltött konfigurációját töltjük be az üres konfigurációba

Lássuk az eredményt:

Igen, az eredmény sem túl jó. A CONFIG tábla 0x10FFF véggel végződik, és úgy tűnik, hogy nincs átalakítva. Rendben, próbáljuk meg a Tool_1CD munkalapot nem működő adatbázisba másolni. Válassza ki a blokkot a munkabázisban, és másolja le a cserével 0x5000 méretben a sérült alapra:

Nyissa meg a Tool_1CD -t, nyissa meg a sérült bázist, de sajnos A Tool_1CD lefagy, amikor megpróbálja megtekinteni a CONFIG táblázatot. Több helytelen lépés után ötletem támadt: mi van, ha az 1C strukturálja a táblákat adatbázis betöltésekor? Ezután még ki kell tölteni és be kell tölteni az adatbázist a működő konfigurációval.

5c lépés. Ugyanazon platformverzió ki nem töltött konfigurációját betöltjük az üres konfigurációba, kirakjuk és betöltjük az adatbázist (nem a konfigurációt!).

Lássuk, hogyan néznek ki most az eltolások:

Most már jobban. A CONFIGSAVE most a 0x31FC000 címen található, ami nagyobb, mint 0x31F1000. Hogyan másolhat egy nagyobb CONFIG táblablokkot egy éles adatbázisban egy kisebbbe egy sérült adatbázisban? A válasz egyszerű: el kell távolítania a metaadatokat a működő konfigurációból, amely nem befolyásolja a szerkezetét: közös modulok, képek, jelentések, feldolgozás stb. Fontos, hogy elindítsuk a sérült adatbázist, később visszaállítjuk a konfigurációt.

Az adatbázis törlésének, kirakodásának és betöltésének többszöri ismétlése után a következő képet kaptam:

Végül: A CONFIGSAVE 0x313B0000 -nál kezdődik<0x31F1000. Most válassza ki a 0x5000- blokkot x313AFFF a munkaállomáson és a 0x5000 címen a sérült bázison, másolja le cserével

Leírjuk. Megnyitjuk az 1C -t. Ok, minden működött.

Frissítés 2012.10.10

Fontos jegyzet

Általában a 0x4000 eltolásnál a táblázatleíró fájlokra mutató hivatkozások találhatók. És már a táblázatok leírásának fájljaiban is vannak hivatkozások a rekordok, indexek és BLOB -ok tábláira. Általánosságban elmondható, hogy ha a CONFIG tábla 0x5000, a CONFIGSAVE táblázat 0x31f1000 értékről indul, nincs garancia arra, hogy nincs olyan blokk 0x5000 és 0x31f1000 között, amely a CONFIG. A legtöbb esetben a CONFIG tábla nem töredezett, ezt szerintem azzal magyarázzák, hogy az egyik tábla fájljainak egymás utáni elrendezése úgy történik, hogy az egész tábla mintegy 1CD fájlban van egy folyamatos darab, az adatbázis -tömörítés tesztelés és javítás során, vagy a chdbfl.exe segédprogram használata során keletkezik.

Csak a működő konfiguráció betöltése az adatbázisba a működő adatbázis helyreállítása érdekében. Ennyi, a bázist helyreállították.

P.S. Természetesen ez az eset leírja az egyszerű meghibásodások kijavítását, azonban még egy ilyen egyszerű eset is megzavarhatja a tapasztalt szakembereket, ha nincsenek szabványos módszerek a probléma megoldására. Ne felejtsen el biztonsági másolatot készíteni.

Vannak esetek, amikor egy táblázat vagy index megsérülhet. Ennek oka lehet a mysql vagy a feldolgozandó adatkészlet változása. Például hiba történt a szortírozás során, meg kell javítania a táblázatot, hogy frissítse az összehasonlítást használó karakteroszlopok indexeit. Szükség lehet a táblák visszaállítására is, miután ellenőriztük a táblák integritását a CHECK TABLE, mysqlcheck vagy mysql_upgrade parancsokkal.

A táblázatok helyreállításához, újbóli létrehozásához mysql adatbázis frissítés vagy leminősítés esetén csak a dump-and-reload módszert használja (biztonsági másolatot készít egy tábláról, majd visszaállítja belőle). Ezért a mysql adatbázis frissítése vagy az adatbázis leminősítése előtt létre kell hoznia egy adatbázis -kiíratást, például a mysqldump használatával. Frissítés vagy leminősítés után állítsa vissza az adatbázist a dump fájlból. Ha ezt a módszert csak az indexek újjáépítésére használja, akkor a ki- és visszaállítás elvégezhető a verzió frissítése vagy visszaállítása előtt és után is.

A tábla újbóli létrehozásához a dump és visszaállítás használatával kövesse az alábbi lépéseket:

mysqldump db_név tábla1> dump_table.sql

mysql db_name< dump_teble.sql

Az összes táblázat visszaállításához nem kell felsorolni őket, használja a következő parancsokat:

mysqldump db_név> dump.sql

mysql db_name< dump.sql

Az összes adatbázis összes táblájának visszaállítása mysql adatok felhasználási lehetőség -Minden adatbázis

mysqldump-minden adatbázis> dump.sql

mysql< dump.sql

A tábla újbóli létrehozása a paranccsal ALTER TABLE ne cserélje ki a tárolómotort, használja a már meglévőt, például My MySam esetén:

ALTER TABLE table1 táblázat MOTOR = MyISAM

Ha nem biztos abban, hogy melyik tárolómotort használja a táblázathoz, a parancs futtatásával megtudhatja:

MUTASSA LÉTREHOZÁSI TÁBLÁZATOT táblázat paramétereinek megjelenítéséhez.

Ha újra létre kell hoznia a táblát, mert a tábla ellenőrzése azt jelzi, hogy a táblázat sérült, használja a következő parancsot: JAVÍTÁSI TÁBLÁZAT, csak ha adott típus tároló tábla támogatja ezt a műveletet. Például a MyISAM támogatja, ezért futtatjuk:

JAVÍTÁSI TÁBLÁZAT 1. táblázat

Asztaltároló rendszerekhez Az InnoDB, a JAVÍTÁSI TÁBLÁZAT nem támogatott... Az ilyen táblák újbóli létrehozásához és visszaállításához használja mysqldump hogy hozzon létre egy kiíratást, majd állítsa vissza azt, az elején leírtak szerint.

mysqlcheck - javítás- lehetővé teszi a táblázatok helyreállítását ugyanúgy, mint a JAVÍTÁSI TÁBLÁZAT, csak ez a kifejezés kényelmesebb, mivel használhatja az opciókat -Adatbázisok vagy-összes adatbázis az összes tábla egyidejű javítása meghatározott adatbázisokban és minden mysql adatbázisban:

mysqlcheck -javítás -adatbázisok db_név1 db_név2 ...

mysqlcheck —javítás — minden adatbázis

A MySQL 5.1.24 hibakód # 27877 utf8_general_ci és ucs2_general_ci kódolással (kódolással) rendelkezik, a MySQL 5.1.62, 5.5.21 és 5.6.5 verzióiban javították. Telepítse a javított verziók bármelyikét, majd konvertálja a táblázatokat az alábbi módszerek egyikével:

Módosítsa a kódolást (szortírozást) utf8_general_mysql500_ci és ucs2_general_mysql500_ci értékre, amelyek megfelelnek a MySQL 5.1.24 utf8_general_ci és ucs2_general_ci paramétereinek

Az érintett táblák átalakításához a frissítés után módosítsa a beállításokat az új leválogatási értékekkel. Tegyük fel, hogy a táblázat egy vagy több problémás utf8 oszlopot tartalmaz. Az ilyen táblák konvertálásához használja a következő parancsot:

ALTER TABLE table1 CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

Ha módosítani szeretné az oszlopokat, használja ugyanazt a parancsot COLLATE nélkül:

ALTER TABLE table1 MODIFY c1 CHAR (N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

Frissítés lehívási és visszaállítási eljárással. Hozzon létre egy dump fájlt, módosítsa a benne található kifejezések kódolását TÁBLÁZAT LÉTREHOZÁSA, megtehető automatikus cserével, majd visszaállítás a dump fájlból.

Az elvégzett javítások után ELLENŐRZŐ TÁBLÁZAT nem szabad hibákat adni.

Ha problémái vannak a mysql adatbázissal, és nem tudja megoldani, kérjük, vegye fel velünk a kapcsolatot (elérhetőségek), örömmel segítünk.

Az indexfájl csak akkor nyitható meg, ha a megfelelő táblázatfájlt korábban megnyitották. Ellenkező esetben hibaüzenet jelenik meg. Az indexfájl megnyitásához ki kell adnia a következő parancsot:

SET INDEX TO [indexfájlok listája]

[OP< CDx-fájl>]]

Az opciók funkciója megegyezik a USE és az INDEX ON parancsokkal.

A USE paranccsal egy táblázatfájl megnyitásával egyidejűleg megnyithat egy meglévő indexfájlt (lásd a 2.2. Fejezetet „Táblázat megnyitása”).

Az összes indexfájl bezárásához meg kell adni az egyik parancsot: vagy INDEX BEÁLLÍTÁSA opciók nélkül, ill ZÁRÓ MUTATÓ.

A jelenlegi index cseréje

Egyszerre több indexfájl nyitható meg minden táblához, de csak egy index lesz aktuális (aktív). Alapértelmezés szerint azt feltételezzük, hogy az aktuális index lesz az első abban a sorrendben az indexfájlban, amelynek nevét először a USE parancs vagy parancs indexfájljainak névlistájában kell feltüntetni INDEX BEÁLLÍTÁSA.

A parancs használatával az aktuális indexfájl bármely indexe aktuálissá tehető

RENDELÉS BEÁLLÍTÁSA

[<выр. N1> | < idx-fájl> | ]

[ NÖVEKEDŐ | LESZÁLLÓ]

Opciók hozzárendelése:

<выр.Nl> - beállítja az aktuális indexet sorszámával a többindexes fájlban.

- egyindexes fájlt tesz aktuálissá.

CÍMKE<имя тега> - beállítja az aktuális indexet címke neve alapján a megadott többindexes fájlból. Ha az opciót kihagyja, a címke az aktuális többindexes fájlból kerül kiválasztásra.

BAN BEN<выр.N2> - jelzi a munkaterület számát, amelyben az indexfájl található. Az opció akkor használható, ha a táblázatfájl egy munkaterületen van nyitva, az indexfájl pedig egy másik munkaterületen.

Az indexet a Táblázattervező párbeszédpanel segítségével is aktuálissá teheti, ha a kívánt index leíró karakterláncát az első helyre helyezi át.

Indexfájlok újjáépítése

A nagy táblák módosítása időigényes, mivel minden módosítás újjáépíti az összes nyitott indexfájlt. Idő megtakarítása érdekében az indexfájlokat bezárják, és a táblázatot módosítják. Ebben a forgatókönyvben azonban eltérés van a frissített táblázat és az indexfájlok között. Ezen eltérés kiküszöbölése érdekében az indexfájlokat újra kell építeni. A módosítotthoz tartozó összes indexfájl megnyitása után táblázatos fájl, parancsot kell adnia REINDEX. A parancs az aktuális munkaterületen megnyitott összes indexfájlt érinti. Az újraindexelést a főmenüből származó parancs kiadásával is el lehet végezni Táblázat -> Indexek újjáépítése.

Egyetlen indexfájl átalakítása címkévé

Ha egy táblázatfájl egy vagy több egyindexes fájlt birtokol, akkor címkékként másolhatók egy többindexes fájlba. Ehhez használja a parancsot

MÁSOLÁSI MUTATÓK< neveketidx -fájlokat> | ÖSSZES

Az ALL opció akkor van megadva, ha az összes egyindexes fájlt másolni szeretné. Ebben az esetben a nevek listája <имена idx-файлов> nem meghatározott. A címkékhez az egyindexes fájlok neve tartozik. Több egyindexes fájl másolásakor nevük vesszővel elválasztva jelenik meg. Ha a TO lehetőséget kihagyja, akkor az egyindexes fájlok átmásolódnak az aktuális többindexes fájlba. Ha a TO beállítás egy nem létező többindexes fájl nevét tartalmazza, akkor létrejön.

A fordított művelet is lehetséges, vagyis egy címke a következő paranccsal konvertálódik (másolható) egy indexű fájlba:

MÁSOLÁS CÍMKE<список имен тегов>(NAK,-NEK<с dx-fájl>] TO< idx-fájl>]

A többindexes fájlt előzetesen meg kell nyitni. Meghatározásával másolhatja az egyes címkéket<список имен тегов>, vagy az összes címkét az ALL opció használatával.

Előbb vagy utóbb minden 1C felhasználó életében nehéz pillanat következik be, amikor egy kedvenc program nem hajlandó foglalkozni vele, egyáltalán nem indul el, vagy gyakran érthetetlen üzeneteket ad ki egy személynek. Tehát mit akar nekünk mondani az 1C, és mit tehetünk érte?

1. "Hiba a metaadatok betöltésekor"

2. "Az adatbázishoz beállított rendezési sorrend eltér a rendszertől!"

Ez a hiba akkor fordul elő, ha az infobázis rendszerkódolása és kódolása eltérő (lásd: http://www.goto1c.ru/2011/04/ordnochkprm.html).

3. "Adatzárolási hiba"

Az adatbázist exkluzív módban használják (talán te vagy az). A probléma kiküszöböléséhez be kell zárnia az 1C: Enterprise szekciót, kizárólagos hozzáféréssel az adatbázishoz, és fel kell osztott módba lépnie. Ha az 1C: Enterprise exkluzív módban nem fut a számítógépen, akkor két lehetőség közül választhat.

Az első lehetőség akkor alkalmazható, ha kevés számítógép van a hálózatban az 1C: Enterprise használatával, vagy ha közel vannak egymáshoz. Az 1C: Vállalati súgó -> A program menüpontjának kiválasztásával minden számítógépen látni fogja a sorban Munkaórák... Ha az „Exkluzív” felirat van írva a bal oldalon, akkor be kell zárnia az 1C: Enterprise -t ezen a számítógépen.

A második lehetőséget akkor kell használni, ha sok számítógép van a hálózaton. Ezután el kell indítania a monitort a Start-> Programok-> 1C: Enterprise-> User Monitor paranccsal. A monitor elindítása után ki kell választania a Monitor -> Aktív felhasználók menüpontot. Megjelenik azoknak a számítógépeknek a listája, ahonnan lehet Ebben a pillanatban az alapot használják (minden sor egy futó 1C komponens: Configurator, Enterprise, Monitor, Debugger). Ha figyel a bal szélső oszlopra, látni fogja, hogy az 1C: Enterprise az egyik számítógépen exkluzív módban fut (ez pirosan jelenik meg) felkiáltójel ikon mellett). Menjen ehhez a számítógéphez, és zárja be az 1C: Enterprise programot. A problémát most meg kell oldani.

Néha előfordulhat, hogy néhány számítógép helytelenül (vagy egyszerűen "lefagyott") állt le, akkor ki kell kapcsolnia, majd újra be kell kapcsolnia. Ha lehetetlen megállapítani, hogy melyik számítógép foglalta el a bázist, és a monitor nem jelzi a kizárólagos módot használó számítógépet, akkor meg kell találnia és le kell állítania az 1cv7.exe folyamatot a kezelőben Windows feladatok vagy kapcsolja ki az összes számítógépet (egyenként is lehet, az egyes számítógépek kikapcsolása után próbálja elindítani az 1C -t).

4. "A felhasználói címtár foglalt"

5. "Nem található adatbázis -könyvtár"

Ez annak köszönhető, hogy a mappa, amelyben az 1C adatbázis található, nem érhető el. Ha az adatbázis a számítógépen van, akkor valószínűleg áthelyezte valahova. Ne feledje, ha könyvtárakat (mappákat) áthelyezett ide mostanában... Ha pontosan tudja, hová helyezte az alapot, akkor az 1C indításakor a párbeszédpanelen válassza a "Módosítás" gombot (jobb oldalon az OK, a Mégse és a következő gombok - "Módosítás"). Adjon meg egy új elérési utat az adatbázishoz, és az OK gombra kattintva indítsa újra az 1C: Enterprise -t.

Ha az alap nem a számítógépen van, hanem be van kapcsolva távoli szerver, jobb, ha segítséget kér attól a személytől, aki felelős a vállalat számítógépeinek teljesítményéért. Ha mégis úgy dönt, hogy saját maga oldja meg a problémát, akkor először ellenőriznie kell a két számítógép közötti hálózat jelenlétét (egyszerűen ellenőrizheti a kiszolgáló számítógép jelenlétét az ügyfél számára elérhető számítógépek listájában kattintson a "Hálózati helyeim" ikonra). Másodszor, meg kell találnia a könyvtár helyét a bázissal a szerveren. Ezt követően az 1C: Enterprise indítás párbeszédpanelen a "Módosítás" gombra kattintva válassza a "Hálózati helyek" -> Szerver, ahol az adatbázis található -> Adja meg az adatbázis elérési útját.

6. "Hiba a táblázat indexfájljának megnyitásakor. Az indexfájlok visszaállításához futtassa a programot exkluzív módban "

A probléma megoldásához exkluzív módban kell futtatnia a programot (a program indításakor jelölje be a "Kizárólag" négyzetet). Természetesen először minden felhasználót meg kell kérnie, hogy lépjen ki az 1C: Enterprise -ból. Igenlő választ kell adni az indexfájlok visszaállítására vonatkozó ajánlatra. Ez a folyamat jelentős időt vehet igénybe, az 5-10 megabájtos bázisok esetében 1-2 perctől a nagy bázisoknál körülbelül egy óráig. Ha nem tudja elindítani a rendszert exkluzív módban, bár biztos abban, hogy minden felhasználó kilépett a programból, akkor először ellenőrizze a számítógépet, talán ott maradt a program futó példánya. Ha ez nem segít, próbálja meg kikapcsolni az ügyfélgépeket (egyenként is megteheti, mindegyik után ellenőrizze). Valószínű, hogy az egyik programot helytelenül fejezték be, és nem szabadította fel a bázist.

7. "A naplófájl sérült"

A bázis könyvtárában (a bázis elérési útja az indító ablak alján van írva) található egy Syslog alkönyvtár. Ez a könyvtár tartalmazza az 1cv 7.mlg fájlt, amely a naplófájl. Áthelyezés másik könyvtárba; ha úgy gondolja, hogy nincs szüksége a naplófájlra, törölheti azt. A lényeg az, hogy távolítsa el a naplófájlt ebből a könyvtárból. A következő indításkor az 1C: Enterprise -t sikeresen kell indítania, és létre kell hoznia egy üres naplófájlt.

8. A program indításakor megjelenik egy felugró képernyő, amelyen az 1C: Enterprise felirat látható, és azonnal eltűnik.

Ez a hiba akkor fordul elő, amikor a platform észleli a futtatandó fájlokat, de a folyószámlát (az operációs rendszer fiókja, nem tévesztendő össze) fiókot"1C: Enterprise") nincs hozzáférési jogosultsága annak a könyvtárnak, ahol az információs bázis található. Az 1C: Enterprise esetében be kell lépni ebbe a könyvtárba. A helyzet kijavításához a kiszolgálón, ahol a bázis található, válassza a lehetőséget közös erőforrás(lemez vagy könyvtár az alappal), kattintson a jobb egérgombbal, válassza a Tulajdonságok menüt, a Hozzáférés fület, állítsa be a Teljes értéket (vagy rendezze át az indikátort a általános hozzáférés a "Windows 2000 rendszerhez" mappába). Mentse el a módosításokat, indítsa újra az 1C: Enterprise -t.

9. Futtatási hiba! C program: \ Program Files \ 1Cv77 \ Bin \ 1Cv77.exe. Rendellenes befejezés "

Ennek a hibának több lehetséges oka is lehet. Először másolja át az adatbázis könyvtárát egy másik helyre, hogy a legrosszabb esetben is (a lámpák lekapcsoltak a javítási folyamat során) visszatérhessen a javítás megkezdése előtti állapothoz. Ön is megteheti következő lépések kijavítja ezt a hibát. Minden lépés után próbálja meg elindítani az 1C: Enterprise -t.

a) Indítsa újra a számítógépet.

b) Telepítse újra az 1C: Enterprise -t.

c) Másolja át az 1Cv 7.md fájlt, amely a bázis ÚJ _STRU könyvtárában található, a bázissal rendelkező könyvtárba. Például, ha az alapja a c: \ 1C \ base könyvtárban van, akkor az 1Cv 7.md fájlt át kell másolnia a c: \ 1C \ base \ NEW _STRU fájlból a c: \ 1C \ base fájlba. A kérdésre: "Le szeretné cserélni az aktuális fájlt?" a válasz „Igen” legyen.

d) Indítsa el a Configurator programot, válassza az Administration -> IB Testing and Correction lehetőséget. Kattintson a Futtatás gombra.

10. „Végzetes adatbázis -hiba. Kód - 10. Hiba az adatbázis -szótár megnyitásakor "

Másolja az 1Cv7.dd fájlt, amely a bázis NEW_STRU könyvtárában található, a bázis könyvtárába. Például, ha az alapja a c: \ 1C \ base könyvtárban van, akkor az 1Cv7.dd fájlt át kell másolnia a c: \ 1C \ base \ NEW_STRU fájlból a c: \ 1C \ base fájlba. A kérdésre: "Le szeretné cserélni az aktuális fájlt?" a válasz „Igen” legyen. Ha ilyen fájl nem létezik a NEW_STRU könyvtárban, de ismeri a konfigurációs jelszót, a problémákat úgy oldhatja meg, hogy átnevez bármilyen metaadat objektumot magának (például törölje az utolsó "l" betűt a konstans "MainFile" azonosítójából "és tegye vissza). Mentse el a konfigurációt.

11. DT táblázat hozzáférési hiba *

Ugyanakkor túllépte a megengedett maximális mennyiséget fájlok megnyitása Windows 9x rendszeren.

A tény az, hogy a Windows 95/98 egyszerre legfeljebb 1024 fájlt tud megnyitni. Ez a korlátozás akkor lép hatályba, ha a hálózati üzemmódban az adatbázis egy alatt futó számítógép megosztott lemezén található Windows vezérlés 95/98. Az 1C indításakor minden csatlakoztatott felhasználó megnyitja a konfigurációban szereplő összes .dbf és .cdx fájlt. A konfiguráció összetettségétől függően 3-6 felhasználó egyszerre dolgozhat az 1C-vel ebben a módban.

Ha ilyen problémával találkozik, akkor WinNT / 2000/2003 számítógépet kell használnia fájlszerverként (azaz olyan számítógépet, amelyen az infobase könyvtár található). Csak szem előtt kell tartania, hogy a WinNT Workstation (2000 Professional) nem korlátozza a megnyitott fájlok számát, de legfeljebb 10 -et engedélyez egyidejű kapcsolatok... Azok. egy számítógépen egyszerre legfeljebb 10 felhasználó dolgozhat adatbázisokkal. Ha dolgozni akarsz több egyidejűleg a felhasználókat, vagyis érdemes megfontolni a lehetőséget dedikált szerverrel és operációs rendszer Windows 2000/2003 szerver.

Ha áthelyezte az adatbázist a Windows 2003 Server rendszerre, és továbbra is ugyanazt a hibát kapja, akkor ellenőrizze a felhasználók (számítógépek) csatlakoztatásához szükséges licencek számát a Win Server 2003 rendszerben - alapértelmezés szerint csak 5 van.

12. "A program védelmi kulcsa nem található"

Ez a hiba több okból is előfordulhat. A megoldási lehetőségek attól függenek, hogy hálózati vagy helyi verzióval rendelkezik -e. Kezdjük azzal helyi mint egy egyszerűbb esetből.

Javasoljuk, hogy kövesse ezeket a lépéseket. Minden kísérlet után próbálja meg elindítani az 1C: Enterprise -t. Lehetséges, hogy a probléma az első lépésben megoldódik, és akkor nem lesz szükség az összes későbbi problémára.

a) Indítsa újra a számítógépet a Start -> Leállítás -> Számítógép újraindítása -> OK gombra kattintva. Várja meg, amíg a számítógép újraindul, majd próbálja meg újra elindítani az 1C -t.

b) Lehet, hogy elfelejtette telepíteni a védelmi illesztőprogramot a program telepítésekor. Ezután el kell indítania a Start-> Programok-> 1C: Enterprise 7.7-> Védelmi illesztőprogram telepítése gombra kattintva. Indítsa újra a számítógépet, és próbálja meg újra elindítani az 1C: Enterprise -t. Ha valamilyen okból nem telepítette az illesztőprogramot, akkor telepítse azt a szoftverhez mellékelt lemezről, vagy töltse le a http://www.aladdin.com/support/hasp/hasp4/enduser.aspx webhelyről.

c) Ellenőrizze a kulcs fizikai jelenlétét a számítógépen, lehet, hogy kiugrott a számítógépről. Ehhez el kell jutnia a számítógép hátuljához, ahol a vezetékek csatlakoztatva vannak. Fontos: Erősen ajánlott, hogy először kapcsolja ki a számítógépet. A kulcs körülbelül 3x4x1 cm méretű blokknak tűnik. Valószínűleg piros vagy fehér lesz. A kulcs be van helyezve az LPT portba (ugyanott, ahol a nyomtató). Mindenesetre csak a kulcsot helyezheti be az LPT portba. Fontos: nem kell nagy erőt kifejtenie, az erőfeszítésnek összehasonlíthatónak kell lennie egy pohár tea felemelésével. Ha a kulcs nem illeszkedik a portba, ne próbálja erővel behelyezni, mert vagy nem kulcs, vagy nem az LPT portba helyezi. Jobb, ha felhívja a vállalat számítógépeivel megbízott személyt. Miután behelyezte a kulcsot a portba, kapcsolja be a számítógépet, és próbálja meg újra elindítani az 1C: Enterprise -t.

d) Néha a kulcs "tetején" elhelyezett nyomtató és egyéb berendezések zavarhatják a biztonsági szerver általi meghatározást. Miután korábban kikapcsolta a számítógépet és a nyomtatót, próbálja meg leválasztani a perifériákat (leggyakrabban a nyomtatót) a számítógépről, és hagyja a kulcsot a helyén. Most kapcsolja be a számítógépet, és próbálja meg elindítani az 1C -t. Természetesen ebben az esetben nem tudja használni a leválasztott eszközt.

Ha használja hálózati verzió, és a kulcs nem található a számítógépen, ajánlott segítséget kérni attól a személytől, aki felelős a számítógép számítógépének működéséért. Ha Ön ez a személy, akkor javasoljuk, hogy kövesse az alábbi lépéseket:

a) Ellenőrizze, hogy a problémás számítógép "látja" azt a szervert, amelyen a kulcs található. A pinget a parancssorból is pingálhatja, ha a ping programot a problémás számítógépről futtatja, a paraméterként a kiszolgáló számítógép nevét. Például: c: ping szerver 1c. Vagy egyszerűen ellenőrizheti a szerver számítógép jelenlétét az ügyfél számára elérhető számítógépek listájában a Saját hálózati helyek ikonra kattintva. Ha kiderül, hogy a problémás számítógép nem "látja" a szervert, akkor maga kell eljárnia standard csekk nál nél hálózati problémák... Javasoljuk, hogy kezdje a kábelek épségének ellenőrzésével (nincs megszakítás), a hub működőképességével, a hálózati kártya működőképességével, emellett győződjön meg arról, hogy rendelkezik a szükséges protokollokkal és a megfelelő konfigurációval.

b) Győződjön meg arról, hogy a "Protection Server" alkalmazás fut a számítógépen a kulccsal. Ez a program szükséges ahhoz, hogy az 1C: Enterprise ügyfelek hálózati verzióban működjenek. A Start-> Programok-> 1C: Enterprise 7.7-> Protection Server-gombra kattintva indíthatja el.

c) Minden 1C: Enterprise számítógéppel rendelkezik nethasp .ini fájl, amely alapértelmezés szerint a C: \ Program Files \ 1Cv 77 \ BIN mappában található. Ez a fájl a program beállításait tartalmazza, amely ellenőrzi a kulcs jelenlétét a hálózaton. A fájl jól dokumentált, és valószínűleg rájön a szerkezetére. Javasoljuk, hogy fordítson különös figyelmet az alkalmazott protokollok soraira (talán csak egy IPX / SPX van hátra, amelyet egyáltalán nem használ a hálózatban), a kulcskeresés várakozási idejére (gyenge hálózat esetén programnak egyszerűen nincs ideje megtalálni), és hivatkozik a szerver számítógépre (lehetséges, hogy ilyen számítógép már nem létezik, áthelyezték vagy átnevezték).

Talán a hardverkulcs "élethosszig tartó". Ebben a helyzetben kapcsolatba kell lépnie a szállítójával. szoftverés írjon kérelmet a védelmi kulcs cseréjére. Vagy az "1C: Enterprise" példányában nincs adott kulcs... Végül is a kulcsot csak licencelt szoftverrel szállítjuk.

A cikk a http://help1c.com, http://www.ititi.ru, http://it-specialist.perm.ru webhelyekről származó anyagokat használta fel.

A leggyakoribb hibák 1C 7.7

1. hiba az 1SCONST tábla indexfájljának megnyitásakor. Az indexfájlok visszaállításához futtassa a programot exkluzív módban.

Általában ez akkor történik, amikor kezdeti telepítés bázisok. Megoldás kéri)) Futtassa az 1C -t exkluzív módban. Az 1C indexeli az adatbázist, és letölthető lesz.

2. a rendezési sorrend eltér a rendszertől.

Ez a hiba leggyakrabban az 1C operációs rendszerekre történő első telepítésekor jelentkezik. Windows Vistaés a Windows 7. A Windows operációs rendszer és az 1C Enterprise 7.7 program különféle rendezési mechanizmusaihoz kapcsolódik.

Itt két lehetőség van.

2.1. Egy számítógépe van Windows Vista / 7 és 1C [b] vagy hálózatos, de minden számítógépen Windows Vista / 7 van.
Ebben az esetben meg kell változtatnia az 1C Enterprise 7.7 rendezési sorrendjét magában az adatbázisban.

Ez így történik:
- Az 1C -t az üzemmódban indítjuk Vállalati konfigurátor 7.7;
- Válassza ki az elemet " Adminisztráció" -> "IB oldalak kódtáblája";
- A listában válassza ki a legalacsonyabb elemet - " Jelenlegi rendszer telepítése ";
- rendben.

2.2 Többfelhasználós verziója van, de különböző operációs rendszerrel rendelkező felhasználók dolgoznak benne - Windows XP, Windows Vista, Windows 7.
Ebben az esetben le kell tiltania a rendezési sorrend ellenőrzését.

Hozzon létre egy jelölőfájlt a névvel OrdNoChk.prm bármilyen tartalommal. üres lehet;
- ha van egy adatbázisa, akkor ezt a fájlt eldobhatja magának a programnak, azaz itt: \\ 1Cv77 \ Bin \ Így tilthatjuk le a rendezési sorrend ellenőrzését az 1C programban. De ez minden alapot érint.
- ha sok adatbázisa van, akkor jobb, ha ezt a fájlt az adatbázisban lévő mappába dobja. Ezután a rendezési sorrend ellenőrzésének letiltása csak ezt az alapot érinti, ahol ez a jelölő (vagy jel) fájl található. Tegyük fel, hogy három alapja van. A Windows XP rendszerben két bázissal dolgoznak, a harmadikkal pedig - különböző rendszerek... Ezután, ha csak a harmadik bázisra küldjük a jelölőfájlt, akkor képesek lesznek együttműködni a harmadik bázissal különböző rendszerekből.

Miért nem dobja ki a fájlt OrdNoChk.prm v KUKAés nem tiltja le az összes adatbázis rendezési sorrendjének ellenőrzését egyszerre?
Mivel:
- Ily módon csak a 26. platformról és felülről működik;
- Az 1C figyelmeztet: Ennek a funkciónak a használata csak szélsőséges esetekben ajánlott, amikor nem lehetséges a rendszer rendezési sorrendjének összeegyeztetése az infobázishoz beállított rendezési sorrenddel. Ha a rendezési sorrend ellenőrzése le van tiltva az elosztott információbázis-kezelő összetevő használatának feltételei között, akkor NE használjon semmilyen ábécé szimbólumát, kivéve a latint, hárombetűs azonosítóban információs bázisok szerepel az elosztottban. Nem szabad megfeledkezni arról, hogy az 1C: Enterprise mindkét mechanizmus rendezési képességét használja munkája során, és a rendelésazonosság ellenőrzésének letiltása a rendszerben váratlan sorrendhez vezethet a felhasználó számára, például jelentések készítésekor".

Ezért, ha valamilyen bázissal dolgoznak ugyanabban a rendszerben, akkor jobb, ha a szabványos képességeket használják. - Például változtassa meg az oldal kódtábláját a bázisban, és működjön normálisan.
- Vagy használjon jelölőfájlt, de szelektíven a különböző operációs rendszerekben használt adatbázishoz, anélkül, hogy megérintené a többit.

Ez a megközelítés rugalmasabbnak és helyesnek tűnik.

Ezenkívül emlékezni kell a következőkre!

Célszerű megkeresni az adatbázisokat egy Windows XP -n futó gépen, és OrdNoChk.prm mappába tenni KUKA Windows 7 (Vista) számítógépen. Ezzel elkerülhetők az olyan alkatrészek működésével kapcsolatos esetleges problémák, mint pl URIB... Emlékeztetni kell arra, hogy a Windows 7 (Vista) rendszerű gép csak 1C Enterprise módban használható.
A Configurator mód bármilyen módosítását csak Windows XP rendszerű gépen szabad elvégezni.
Ha az adatbázisok egy Windows 7 (Vista) rendszerű gépen találhatók, mindenképpen vigye az IB kódlapot a rendszerbe (az első módszer szerint), és használja az OrdNoChk.prm programot a Windows XP operációs rendszerrel rendelkező gépeken, ellenkező esetben dolgozzon a URIB vagy egyszerűen nem lehet korábban feltöltött adatokat betölteni az IB -be.

3. Hiba a V7Plus.dll összetevőből történő létrehozáskor (hiányzó CLSID)

Ez a hiba abból adódik, hogy a könyvtárak nincsenek regisztrálva az operációs rendszerben. Ebben az esetben - V7Plus.dll.
Az 1C dinamikusan regisztrálja a könyvtárakat, azaz az első híváskor a kívánt könyvtárba.
De nem lehet.
Ez általában a jogok hiánya miatt történik, vagy amikor UAC(Windows Vista / 7 alatt). Ha engedélyezve van UAC Az 1C felhasználói jogokkal működik, ezért nem tudja regisztrálni a könyvtárat.
Két megoldás létezik:
- másolat V7Plus.dll(vagy a kívánt könyvtárat) a mappába KUKA 1C (hogy ne kötődjön egy adott adatbázishoz), és egyszer megzavarja az 1C -t a rendszergazda nevében, vagy egy rendszergazdai jogokkal rendelkező fiókból. Mivel a rendszergazda jogosultsággal indul, a könyvtár regisztrálva lesz.
- kézzel regisztráljon. Ehhez fuss parancs sor rendszergazdai jogokkalés adja ki a parancsot regsvr32 \ BIN \ V7Plus.dll, a végrehajtás eredménye egy üzenet a könyvtár sikeres regisztrációjáról.

4. Hiba "Az adatbázis eléréséhez ODBC illesztőprogram szükséges az MS SQL -hez Szerver verziók 3.50.0303 vagy régebbi.

A hiba akkor fordul elő, amikor megpróbálja futtatni az 1C Enterprise 7.7 SQL verziót Windows 7 (Vista) rendszeren, és abban áll, hogy az SQL Server ezen operációs rendszer -verziói nem támogatottak SQL szerver 2005 SP2.

Részlet a Microsoft hivatalos sajtóközleményéből:
Több biztosítása érdekében magas szint biztonság, Microsoft operációs rendszerek Windows Server 2008 és Microsoft Windows A Vista támogatja az SQL Server 2005 SP1 Express Edition kiadást, és minden más SQL Server kiadáshoz SQL Server 2005 SP2 vagy újabb szükséges. Több korai verziók SQL Server, beleértve az SQL Server 2000 -t (minden kiadás, beleértve a Desktop Engine -t, más néven MSDE -t), az SQL Server 7.0 és az SQL Server 6.5, működőképes Windows rendszerek A Server 2008 és a Windows Vista nem támogatott.

Jelenleg nincs megoldás (és nem valószínű, hogy megjelenik).

Mint alternatív lehetőség javasolhatja az 1C Enterprise elindítását a Windows Server 2003 rendszeren terminál módban, ugyanezt a lehetőséget ajánljuk az 1C fájlmódhoz a Windows különböző verzióival rendelkező hálózatban.