Eroare la deschiderea fișierului index al tabelului 1c 7.7. Conversia unui singur fișier index într-o etichetă

Introducere

Era o zi însorită de vară și nu a existat niciun semn de probleme când a sunat telefonul și angajatul de la celălalt capăt a spus: „Se pare că am ucis baza de clienți”. După interogatoriu cu parțialitate, a rezultat următoarele: pe un desktop obișnuit la distanță (RDP), a fost efectuată o actualizare a configurației 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 relansare programul a dat un mesaj

și după aceea a căzut în Windows. A avea o copie de rezervă ar fi făcut posibilă restabilirea bazei de date în cel mai scurt timp, dar neatenția umană a angajatului, care nu a petrecut câteva minute în plus pentru a o crea, a dus la faptul că a fost nevoie de aproximativ patru zile pentru a remedia. problema, au fost întreprinși mai mulți pași incorecți care nu au condus la un rezultat semnificativ. Mai jos descriu modul corect.

Refacerea bazei

O căutare pe Internet a dus 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 o recuperare corectă:

Pasul 1.Noi facem backup baza stricata

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

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

Deci, după cum știți, un fișier CD este în esență o stocare a fișierelor de tabel. Deschideți editorul Hex (de exemplu, open source http://en.wikipedia.org/wiki/HxD), urmați linkul 0x4000. Există un tabel de decalaje 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, dacă o masă este deteriorată, nu primul din listă. Pe de altă parte, simplifică munca programatorilor 1C și accelerează procesul de încărcare a tabelelor necesare în memorie.

Deci, să aruncăm o privire la tabelul din editorul HEX:

Această imagine din partea stângă arată editorul HEX din partea dreaptă a listei de tabele din utilitarul Tool_1CD. Sunt în aceeași ordine în care apar în fișierul CD. Aici vedem că tabelul CONFIG începe la 0x5000 și se termină la 0x31F0FFF, unde tabelul începe următorul CONFIGSAVE la 0x31F1000 (pentru cei care nu au programat niciodată în asamblare, voi spune că numerele din codurile mașinilor sunt scrise de la dreapta la stânga - o relicvă a regimului țarist). Strict vorbind, 0x5000 este antetul tabelului 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 înjură configurația, prin urmare, trebuie să reparăm acest tabel special, pentru aceasta trebuie să scoatem tabelul CONFIG din configurația salvată (sau dacă nu este salvată, luăm configurația la fel de aproape pe cat posibil celui deteriorat) si inlocuieste-l la adresa 0x5000, dar tabelul nu ar trebui să depășească 0x31F0FFF.

Actualizat 10.10.2012

Notă importantă :

1C se referă la tabele după nume și nu contează care tabel este primul în listă, care este al doilea etc.Doar că atunci când creează o nouă bază de date, 1C creează tabelele necesare unul după altul în ordinea în care această creație a fost scrisă de programatorii 1C. Prin urmare, se dovedește întotdeauna că CONFIG vine pe primul loc, CONFIGSAVE vine pe al doilea etc. Dar dacă primul tabel ar fi _REFERENCE152, iar CONFIG ar fi al șaptesprezecelea din listă, 1C ar funcționa liniștit cu o astfel de bază.

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

Încărcat. L-au notat. Ne uităm în editorul HEX

Deci, ceva nu este în regulă, a fost adăugat un tabel nou. De aici concluzia: Recuperarea ar trebui să se facă pe aceeași versiune de platformă ca baza de date deteriorată.

Pasul 5b. Încărcăm 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 0x10FFF și nu pare să fie restructurat. Bine, să încercăm să copiem foaia de lucru Tool_1CD într-o bază de date care nu funcționează. Selectați blocul din baza de lucru și copiați-l cu înlocuire la 0x5000 pe baza deteriorată:

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

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

Să vedem cum arată acum offset-urile:

Mai bine acum. CONFIGSAVE este acum localizat la 0x31FC000, care este mai mare decât 0x31F1000. Cum copiați un bloc de tabel CONFIG mai mare dintr-o bază de date de producție într-unul mai mic dintr-o bază de date coruptă? Răspunsul este simplu: trebuie să eliminați metadatele din configurația de lucru care nu îi afectează structura: module comune, poze, rapoarte, prelucrare etc. Este important pentru noi să pornim 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 lucru și în adresa 0x5000 în baza deteriorată, copiați-o cu înlocuire

O notăm. Deschidem 1C. Ok, totul a funcționat.

Actualizat 10.10.2012

Notă importantă

De regulă, la offset 0x4000, sunt conținute link-uri către fișierele de descriere a tabelului. Și deja în fișierele descriere a tabelelor, există referințe la tabelele de înregistrări, indici și BLOB. În general, dacă tabelul CONFIG „începe” la 0x5000 și tabelul CONFIGSAVE la 0x31f1000, nu există nicio garanție că nu există niciun bloc între 0x5000 și 0x31f1000 care să aparțină oricărui tabel altul decât CONFIG. În cele mai multe cazuri, tabelul CONFIG nu este fragmentat, acest lucru se explică, cred, prin faptul că o astfel de aranjare a fișierelor unui tabel unul după altul, astfel încât întregul tabel să fie, parcă, într-un fișier 1CD în o singură bucată continuă, se formează ca urmare a aplicării compresiei bazei de date în timpul testării și reparării sau utilizării utilitarului chdbfl.exe.

Rămâne doar să încărcați configurația de lucru în baza de date pentru a restabili baza de date de lucru. Gata, baza a fost restaurată.

P.S. Desigur, acest caz descrie corectarea defecțiunilor simple, cu toate acestea, 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ă momente când un tabel sau un index poate fi corupt. Acest lucru s-ar putea datora modificărilor în mysql sau în setul de date procesat. De exemplu, există o eroare în colaţionare, trebuie să reparaţi tabelul pentru a actualiza indecşii coloanelor de caractere care utilizează colaţionare. De asemenea, poate fi necesară restaurarea tabelelor după verificarea integrității tabelelor folosind comenzile CHECK TABLE, mysqlcheck sau mysql_upgrade.

Pentru a restaura, a re-crea tabele î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 din acesta). Prin urmare, înainte de a actualiza baza de date mysql sau de a downgrade baza de date, trebuie să creați un dump al bazei de date, de exemplu folosind mysqldump. După upgrade sau downgrade, restaurați baza de date din fișierul dump. Dacă utilizați această metodă numai pentru reconstruirea indexurilor, atunci descărcarea și restaurarea se pot face atât înainte, cât și după actualizarea sau derularea versiunii.

Pentru a recrea tabelul utilizând dump și restaurare, urmați acești pași:

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 tabelul folosind comanda ALTER TABLE nu schimba motorul de stocare, folosește-l pe cel care este deja acolo, de exemplu l pentru MyIsam:

ALTER TABLE table1 ENGINE = MyISAM

Dacă nu sunteți sigur ce motor de stocare este folosit pentru 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 dat un mesaj că tabelul a fost corupt, utilizați comanda: MASA DE REPARATIE, doar daca tipul dat masa de depozitare suportă această operație. De exemplu, MyISAM 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 recrea ș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 — reparație- oferă posibilitatea de a restaura tabele în același mod ca REPAIR TABLE, doar că această expresie este mai convenabilă, deoarece puteți utiliza opțiunile —Baze de date sau —toate bazele de date 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 — reparare — toate bazele de date

MySQL 5.1.24 are bug-ul # 27877 utf8_general_ci și ucs2_general_ci (codificări), a fost remediat în MySQL 5.1.62, 5.5.21 și 5.6.5. Instalați oricare dintre versiunile corectate, apoi convertiți tabelele utilizând una dintre următoarele metode:

Schimbați codarea (colationare) în utf8_general_mysql500_ci și ucs2_general_mysql500_ci, care corespunde cu utf8_general_ci și ucs2_general_ci în MySQL 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 o procedură de dump și restaurare. Creați un fișier dump, modificați codificarea expresiilor din acesta CREAȚI TABEL, se poate face prin înlocuire automată, apoi restaurare din fișierul dump.

După corecturile făcute VERIFICAȚI TABELUL nu ar trebui să dea 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.

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

SET INDEX TO [lista de fișiere index]

[OP< CDx-file>]]

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

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

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

Înlocuirea indexului curent

Mai multe fișiere index pot fi deschise pentru fiecare tabel în același timp, dar un singur index va fi curent (activ). În mod implicit, se presupune că indexul curent va fi primul în ordinea fișierului index, al cărui nume este indicat primul în lista de nume de fișiere index ale comenzii sau comenzii USE SETARE INDEX LA.

Orice index din fișierul index curent poate fi actualizat folosind comanda

SETĂ COMANDA PENTRU

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

[ ASCENDENT | DESCENDENTĂ]

Atribuire opțiuni:

<выр.Nl> - setează indexul curent după numărul său ordinal î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 zonei de lucru în care se află fișierul index. Opțiunea este utilizată dacă fișierul tabel este deschis într-o zonă de lucru, iar fișierul index este într-o altă zonă de lucru.

De asemenea, puteți face indexul curent utilizând caseta de dialog Table Designer mutând șirul de descriere a indexului dorit pe primul loc.

Reconstruirea fișierelor index

Modificările aduse tabelelor mari necesită timp deoarece fiecare modificare reconstruiește toate fișierele index deschise. Pentru a economisi timp, fișierele index sunt închise și tabelul modificat. Cu toate acestea, în acest scenariu, 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 celei modificate fișier tabelar, trebuie să dai o comandă REINDEX. Comanda afectează toate fișierele index deschise în zona de lucru curentă. Reindexarea poate fi efectuată și prin lansarea comenzii din meniul principal Tabel -> Reconstruiți indecși.

Conversia unui singur fișier 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ă doriți să copiați toate fișierele cu un singur index. În acest caz, 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, 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 deschis în prealabil. Puteți copia etichete individuale specificând<список имен тегов>, sau toate etichetele folosind opțiunea ALL.

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 dând mesaje adesea neinteligibile pentru o persoană. 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 sistem!”

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

3. „Eroare de blocare a datelor”

Baza de date este folosită în modul exclusiv (poate că ești tu însuți). Pentru a elimina această problemă, trebuie să închideți sesiunea 1C: Enterprise cu acces exclusiv la baza de date și să intrați în modul split. Dacă 1C: Enterprise în modul exclusiv nu rulează 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 programul de pe fiecare computer, veți vedea în rând Ore de lucru... Dacă „Exclusiv” este scris î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ă porniți monitorul folosind comanda Start -> Programs-> 1C: Enterprise-> User Monitor. După pornirea monitorului, trebuie să selectați elementul de meniu Monitor -> Utilizatori activi. Veți vedea o listă de computere de la care să acest moment se utilizează baza (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ă 1C: Enterprise rulează pe unul dintre computere în modul exclusiv (acesta este afișat cu roșu Semnul exclamarii 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 fi oprit incorect (sau pur și simplu „înghețat”), atunci trebuie să îl opriți și să îl porniți din nou. Dacă este imposibil să determinați ce computer a ocupat baza și monitorul nu indică un computer care utilizează modul exclusiv, atunci va trebui să găsiți și să încheiați procesul 1cv7.exe în Manager Sarcini Windows sau opriți toate computerele (puteți face pe rând, î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 directoare (dosare) în timpuri recente... Dacă știți exact unde a fost mutată baza, atunci când porniți 1C în caseta de dialog, selectați butonul „Schimbare” (în dreapta sunt butoanele OK, Anulare și următoarele - „Schimbare”). Specificați o nouă cale către baza de date și, făcând clic pe butonul OK, porniți din nou 1C: Enterprise.

Dacă baza nu este pe computerul dvs., ci este pornită server la distanta, este mai bine să solicitați ajutor de la persoana care este responsabilă de performanța computerelor din compania dumneavoastră. Dacă totuși ați decis să rezolvați singur problema, atunci, în primul rând, trebuie să verificați prezența unei rețele între cele două computere (puteți verifica pur și simplu prezența computerului server în lista de computere disponibile clientului prin făcând clic pe pictograma „Locațiile mele din rețea”). În al doilea rând, trebuie să aflați locația directorului cu baza de pe server. După aceea, făcând clic pe butonul „Schimbare” din caseta de dialog de lansare 1C: Enterprise, selectați „Locațiile mele de rețea” -> Server unde 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ă iasă din 1C: Enterprise. Ar trebui să răspundeți afirmativ la oferta de restaurare a fișierelor index. Acest proces poate dura o perioadă semnificativă de timp, de la 1-2 minute pentru baze de 5-10 megaocteți până la aproximativ o oră pentru baze 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, poate că există o copie care rulează a programului. Dacă acest lucru nu ajută, atunci încercați să opriți mașinile client (puteți face unul câte unul, cu o verificare după fiecare). Este posibil ca unul dintre programe să fi fost terminat incorect și să nu fi eliberat baza.

7. „Fișierul jurnal este deteriorat”

În directorul bazei tale (calea către bază este scrisă în partea de jos în fereastra de lansare) există un subdirector Syslog. Acest director conține fișierul 1cv 7.mlg, acesta este fișierul jurnal. Mutați-l într-un 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 atunci când platforma detectează fișiere de rulat, dar contul curent (contul de sistem de operare, a nu fi confundat cu cont„1C: Enterprise”) nu există drepturi de acces la directorul în care se află baza de informații. Pentru a porni 1C: Enterprise, trebuie să scrieți în acest director. Pentru a remedia situația de pe serverul pe care se află baza, selectați resursă comună(disc sau director cu baza), faceți clic dreapta, selectați meniul Proprietăți, fila Acces, setați valoarea Complet (sau rearanjați indicatorul în „Deschidere acces generalîn folderul „pentru Windows 2000). Salvați modificările, încercați să porniți din nou 1C: Enterprise.

9. Eroare de rulare! Programul c: \ Program Files \ 1Cv77 \ Bin \ 1Cv77.exe. Terminare anormala"

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 și în cel mai rău caz (luminile au fost stinse în timpul procesului de reparație), să puteți reveni la situația dinaintea începerii reparației. O poți face singur pasii urmatori remediază 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 dumneavoastră, în directorul cu baza. De exemplu, dacă baza dvs. se află în directorul de bază c: \ 1C \, atunci trebuie să copiați fișierul 1Cv 7.md din c: \ 1C \ base \ NEW _STRU în c: \ 1C \ bază. La întrebarea: „Doriți să înlocuiți fișierul curent?” răspunsul ar trebui să fie „Da”.

d) Lansați Configuratorul, selectați Administrare -> Testare și corecție IB. Faceți clic pe butonul Run.

10. „Eroare fatală la baza de date. 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 dvs., în directorul bazei dvs. De exemplu, dacă baza dvs. se află în directorul de bază c: \ 1C \, atunci trebuie să copiați fișierul 1Cv7.dd din c: \ 1C \ base \ NEW_STRU în c: \ 1C \ bază. La întrebarea: „Doriți să înlocuiți fișierul curent?” răspunsul ar trebui să fie „Da”. Dacă un astfel de fișier nu există în directorul NEW_STRU, dar cunoașteți parola de configurare, puteți rezolva problemele prin redenumirea oricărui obiect de metadate în sine (de exemplu, ștergeți ultima literă „l” din identificatorul Constantului „MainFile”. " și pune-l înapoi). Salvați configurația.

11. Eroare de acces la tabelul DT *

A depășit suma maximă permisă în același timp deschide fișiere pe Windows 9x.

Faptul este că Windows 95/98 nu poate deschide mai mult de 1024 de fișiere simultan. Această limitare are efect dacă în modul de funcționare în rețea, baza de date este localizată pe un disc partajat al unui computer care rulează Control Windows 95/98. La pornirea 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 WinNT / 2000/2003 ca ​​server de fișiere (adică un computer pe care este stocat directorul bazei de informații). Trebuie doar să rețineți că WinNT Workstation (2000 Professional) nu are o limită a numărului 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 în același timp. Dacă vrei să lucrezi Mai mult utilizatorii în același timp, adică are sens să luați în considerare opțiunea cu un server dedicat și sisteme de operare Windows 2000/2003 Server.

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

12. „Cheia de protecție 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 o versiune locală. Sa incepem cu local ca dintr-un caz mai simplu.

Vă sugerăm să urmați acești pași. După fiecare încercare, încercați să lansați 1C: Enterprise. Este posibil ca problema să fie rezolvată chiar de la primul pas, iar apoi să nu fie necesare toate cele ulterioare.

a) Reporniți computerul făcând clic pe Start-> Shutdown -> Restart Computer -> OK. Așteptați ca computerul să repornească, apoi încercați să porniți din nou 1C.

b) Este posibil să fi uitat să instalați driverul de protecție la instalarea programului. Apoi trebuie să-l lansați făcând clic pe Start -> Programe-> 1C: Enterprise 7.7-> Instalarea driverului de protecție. Reporniți computerul și încercați să porniți din nou 1C: Enterprise. Dacă, dintr-un motiv oarecare, driverul nu a fost instalat, atunci instalați-l de pe discul furnizat 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 în partea din spate a 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ă aplicați o forță mare, efortul ar trebui să fie comparabil cu efortul de la ridicarea unui pahar de ceai. Dacă cheia nu se potrivește în port, nu încercați să o introduceți forțat, 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 dumneavoastră. 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 determinarea acesteia de către serverul de securitate. După ce ați oprit anterior computerul și imprimanta, încercați să deconectați perifericele (cel mai adesea 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 deconectat.

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 funcționarea computerelor din compania dvs. Dacă sunteți această persoană, atunci vă putem sfătui să urmați acești pași:

a) Verificați dacă computerul cu probleme „vede” serverul pe care se află cheia. Puteți fie să faceți ping la server din linia de comandă, 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 computerului server în lista de computere disponibile clientului făcând clic pe pictograma Locațiile mele de rețea. Dacă se dovedește că computerul cu probleme nu „vede” serverul, atunci va trebui să conduceți verificare standard la probleme de rețea... Vă recomandăm să începeți cu verificarea integrității cablurilor (fără întreruperi), a operabilității hub-ului, a operabilității plăcii de rețea, în plus, trebuie să vă asigurați că aveți protocoalele necesare și că acestea sunt configurate corect.

b) Asigurați-vă că aplicația „Server de protecție” rulează pe computerul cu cheia. Acest program este necesar pentru ca clienții 1C: Enterprise să funcționeze într-o versiune de rețea. Îl puteți porni făcând clic pe Start -> Programs-> 1C: Enterprise 7.7-> Protection Server.

c) Fiecare computer cu 1C: Enterprise are 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 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.), timpului de așteptare pentru căutarea cheii (cu o rețea slabă, programul poate pur și simplu să nu aibă timp să-l găsească) și legături către computerul server (este posibil ca un astfel de computer să nu mai existe, să fi fost mutat sau redenumit).

Poate că dongle-ul hardware este „pe viață”. În această situație, trebuie să vă contactați furnizorul. softwareși scrieți o cerere pentru schimbul cheii de protecție. Sau copia dvs. de „1C: Enterprise” nu are 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.

Cele mai frecvente erori 1C 7.7

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

De obicei, asta se întâmplă când instalare inițială bazele. Soluție solicitată)) Rulați 1C în modul exclusiv. 1C va indexa baza de date și va putea fi descărcată.

2. ordinea de sortare este diferită 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] sau conectat în 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 astfel:
- Începem 1C în modul Configurator Enterprise 7.7;
- Selectați articolul " Administrare" -> "Tabelul de coduri al paginilor IB";
- În listă, selectați cel mai mic element - " Actual instalarea 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 arunca acest fișier în programul în sine, adică în \\ 1Cv77 \ Bin \ Aceasta dezactivează verificarea ordinii de sortare în programul 1C. Dar oricum va viza toate bazele.
- 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ă, unde se află acest fișier marcator (sau semnal). Să presupunem că aveți trei baze. Funcționează cu două baze în Windows XP, iar cu a treia - cu sisteme diferite... Apoi, dacă trimitem fișierul de marcare numai către a treia bază, atunci ei vor putea lucra cu a treia bază din sisteme diferite.

De ce să nu arunci dosarul OrdNoChk.prm v COSși nu dezactivați verificarea ordinii de sortare pentru toate bazele de date simultan?
Pentru că:
- Pe aici 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ă reconcilierea ordinii de sortare a sistemului cu ordinea de sortare setată pentru baza de informații. Dacă verificarea ordinii de sortare este dezactivată în condițiile utilizării componentei de gestionare a bazei de informații distribuite, NU TREBUIE să utilizați simboluri ale niciunui alfabet, cu excepția latinei, într-un identificator de trei litere. baze de informare incluse în distribuit. Trebuie avut în vedere faptul că 1C: Enterprise folosește capacitatea de a sorta ambele mecanisme în timpul lucrului său, iar dezactivarea verificării identității comenzii în acestea poate duce la o ordine neașteptată a liniilor pentru utilizator, de exemplu, atunci când generarea de rapoarte".

Prin urmare, dacă funcționează cu o bază în același sistem, este mai bine să utilizați capabilitățile standard. - De exemplu, schimbați tabelul de coduri de pagină în baza propriu-zisă și funcționați normal.
- Sau folosiț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 a fi mai flexibilă și mai corectă.

În plus, trebuie reținute următoarele!

Este recomandabil să localizați bazele de date pe o mașină cu Windows XP și OrdNoChk.prm pus in folder COS pe o mașină Windows 7 (Vista). Acest lucru va evita potențialele probleme cu funcționarea componentelor precum URIB... Trebuie amintit că o mașină cu Windows 7 (Vista) poate fi folosită doar pentru a funcționa în modul 1C Enterprise.
Orice modificare în modul Configurator trebuie făcută numai pe o mașină cu Windows XP.
Când bazele de date sunt localizate pe o mașină cu Windows 7 (Vista), asigurați-vă că aduceți pagina de cod IB pe cea de sistem (conform primei metode) și utilizați OrdNoChk.prm deja pe mașini cu Windows XP, altfel lucrați cu URIB sau pur și simplu încărcarea datelor încărcate anterior în IB nu va fi posibilă.

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

Această eroare apare din cauza faptului că bibliotecile nu sunt înregistrate în sistemul de operare. În acest caz - V7Plus.dll.
1C înregistrează biblioteci în mod dinamic, adică la primul apel către biblioteca dorită.
Dar nu se poate.
Acest lucru se întâmplă de obicei din cauza lipsei de drepturi sau când UAC(în Windows Vista / 7). Când este activat 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 se lega de o anumită bază de date) și odată confundați 1C î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, alergați Linie de comanda 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 „Este necesar un driver ODBC pentru MS SQL pentru a accesa baza de date Versiuni de server 3.50.0303 sau mai vechi.

Eroarea apare atunci când încercați să rulați versiunea SQL 1C Enterprise 7.7 pe Windows 7 (Vista) și constă în lipsa suportului pentru aceste versiuni OS ale serverului SQL de mai jos SQL Server 2005 SP2.

Extras din comunicatul oficial de presă Microsoft:
Pentru a asigura mai mult nivel inalt securitate, sisteme de operare Microsoft Windows Server 2008 și Microsoft Windows Vista va suporta SQL Server 2005 SP1 Express Edition și toate celelalte ediții 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, operațional sisteme Windows Server 2008 și Windows Vista nu vor fi acceptate.

Momentan nu există o soluție (și este puțin probabil să apară).

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