Recenzii 

Restaurarea fișierului index al tabelului se blochează. Reconstruirea fișierelor index

Introducere

Era o zi însorită de vară și nu existau semne de probleme când a sunat telefonul, iar angajatul de la celălalt capăt a spus: „Se pare că am ucis baza de clienți”. După interogatoriu cu pasiune, s-a dezvăluit următoarele: pe un desktop la distanță obișnuit (RDP), a fost efectuată o actualizare de configurare cu o restructurare a bazei de date, astfel de actualizări se fac de o mie cinci sute de ori pe zi; Cu toate acestea, de data aceasta ceva a mers prost și baza de date s-a prăbușit.

La repornirea programului, a fost afișat mesajul

și după aceea s-a prăbușit în Windows. A avea o copie de rezervă ar fi făcut posibilă restaurarea bazei de date în cel mai scurt timp, dar neatenția umană a unui angajat care nu a petrecut câteva minute în plus pentru a o crea a dus la faptul că rezolvarea problemei a durat aproximativ patru zile; au fost întreprinși pași greșiți care nu au condus la un rezultat semnificativ. Mai jos descriu modul corect.

Restaurarea bazei de date


 O căutare pe internet a condus la pagini care descriu aceste probleme fără o soluție, dar în curând au fost găsite două link-uri importante care au fost punctul de plecare pentru recuperare:

Pasul 1.Hai sa facem copie de rezervă baza deteriorată

Pe lângă vizualizarea listei de tabele, există o funcție importantă pentru noi pentru a descărca configurația. Lansăm utilitarul și deschidem baza de date. Baza de date s-a deschis fără mesaje de eroare, acesta este un semn bun!

Pasul 3. Analizarea structurii fișierului de bază de date corupt

Deci, după cum știți, un fișier CD este în esență o stocare a fișierelor de tabel. Deschideți un editor Hex (de exemplu, open source http://en.wikipedia.org/wiki/HxD), urmați linkul 0x4000. Iată un tabel cu compensații ale bazei de date principale și tabele de configurare.

Digresiune lirică

Toate adresele sunt stocate în adresare absolută, ceea ce face dificilă corectarea mod manual, în cazul în care un tabel care nu este primul din listă a devenit corupt. Pe de altă parte, acest lucru simplifică munca programatorilor 1C și accelerează procesul de încărcare a tabelelor necesare în memorie.


Deci, să ne uităm la masa de la Editor HEX A:

Această imagine arată un editor HEX în partea stângă și o listă de tabele din utilitarul Tool_1CD în partea dreaptă. Ordinea lor este aceeași cu cea care apar în fișierul CD. Aici vedem că tabelul CONFIG începe la adresa 0x5000 și se termină la 0x31F0FFF, unde tabelul începe următorul CONFIGSAVE la adresa 0x31F1000 (pentru cei care nu au programat niciodată în limbaj de asamblare, voi spune că în codurile mașinilor se scriu numerele de la dreapta la stânga - o relicvă a regimului țarist). Strict vorbind, Este localizat antetul tabelului 0x5000 CONFIG, care se referă la încă un antet, apoi urmează tabelul în sine (vezi descrierea formatului de fișier în linkul de mai sus). Este rezonabil să presupunem că, dacă 1C se plânge de configurație, prin urmare, acest tabel trebuie să reparăm pentru a face acest lucru, trebuie să extragem tabelul CONFIG din configurația salvată (sau dacă nu este salvată, luăm configurația; cat mai aproape de cel corupt) si inlocuieste-l la adresa 0x5000, dar tabelul nu ar trebui să depășească 0x31F0FFF.

Actualizare 10.10.2012

Notă importantă :

1C accesează tabelele după nume și nu contează care tabel este primul în listă, care este al doilea etc.Pur și simplu, atunci când creează o nouă bază de date, 1C creează tabelele necesare unul după altul, în ordinea în care programatorii 1C au scris această creație. Prin urmare, se dovedește întotdeauna că CONFIG vine pe primul loc, CONFIGSAVE vine pe al doilea etc. Dar dacă primul tabel ar fi un fel de _REFERENCE152 și CONFIG ar fi al șaptesprezecelea din listă, 1C ar funcționa cu ușurință cu o astfel de bază de date.


Pasul nr. 4a. Încărcați configurația descărcată în configurația goală (scuze pentru joc de cuvinte)

Încărcat. Înregistrate. Ne uităm în editorul HEX


Ei bine, ceva nu este în regulă, a fost adăugat un tabel nou. De aici concluzia: Restaurarea trebuie făcută pe aceeași versiune de platformă ca baza de date deteriorată.

Pasul #5b. Încărcați configurația descărcată a aceleiași versiuni de platformă în configurația goală

Sa vedem rezultatul:

Da, nici rezultatul nu este foarte bun. Tabelul CONFIG se termină la adresa 0x10FFF, se pare că nu a fost restructurat. Bine, să încercăm să copiem tabelul de lucru Tool_1CD într-o bază de date care nu funcționează. Selectăm un bloc în baza de date de lucru și îl copiem cu înlocuire la adresa 0x5000 în baza de date deteriorată:


Deschideți Tool_1CD, deschideți baza de date coruptă, dar din păcate Tool_1CD se blochează când încerci să te uiți la tabelul CONFIG. După câțiva pași incorecți, mi-a venit o idee: ce se întâmplă dacă 1C structurează tabele la încărcarea bazei de date? Apoi, tot ce rămâne este să descărcați și să încărcați baza de date cu configurația de lucru.

Pasul nr. 5c. Încărcăm configurația descărcată a aceleiași versiuni a platformei în configurația goală, descarcăm și încărcăm baza de date (nu configurația!).

Să vedem cum arată acum offset-urile:

Deja mai bine. CONFIGSAVE este acum situat la 0x31FC000, care este mai mare decât 0x31F1000. Cum pot copia un bloc mai mare din tabelul CONFIG din baza de date de lucru într-un bloc mai mic din baza de date deteriorată? Răspunsul este simplu: trebuie să eliminați metadatele din configurația de lucru care nu îi afectează structura: module comune, imagini, rapoarte, procesare etc. Este important pentru noi să lansăm baza de date deteriorată, vom restabili configurația mai târziu.

După mai multe iterații de ștergere, descărcare și încărcare a bazei de date, am obținut următoarea imagine:

În cele din urmă: CONFIGSAVE începe la 0x313B0000<0x31F1000. Acum selectați blocul 0x5000- x313AFFF în baza de date de lucru și copiați la adresa 0x5000 în baza de date deteriorată cu înlocuire

Să-l notăm. Deschide 1C. Super, totul a funcționat.

Actualizare 10.10.2012

Notă importantă

De regulă, offset 0x4000 conține legături către fișierele de descriere a tabelului. Și fișierele de descriere a tabelelor conțin legături către tabele de înregistrări, indici și BLOB. În general, dacă tabelul CONFIG „începe” la adresa 0x5000, iar tabelul CONFIGSAVE la adresa 0x31f1000, nu există nicio garanție că intervalul de la 0x5000 la 0x31f1000 nu conține un singur bloc care să aparțină oricărei alte tabele în afară de CONFIG. În cele mai multe cazuri, tabelul CONFIG nu este fragmentat, acest lucru se explică, cred, prin faptul că fișierele unui tabel sunt aranjate unul după altul, astfel încât întregul tabel să fie, parcă, situat în fișierul 1CD din o singură bucată continuă, formată ca urmare a aplicării compresiei bazei de date în timpul testării și corectării sau când se utilizează utilitarul chdbfl.exe.

Tot ce rămâne este să încărcați configurația de lucru în baza de date pentru a restaura baza de date de lucru. Gata, baza a fost restaurată.

P.S. Desigur, acest caz descrie corectarea unor defecțiuni simple, dar chiar și un astfel de caz simplu poate deruta profesioniștii cu experiență atunci când nu există modalități standard de a rezolva problema. Nu uitați să faceți copii de rezervă.

Există situații în care un tabel sau un index poate deveni corupt. Acest lucru se poate datora modificărilor în mysql sau în setul de date procesat. De exemplu, există o eroare de colare și trebuie să restaurați tabelul pentru a actualiza indecșii coloanelor de caractere care folosesc colarea. De asemenea, restaurarea tabelelor poate fi necesară după verificarea integrității tabelelor folosind comenzile CHECK TABLE, mysqlcheck sau mysql_upgrade.

Pentru a restaura sau recrea tabelele în cazul unei actualizări sau downgrade a bazei de date mysql, utilizați numai metoda dump-and-reload (crearea unei copii de rezervă a unui tabel și apoi restaurarea acestuia din acesta). Astfel, înainte de a actualiza baza de date mysql sau de a downgrade versiunea bazei de date, trebuie să creați un dump al bazei de date, de exemplu folosind mysqldump. După actualizarea sau downgrade-ul versiunii, restaurați baza de date din fișierul de descărcare. Dacă utilizați această metodă numai pentru a recrea indecși, atunci descărcarea și restaurarea se pot face atât înainte, cât și după actualizarea sau derularea versiunii.

Pentru a recrea tabelul folosind dump și restaurare, rulați următoarele acțiuni:

mysqldump db_name table1 > dump_table.sql

mysql db_name< dump_teble.sql

Pentru a restaura toate tabelele nu este nevoie să le listați, utilizați următoarele comenzi:

mysqldump db_name > dump.sql

mysql db_name< dump.sql

Pentru a restaura toate tabelele din toate bazele de date date mysql utilizați opțiunea --toate-bazele de date

mysqldump --all-databases > dump.sql

mysql< dump.sql

Pentru a recrea un tabel folosind comanda ALTER TABLE nu schimba motorul de stocare, foloseste-l pe cel care exista deja, de exemplu pentru MyIsam:

ALTER TABLE table1 ENGINE = MyISAM

Dacă nu sunteți sigur ce motor de stocare este folosit pentru un tabel, puteți afla rulând comanda:

AFIȚI CREATE TABLE pentru a afișa parametrii tabelului.

Dacă trebuie să recreați tabelul deoarece verificarea tabelului a returnat un mesaj că tabelul este deteriorat, utilizați comanda: MASA DE REPARATIE, doar daca acest tip depozitarea la masă acceptă această operație. De exemplu, MyISAM îl acceptă, așa că rulăm:

TABEL DE REPARAȚII tabelul 1

Pentru sisteme de depozitare pe masă InnoDB, REPARARE TABLE nu este acceptat. Pentru a reconstrui și a restaura astfel de tabele, utilizați mysqldump pentru a crea un dump și apoi a o restaura, așa cum este descris la început.

mysqlcheck --reparare— oferă numai capacitatea de a restaura tabele similare cu REPAIR TABLE această expresie mai convenabil cu cât puteți utiliza opțiuni --databases sau --all-databases pentru a repara toate tabelele simultan în anumite baze de date și, respectiv, în toate bazele de date mysql:

mysqlcheck --repair --databases db_name1 db_name2 ...

mysqlcheck --repair --all-databases

MySQL 5.1.24 are o eroare de codificare Bug #27877 utf8_general_ci și ucs2_general_ci, a fost remediată în versiunile MySQL 5.1.62, 5.5.21 și 5.6.5. Instalați oricare dintre versiunile corectate, apoi convertiți tabelele folosind una dintre următoarele metode:

    Schimbați codificarea (sortarea) în utf8_general_mysql500_ci și ucs2_general_mysql500_ci, care corespunde cu utf8_general_ci și ucs2_general_ci în MySQL versiunea 5.1.24

    Pentru a converti tabelele afectate după actualizare, modificați setările utilizând noile valori de colare. Să presupunem că tabelul conține una sau mai multe coloane utf8 problematice. Pentru a converti astfel de tabele, utilizați comanda:

    ALTER TABLE table1 CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

    Pentru a aplica modificări coloanelor, utilizați aceeași comandă fără COLLATE:

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

    Pentru a actualiza folosind procedura de descărcare și restaurare. Creați un fișier dump, modificați codificarea expresiilor din acesta CREAȚI TABEL, acest lucru se poate face prin înlocuire automată, apoi restaurare din fișierul de descărcare.

După ce s-au făcut corecturile VERIFICAȚI TABELUL nu trebuie să producă erori.

Dacă aveți probleme cu baza de date mysql și nu le puteți rezolva, vă rugăm să ne contactați (contacte), vom fi bucuroși să vă ajutăm.

Puteți deschide un fișier index numai dacă fișierul tabel corespunzător a fost deja deschis. În caz contrar, va fi afișat un mesaj de eroare. Pentru a deschide fișierul index trebuie să lansați comanda:

SETARE INDEX LA [listă fișiere index]

[SAU< CDx-file>]]

Semnificația opțiunilor este aceeași ca și în comenzile USE și INDEX ON.

Puteți deschide un fișier index existent simultan cu deschiderea unui fișier tabel cu comanda USE (vezi secțiunea 2.2 „Deschiderea unui tabel”).

Pentru a închide toate fișierele index, trebuie să lansați una dintre comenzile: fie SETARE INDEX LA fără opțiuni, sau ÎNCHID INDEX.

Înlocuirea indexului curent

Fiecare tabel poate avea mai multe fișiere index deschise în același timp, dar un singur index va fi curent (activ). În mod implicit, indexul curent va fi primul index din fișierul index al cărui nume este specificat primul în lista de nume de fișiere index ale comenzii sau comenzii USE SETARE INDEX LA.

Puteți face ca orice index din fișierul index curent să fie curent folosind comanda

SETĂ COMANDA PENTRU

[<выр. N1> | < idx-file> | ]

[ ASCENDENT | DESCENDENTĂ]

Scopul opțiunilor:

<выр.Nl> - setează indexul curent după numărul său de serie în fișierul multi-index.

- face curent un fișier cu un singur index.

ETICHETĂ<имя тега> - setează indexul curent după numele etichetei din fișierul multi-index specificat. Dacă opțiunea este omisă, eticheta este selectată din fișierul multi-index curent.

ÎN<выр.N2> - indică numărul spațiului de lucru în care se află fișierul index. Această opțiune este utilizată dacă fișierul tabel este deschis într-un spațiu de lucru și fișierul index este deschis într-un alt spațiu de lucru.

De asemenea, puteți face ca indexul să fie cel curent folosind panoul de dialog Table Designer mutând linia de descriere a indexului dorit pe primul loc.

Reconstruirea fișierelor index

Efectuarea de modificări la tabelele mari pierde mult timp, deoarece fiecare modificare reconstruiește toate fișierele index deschise. Pentru a economisi timp, fișierele index sunt închise și se fac modificări în tabel. Cu toate acestea, în acest caz, există o nepotrivire între tabelul actualizat și fișierele index. Pentru a elimina această discrepanță, fișierele index trebuie reconstruite. După deschiderea tuturor fișierelor index aparținând fișierului tabel modificat, trebuie să lansați comanda REINDEX. Comanda afectează toate fișierele index deschise în spațiul de lucru curent. Reindexarea poate fi efectuată și prin utilizarea comenzii din meniul principal Tabel -> Reconstruiți indecși.

Conversia unui fișier cu un singur index într-o etichetă

Dacă un fișier tabel deține unul sau mai multe fișiere cu un singur index, atunci acestea pot fi copiate ca etichete într-un fișier cu mai multe indexuri. În aceste scopuri utilizați comanda

COPIEAZĂ INDEXURI< numeidx-fişiere> | TOATE

Opțiunea ALL este specificată dacă toate fișierele cu index unic trebuie copiate. Cu toate acestea, lista de nume <имена idx-файлов> nu este specificat. Etichetele sunt atribuite nume de fișiere cu un singur index. Când copiați mai multe fișiere cu un singur index, numele acestora sunt enumerate separate prin virgule. Dacă opțiunea TO este omisă, atunci fișierele cu un singur index sunt copiate în fișierul cu mai multe indici curent. Dacă opțiunea TO conține numele unui fișier multi-index inexistent, atunci acesta este creat.

Operația inversă este de asemenea posibilă, adică o etichetă este convertită (copiată) într-un fișier cu un singur index folosind comanda:

COPIEAZĂ Eticheta<список имен тегов>(DE<с dx-file> ] TO< idx-file>]

Fișierul multi-index trebuie mai întâi deschis. Puteți copia etichete individuale specificând<список имен тегов>, sau toate etichetele folosind opțiunea ALL.

Cele mai frecvente erori 1C 7.7


1. eroare la deschiderea fișierului index al tabelului 1SCONST. Pentru a restaura fișierele index, rulați programul în modul exclusiv.

Acest lucru se întâmplă de obicei în timpul instalării inițiale a bazelor de date. Soluția a fost sugerată)) Lansăm 1C în modul exclusiv. 1C va indexa baza de date și o puteți descărca.

2. ordinea de sortare este diferită de cea de sistem.

Această eroare apare cel mai adesea în timpul instalării inițiale a 1C pe sistemele de operare Windows Vistași Windows 7. Este asociat cu diverse mecanisme de sortare în sistemul de operare Windows și programul 1C Enterprise 7.7.

Există două opțiuni aici.

2.1. Aveți un singur computer cu Windows Vista/7 și 1C [b]or rețea, dar toate computerele au Windows Vista/7.
În acest caz, trebuie să modificați ordinea de sortare pentru 1C Enterprise 7.7 în baza de date în sine.

Se face asa:
- Lansați 1C în modul Configurator Enterprise 7.7;
- Selectați elementul " Administrare" -> "Tabelul codurilor paginii IB";
- Selectați cel mai jos element din listă - " Instalarea curentă a sistemului";
- Bine.

2.2 Aveți o versiune pentru mai mulți utilizatori, dar în ea lucrează utilizatori cu sisteme de operare diferite - Windows XP, Windows Vista, Windows 7.
În acest caz, trebuie să dezactivați verificarea ordinii de sortare.

Creați un fișier de marcare cu numele OrdNoChk.prm cu orice conținut. poate fi goală;
- dacă aveți o bază de date, atunci puteți adăuga acest fișier în programul în sine, adică în \\1Cv77\Bin\ Cu aceasta dezactivăm verificarea ordinii de sortare în programul 1C. Dar acest lucru se va aplica în continuare tuturor bazelor.
- dacă aveți o mulțime de baze de date, atunci este mai bine să aruncați acest fișier în folderul cu baza de date. Apoi, dezactivarea verificării ordinii de sortare va afecta numai această bază de date, unde se află acest fișier marcator (sau semnal). Să presupunem că aveți trei baze. Funcționează cu două baze de date în Windows XP, iar cu a treia - cu sisteme diferite. Apoi, dacă aruncăm fișierul marker doar la a treia bază, atunci ei pot lucra cu a treia bază din sisteme diferite.

De ce nu încărcați fișierul? OrdNoChk.prm V COSși nu dezactivați verificarea ordinii de sortare pentru toate bazele de date simultan?
Deoarece:
- aceasta metoda funcționează numai de la platforma 26 și mai sus;
- 1C avertizează: " Utilizarea acestei caracteristici poate fi recomandată numai în cazuri extreme, când nu este posibil să fiți de acord ordine sistemică sortarea cu ordinea de sortare stabilită pentru baza de informatii. Când dezactivați verificarea ordinii de sortare în condițiile de utilizare a componentei de gestionare a bazei de informații distribuite, NU TREBUIE să utilizați caractere de alt alfabet decât latină în identificatorul de trei litere al bazelor de informații incluse în baza de informații distribuită. Trebuie reținut că 1C:Enterprise utilizează capacitățile de sortare ale ambelor mecanisme atunci când funcționează, iar dezactivarea verificării identității comenzii în acestea poate duce la o ordine neașteptată a rândurilor pentru utilizator, de exemplu, atunci când generează rapoarte".

Prin urmare, dacă funcționează cu o bază de date în același sistem, este mai bine să utilizați capabilități standard. - De exemplu, schimbare tabelul de coduri pagini din baza de date în sine și funcționează normal.
- Sau utilizați un fișier marcator, dar selectiv la baza de date care este utilizată în diferite sisteme de operare, fără a atinge restul.

Această abordare pare mai flexibilă și mai corectă.

În plus, ar trebui să vă amintiți următoarele!

Este recomandabil să localizați bazele de date pe o mașină cu Windows XP și OrdNoChk.prm pus într-un folder COS pe o mașină cu Windows 7 (Vista). Acest lucru va evita potențialele probleme cu funcționarea componentelor precum URIB. Vă rugăm să rețineți că o mașină cu Windows 7 (Vista) poate fi utilizată numai pentru a funcționa în modul 1C Enterprise.
Orice modificare în modul Configurator trebuie făcută numai pe o mașină care rulează Windows XP.
Când localizați baze de date pe o mașină cu Windows 7 (Vista), asigurați-vă că schimbați pagina de coduri de securitate a informațiilor la cea de sistem (conform primei metode) și utilizați OrdNoChk.prm pe mașinile cu Windows XP, altfel lucrați cu URIB sau pur și simplu încărcarea datelor încărcate anterior în securitatea informațiilor va fi imposibilă.

3. Eroare la crearea din componenta V7Plus.dll (lipsește CLSID)

Această eroare apare deoarece bibliotecile nu sunt înregistrate în sistemul de operare. În acest caz - V7Plus.dll.
1C înregistrează biblioteci în mod dinamic, adică când accesați prima dată biblioteca dorită.
Dar el nu poate.
Acest lucru se întâmplă de obicei din cauza lipsei de drepturi sau când UAC(în Windows Vista/7). Când este pornit UAC 1C funcționează cu drepturi de utilizator și, prin urmare, nu poate înregistra biblioteca.
Există două soluții:
- copie V7Plus.dll(sau biblioteca dorită) în folder COS 1C (pentru a nu fi legat de o anumită bază de date) și rulați 1C o dată în numele Administratorului, sau dintr-un cont cu drepturi de administrator. Deoarece este lansat cu drepturi de administrator, biblioteca va fi înregistrată.
- inregistreaza-te manual. Pentru a face acest lucru lansăm linie de comandă cu drepturi de administratorși dați porunca regsvr32\BIN\V7Plus.dll, rezultatul execuției ar trebui să fie un mesaj despre înregistrarea cu succes a bibliotecii.

4. Eroare: „Driverul ODBC pentru MS este necesar pentru a accesa baza de date SQL Server versiunea 3.50.0303 sau mai recentă.

Eroarea apare la încercarea de a rula versiunea SQL 1C Enterprise 7.7 pe Windows 7 (Vista) și se datorează lipsei de suport din partea acestor sisteme de operare pentru versiunile de server SQL mai mici decât SQL Server 2005 SP2.

Extras din comunicatul oficial de presă Microsoft:
Pentru a oferi mai mult nivel inalt securitate, sisteme de operare Microsoft Windows Server 2008 și Microsoft Windows Vista va suporta SQL Server 2005 Express SP1, iar toate celelalte ediții de SQL Server vor necesita SQL Server 2005 SP2 sau o versiune ulterioară. Mai mult versiuni timpurii SQL Server, inclusiv SQL Server 2000 (toate edițiile, inclusiv ediția Desktop Engine, cunoscută și sub numele de MSDE), SQL Server 7.0 și SQL Server 6.5, care operează sisteme Windows Server 2008 și Windows Vista nu vor fi acceptate.

Nu există nicio soluție astăzi (și este puțin probabil să apară una).

La fel de varianta alternativa putem recomanda rularea 1C Enterprise pe Windows Server 2003 în modul terminal, recomandăm aceeași opțiune pentru modul fișier 1C în rețea cu versiuni diferite Windows.

Mai devreme sau mai târziu, în viața oricărui utilizator 1C vine un moment dificil când un program preferat refuză să se ocupe de el, neîncepând deloc sau emitând mesaje care sunt adesea de neînțeles pentru o persoană fără experiență. Deci, ce încearcă 1C să ne spună și ce putem face pentru asta?

1. „Eroare la încărcarea metadatelor”

2. „Ordinea de sortare setată pentru baza de date este diferită de cea de sistem!”

Această eroare apare atunci când codarea sistemului și codificarea bazei de informații sunt diferite (vezi http://www.goto1c.ru/2011/04/ordnochkprm.html).

3. „Eroare de blocare a datelor”

Baza ta de date este folosită în modul exclusiv (poate tu însuți). Pentru a remedia această problemă, trebuie să închideți sesiunea 1C:Enterprise cu acces exclusiv la baza de date și să vă conectați în mod separat. Dacă 1C: Enterprise nu rulează în modul exclusiv pe computer, atunci sunt posibile două opțiuni.

Prima opțiune este aplicabilă dacă există puține computere în rețea care utilizează 1C: Enterprise sau sunt situate aproape unul de celălalt. Selectând elementul de meniu 1C:Enterprise Help -> Despre program de pe fiecare computer, veți vedea în rând Mod de operare. Dacă scrie „Exclusiv” în stânga, atunci trebuie să închideți 1C:Enterprise pe acest computer.

A doua opțiune ar trebui utilizată atunci când există multe computere în rețea. Apoi trebuie să lansați Monitorul cu comanda Start -> Programs -> 1C: Enterprise -> User Monitor. După ce ați lansat monitorul, trebuie să selectați elementul de meniu Monitor -> Utilizatori activi. Veți vedea o listă de computere de pe care puteți acest moment se folosește o bază de date (fiecare linie este o componentă 1C care rulează: Configurator, Enterprise, Monitor, Debugger). Dacă acordați atenție coloanei din stânga, veți vedea că unul dintre computere rulează 1C: Enterprise în modul exclusiv (acesta este afișat printr-un semn de exclamare roșu lângă pictogramă). Accesați acest computer și închideți 1C: Enterprise acolo. Problema ar trebui rezolvată acum.

Uneori este posibil ca un computer să se închidă incorect (sau pur și simplu să se înghețe), apoi trebuie să îl opriți și să îl porniți din nou. Dacă este imposibil să determinați ce computer a ocupat baza de date și Monitorul nu indică un computer care utilizează modul exclusiv, va trebui să găsiți și să încheiați procesul 1cv7.exe în Manager Sarcini Windows sau opriți toate computerele (puteți unul câte unul, încercând să porniți 1C după oprirea fiecărui computer).

4. „Directorul utilizatorilor este ocupat”

5. „Directorul bazei de date nu a fost găsit”

Acest lucru s-a întâmplat din cauza faptului că folderul în care se află baza de date 1C este inaccesibil. Dacă baza de date se află pe computerul dvs., atunci cel mai probabil ați mutat-o ​​undeva. Amintiți-vă dacă ați mutat vreun directoare (dosare) recent. Dacă știți exact unde a fost mutată baza de date, atunci când porniți 1C în caseta de dialog, selectați butonul „Schimbare” (în dreapta sunt butoanele OK, Anulare și următorul este „Schimbare”). Specificați o nouă cale către baza de date și, făcând clic pe butonul OK, lansați din nou 1C: Enterprise.

Dacă baza de date se află nu pe computerul dvs., ci pe server la distanta, atunci este mai bine să solicitați ajutor de la persoana care este responsabilă de performanța computerelor din compania dvs. Dacă tot decideți să remediați singur problema, atunci, în primul rând, trebuie să verificați prezența unei rețele între două computere (puteți verifica pur și simplu prezența unui computer server în lista de computere disponibile clientului făcând clic pe butonul pictograma „Cartierul meu de rețea”). În al doilea rând, trebuie să aflați locația directorului cu baza de date de pe server. După aceea, făcând clic pe butonul „Schimbare” din caseta de dialog de lansare 1C:Enterprise, selectați „My Network Neighborhood” -> Server pe care se află baza de date -> Specificați calea către baza de date.

6. „Eroare la deschiderea fișierului index al tabelului. Pentru a restaura fișierele index, rulați programul în modul exclusiv”

Pentru a rezolva această problemă, trebuie să rulați programul în modul exclusiv (bifați caseta „Exclusiv” când porniți programul). Desigur, mai întâi va trebui să ceri tuturor utilizatorilor să se deconecteze de la 1C: Enterprise. Oferta de restaurare a fișierelor index trebuie să primească un răspuns afirmativ. Acest proces poate dura o perioadă semnificativă de timp, de la 1-2 minute pentru bazele de date de 5-10 megaocteți până la aproximativ o oră pentru bazele de date mari. Dacă nu puteți porni sistemul în modul exclusiv, deși sunteți sigur că toți utilizatorii au părăsit programul, atunci verificați mai întâi computerul că este posibil să existe o copie a programului care rulează; Dacă acest lucru nu ajută, atunci încercați să opriți mașinile client (puteți face unul câte unul, verificând după fiecare). Este posibil ca unul dintre programe să fi fost terminat incorect și să nu fi eliberat baza de date.

7. „Fișierul jurnal este deteriorat”

În directorul bazei de date (calea către baza de date este scrisă în partea de jos a ferestrei de lansare) există un subdirector Syslog. În acest director există un fișier 1cv 7.mlg, acesta este fișierul jurnal. Mutați-l în alt director; Dacă credeți că nu aveți nevoie de fișierul jurnal, îl puteți șterge. Principalul lucru este să eliminați fișierul jurnal din acest director. Data viitoare când porniți 1C: Enterprise ar trebui să pornească cu succes și să creeze un fișier jurnal gol.

8. Când porniți programul, apare un ecran pop-up cu inscripția 1C: Enterprise și dispare imediat.

Această eroare apare dacă platforma detectează fișiere care urmează să fie lansate, dar contul curent (contul de sistem de operare, a nu fi confundat cu cont„1C:Enterprise”) nu are drepturi de acces la directorul în care se află baza de informații. 1C: Enterprise necesită o intrare în acest director pentru a lansa. Pentru a corecta situația de pe serverul pe care se află baza de date, selectați o resursă partajată (disc sau director cu baza de date), faceți clic pe Click dreapta, selectați meniul Proprietăți, fila Acces, setați valoarea la Complet (sau mutați indicatorul la „Deschidere acces generalîn folder" pentru Windows 2000). Salvați modificările și încercați să rulați din nou 1C: Enterprise.

9. "Eroare de rulare! Programul c:\Program Files\1Cv77\Bin\1Cv77.exe. „Începere anormală”

Există mai multe motive posibile pentru această eroare. Mai întâi, copiați directorul bazei de date într-o altă locație, astfel încât, chiar dacă apare cel mai rău rezultat (luminile sunt stinse în timpul procesului de corecție), să puteți reveni la situația dinaintea începerii corecției. Puteți face următorii pași pentru a remedia singur această eroare. După fiecare pas, încercați să lansați 1C: Enterprise.

a) Reporniți computerul.

b) Reinstalați 1C: Enterprise.

c) Copiați fișierul 1Cv 7.md, care se află în directorul NEW _STRU al bazei de date în directorul cu baza de date. De exemplu, dacă baza de date se află în directorul c :\1C \base, atunci trebuie să copiați fișierul 1Cv 7.md din c :\1C \base \NEW _STRU în c :\1C \base . La întrebarea: „Ar trebui să înlocuiesc fișierul curent?” ar trebui să răspunzi „Da”.

d) Lansați Configuratorul, selectați Administrare -> Testare și corectare a securității informațiilor. Faceți clic pe butonul Run.

10. „Eroare de bază de date irecuperabilă. Cod - 10. Eroare la deschiderea dicționarului bazei de date"

Copiați fișierul 1Cv7.dd, care se află în directorul NEW_STRU al bazei de date, în directorul bazei de date. De exemplu, dacă baza de date se află în directorul c:\1C\base, atunci trebuie să copiați fișierul 1Cv7.dd din c:\1C\base\NEW_STRU în c:\1C\base. La întrebarea: „Ar trebui să înlocuiesc fișierul curent?” ar trebui să răspunzi „Da”. Dacă un astfel de fișier nu există în directorul NEW_STRU, dar cunoașteți parola pentru configurare, atunci puteți rezolva problemele prin redenumirea oricărui obiect de metadate în sine (de exemplu, în identificatorul constantă MainBranch, ștergeți ultima literă „l ” și pune-l din nou). Salvați configurația.

11. Eroare de acces la tabelul DT*

Numărul maxim permis la un moment dat a fost depășit deschide fișiereîn Windows 9x.

Faptul este că Windows 95/98 vă permite să deschideți nu mai mult de 1024 de fișiere în același timp. Această restricție intră în vigoare dacă mod retea de lucru, baza de date se află pe un disc partajat al unui computer care rulează sub Control Windows 95/98. Când pornește 1C, fiecare utilizator conectat deschide toate fișierele .dbf și .cdx incluse în configurație. În funcție de complexitatea configurației, 3-6 utilizatori pot lucra simultan cu 1C în acest mod.

Dacă întâmpinați o astfel de problemă, ar trebui să utilizați un computer cu WinNT/2000/2003 ca ​​server de fișiere (adică computerul pe care este stocat directorul infobase). Trebuie doar să rețineți că WinNT Workstation (2000 Professional) nu are limită de număr de fișiere deschise, dar nu permite mai mult de 10 conexiuni simultane. Acestea. Nu mai mult de 10 utilizatori pot lucra cu baze de date pe un astfel de computer simultan. Dacă trebuie să lucrați cu mai mulți utilizatori în același timp, atunci este logic să luați în considerare opțiunea unui server dedicat și sisteme de operare Windows 2000/2003 Server.

Dacă ați transferat baza de date pe Windows 2003 Server și continuați să primiți aceeași eroare, atunci verificați numărul de licențe pentru conectarea utilizatorilor (calculatoare) în Win Server 2003 - există doar 5 în mod implicit.

12. „Cheia de securitate a programului nu a fost găsită”

Această eroare poate apărea din mai multe motive. Opțiunile de soluție depind dacă aveți o versiune de rețea sau una locală. Sa incepem cu local, ca într-un caz mai simplu.

Vă sugerăm să parcurgeți următorii pași. După fiecare încercare, încercați să lansați 1C: Enterprise. Este posibil ca problema să fie rezolvată în primul pas, iar apoi să nu fie necesare toate cele ulterioare.

a) Reporniți computerul făcând clic pe Start->Shut Down ->Restart Computer ->OK. Așteptați până când computerul repornește, apoi încercați să porniți din nou 1C.

b) Este posibil să fi uitat să instalați driverul de securitate la instalarea programului. Apoi trebuie să-l lansați făcând clic pe Start ->Programe->1C: Enterprise 7.7->Instalare driver de protecție. Reporniți computerul și încercați să porniți din nou 1C: Enterprise. Dacă din anumite motive driverul nu a fost instalat, atunci instalați-l de pe discul inclus cu software-ul sau descărcați-l de pe site-ul http://www.aladdin.com/support/hasp/hasp4/enduser.aspx.

c) Verificați prezența fizică a cheii pe computer, este posibil să fi sărit din computer. Pentru a face acest lucru, trebuie să ajungeți la peretele din spate al carcasei computerului, unde sunt conectate firele. Important: este foarte recomandat să opriți mai întâi computerul. Cheia arată ca un bloc de aproximativ 3x4x1 cm Cel mai probabil, va fi roșie sau albă. Cheia este introdusă în portul LPT (în același loc cu imprimanta). În orice caz, puteți introduce cheia doar în portul LPT. Important: nu trebuie să exerciți multă forță, eforturile ar trebui să fie comparabile cu eforturile de la ridicarea unui pahar de ceai. Dacă cheia nu se potrivește în port, nu încercați să o forțați, deoarece fie nu este o cheie, fie nu o introduceți în portul LPT. Este mai bine să sunați la persoana responsabilă cu computerele din compania dvs. După ce ați introdus cheia în port, porniți computerul și încercați să porniți din nou 1C: Enterprise.

d) Uneori, o imprimantă și alte echipamente plasate „pe deasupra” cheii pot interfera cu detectarea acesteia de către serverul de securitate. După ce ați oprit mai întâi computerul și imprimanta, încercați să deconectați perifericul (de obicei, imprimanta) de la computer, lăsând cheia pe loc. Acum porniți computerul și încercați să porniți 1C. Desigur, în acest caz, nu veți putea folosi dispozitivul dezactivat.

Dacă utilizați versiunea de rețea, iar cheia nu se află pe computerul dvs., este recomandat să solicitați ajutor de la persoana care este responsabilă de performanța computerelor din compania dvs. Dacă sunteți această persoană, atunci vă putem sfătui să faceți următoarele:

a) Verificați dacă computerul cu probleme „vede” serverul pe care se află cheia. Puteți fie să dați ping la server de la Linie de comanda rulând programul ping de pe computerul cu probleme cu numele computerului server ca parametru. De exemplu, c: server ping 1c. Sau puteți verifica pur și simplu prezența unui computer server în lista de computere disponibile clientului făcând clic pe pictograma „My Network Neighborhood”. Dacă se dovedește că computerul cu probleme nu „vede” serverul, atunci va trebui să efectuați o verificare standard pentru problemele de rețea. Vă recomandăm să începeți prin a verifica integritatea cablurilor (fără întreruperi), funcționalitatea hub-ului, funcționalitatea plăcii de rețea, în plus, trebuie să vă asigurați că sunt disponibile protocoalele necesare și că sunt configurate corect.

b) Asigurați-vă că programul „Server de protecție” rulează pe computer cu cheia. Acest program este necesar pentru funcționarea clienților 1C: Enterprise în versiunea de rețea. Îl puteți lansa făcând clic pe Start -> Programs -> 1C: Enterprise 7.7 -> Protection Server.

c) Pe fiecare computer cu 1C: Enterprise există un fișier nethasp .ini, care se află implicit în C:\Program Files\1Cv 77\BIN. Acest fișier conține setări pentru programul care verifică prezența unei chei în rețea. Fișierul este destul de bine documentat și probabil vă puteți da seama de structura acestuia. Vă recomandăm să acordați o atenție deosebită liniilor protocoalelor utilizate (poate că a mai rămas un singur IPX/SPX, care nu este folosit deloc în rețeaua dvs.), timpul de așteptare pentru căutarea unei chei (dacă rețeaua este slabă , este posibil ca programul pur și simplu să nu aibă timp să-l găsească) și să facă legături către computerul server (poate că un astfel de computer nu mai există, a fost mutat sau redenumit).

Poate că cheia de protecție hardware a murit. În această situație, trebuie să vă contactați furnizorul softwareși scrieți o aplicație pentru a schimba cheia de securitate. Sau copia dvs. de „1C:Enterprise” nu are niciuna cheia dată. La urma urmei, cheia este furnizată numai cu software-ul licențiat.

Articolul a folosit materiale de pe site-urile http://help1c.com, http://www.ititi.ru, http://it-specialist.perm.ru.