Încercarea de a introduce o valoare unică într-un indice unic. O încercare de a introduce o valoare unică într-un indice unic pentru a elimina indexurile de nevoiți în fișierul 1C 8

Ați întâlnit un mesaj care conține linii:
Furnizor Microsoft Ole DB pentru SQL Server: Creați un indice unic terminat deoarece a fost găsită o tastă duplicată pentru ID-ul indexului
sau
Nu pot i_sert duplicat rândul cheie în obiect
sau
Încercarea de a introduce o valoare unică într-un indice unic.

Opțiuni de soluție:

1. În SQL Server Management Studio, distrugeți fizic indicele eșuat (în cazul meu a fost un index privind tabelul rezultatului registrului contabil). În 1c, vom scula documentele de eșec. În modul de testare și corecție, punem reintroducerea dungă a tabelelor + recalcularea rezultatelor. 1c recreează indicele fără eroare. Am făcut anterior documente.

2. 1) Utilizarea studioului de management 2005 a generat scriptul Creare pentru a crea un indice care a fost buggy și salvat în fișier.
2) a ucis manual un indice de sacou din tabelul _ACCUMGRGTN19455
3) a lansat o solicitare de vizualizare
Cod SQL S_ELECT COUNT (*), câmp_index
De la SIMARGTN19455.
Grup de câmpuri_index.
Având numărul (*)\u003e 1
După ce indicele a fost ucis, am dispărut 15 înregistrări duplicate, deși înainte de execuția alineatului (2), nu am returnat nimic.
4) Vizualizați toate înregistrările și duplicatele curățate manual. De fapt, am folosit și prelucrarea "structurii raportului" pentru a înțelege ceea ce am de-a face cu mine. Sa dovedit că tabelul _ACCUMRGTN19455 stochează registrul de acumulare "Producție (contabilitate fiscală)". Încă am săpat cereri SQL, am dezvăluit 15 documente nedorite și după încheierea tuturor actelor pe care le-am verificat în 1c că aceste documente sunt efectuate în mod normal, fără erori. Doar curățați tabelul Namaum, desigur, nu merită: Este important să înțelegeți că este curățată și la ce se poate transforma.
5) a lansat o solicitare de creare a unui indice care a fost salvat în fișier.
6) Traducerea bazei de date în modul cu un singur utilizator și lansată DBCC CHECKDB - de data aceasta nu a fost emisă o singură eroare.
7) a transferat baza de date înapoi în modul unic utilizator.
Totul ... problema este învinsă. Ei bine, în 1c lansat "Testarea și corectarea", totul a fost bine acolo, a fost normal, a oprit să jure într-un indice ne-unic.

3. În cazul în care unelativitatea se află în datele cu valorile zeroProblema este rezolvată prin crearea unei baze de date cu un parametru de deplasare până în anul 2000.

1. Dacă problema încărcării bazei de date, atunci:
1.1. Dacă faceți descărcarea (utilizați fișierul DT) în baza de date MS SQL Server, atunci când creați o bază înainte de a descărca, specificați offsetul datelor - 2000.
Dacă baza este deja creată cu deplasarea 0, apoi creați una nouă din 2000.

1.2. Dacă aveți posibilitatea de a lucra cu baza de date în fișier, veți testa și remedia, precum și configurarea - verificarea configurației - verificarea integrității logice a configurației + Căutați legături incorecte.

1.3 Dacă nu există o versiune de fișier, încercați să descărcați de la DT la o versiune client-server cu DB2 (care este mai puțin exigentă pentru unicitate), apoi efectuați testarea și fixarea, precum și verificarea configurației - verificarea integrității logice a configurației + căutați pentru link-uri incorecte.

1.4. Pentru a localiza problema, puteți defini datele obiectului, încărcarea căreia a eșuat. Pentru a face acest lucru, trebuie să activați următorul utilitar de profile în timpul descărcării sau să activați înregistrarea în jurnalul tehnologic DBMSSQL și EXCP.

2. Dacă problema neplăcutei se manifestă în timp ce utilizatorii:

2.1. Găsiți cu metoda de la punctul 1.4 Cererea de problemă.

2.1.2. Uneori apare eroarea în timpul executării cererilor, de exemplu:

Această eroare apare datorită faptului că, în modulul Registrului de registru "orele de lucru ale angajaților organizațiilor" în procedura "Registrykers", în cerere, nu costă cuvântul oficial "diferit".
Cod 1c v 8.x adică Ar trebui să fie:
Solicitare \u003d cerere nouă (
"Alegeți diferit
| Infoizori majori,
. . . . .
În cele mai recente versiuni lansate de ZUP și UPP, eroarea nu apare deoarece Sunt diferite".

2.2. După găsirea unui indice de problemă din elementul anterior, este necesar să găsiți o intrare ne-unică.
2.2.1. Script de "pește" pentru a determina intrările non-unice utilizând SQL:
Cod SQL S_ELECT Count (*) Counter,<перечисление всех полей соответствующего индекса> din.<имя таблицы>
A se grupa cu.<перечисление всех полей соответствующего индекса>
Având contra\u003e 1

2.2.2 Exemplu. Indicele din eroare este numit "_document140_vt1385_intkeyindng".
Lista câmpurilor de tabel:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Înainte de a efectua următoarea procedură, faceți backup. Bază de date.
Rulați în analizerul de interogare MS SQL Server:
Sql s_elect numărare (*), _document140_idrref, _Keyfield
de la _document140_vt1385.
Grup de _document140_idrref, _Keyfield
Având numărul (*)\u003e 1
Cu aceasta, aflați valorile coloanei _document140_idrref, _keyfield, intrări duplicate (ID, cheie).

Folosind interogarea:
Sql s_elec * cod *
de la _document140_vt1385.
sau _document140_idrref \u003d ID2 și _Keyfield \u003d tasta2 sau ...
Uită-te la valorile altor coloane de înregistrări duplicate.
Dacă ambele înregistrări au valori semnificative și aceste valori sunt diferite, atunci corectați valoarea _Keyfield pe unul unic. Pentru a face acest lucru, determinați valoarea maximă ocupată _Keyfield (KeyMax):
SQL S_ELECT MAX (_KEYFIELD) cod
de la _document140_vt1385.
Unde _document140_idrref \u003d ID1
Înlocuiți valoarea _Keyfield într-una din înregistrările repetitive la corecte:
Cod sql update _document140_vt1385
Setați _Keyfield \u003d KeyMax + 1
Aici _lineno1386 \u003d - stare suplimentarăcare vă permite să selectați una dintre cele două intrări repetitive.

Dacă unul (sau ambele) din înregistrările repetitive este evident valoarea incorectă, atunci trebuie eliminat:
SQL Ștergeți de la codul _document140_vt1385
Unde _document140_idrref \u003d ID1 și _lineno1386 \u003d lineno1
Dacă repetarea înregistrărilor au aceleași valori în toate coloanele, atunci trebuie să lăsați unul:
Cod SQL S_Electați distinct *
În # tmp1.
de la _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

Ștergeți de la _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

I_sert în _document140_vt1385.
S_ELECT # TMP1.

D_rop tabel # tmp1

Procedura descrisă trebuie efectuată pentru fiecare pereche de înregistrări recurente.

2.2.3. Al doilea exemplu:
Cod SQL S_ELECT Count (*) ca Expr2, _IDRREF ca Expr1, _Decription
De la _reference8_
Grup de _idrref, _description
Având (număr (*)\u003e 1)

2.3.4 Un exemplu de determinare a intrărilor non-unice utilizând cererea 1C: Intreprindere:
Cod 1c v 8.x Selectați link-ul Manualului
Din Manual. Manualul ca director
Grupul pe cartea de referință
Având cantitate (*)\u003e 1

Ați întâlnit un mesaj care conține linii:
Microsoft OLE DB furnizor pentru SQL Server: Creați un indice unic terminat deoarece a fost găsită o tastă duplicată pentru ID-ul indexului
sau
Nu pot i_sert duplicat rândul cheie în obiect
sau
Încercarea de a introduce o valoare unică într-un indice unic.

Opțiuni de soluție:

1. În SQL Server Management Studio, distrugeți fizic indicele eșuat (în cazul meu a fost un index privind tabelul rezultatului registrului contabil). În 1c, vom scula documentele de eșec. În modul de testare și corecție, punem reintroducerea dungă a tabelelor + recalcularea rezultatelor. 1c recreează indicele fără eroare. Am făcut anterior documente.

2. 1) Utilizarea studioului de management 2005 a generat scriptul Creare pentru a crea un indice care a fost buggy și salvat în fișier.
2) a ucis manual un indice de sacou din tabelul _ACCUMGRGTN19455
3) a lansat o solicitare de vizualizare
Cod SQL S_ELECT COUNT (*), câmp_index
De la SIMARGTN19455.
Grup de câmpuri_index.
Având numărul (*)\u003e 1
După ce indicele a fost ucis, am dispărut 15 înregistrări duplicate, deși înainte de execuția alineatului (2), nu am returnat nimic.
4) Vizualizați toate înregistrările și duplicatele curățate manual. De fapt, am folosit și prelucrarea "structurii raportului" pentru a înțelege ceea ce am de-a face cu mine. Sa dovedit că tabelul _ACCUMRGTN19455 stochează registrul de acumulare "Producție (contabilitate fiscală)". Încă am săpat cereri SQL, am dezvăluit 15 documente nedorite și după încheierea tuturor actelor pe care le-am verificat în 1c că aceste documente sunt efectuate în mod normal, fără erori. Doar curățați tabelul Namaum, desigur, nu merită: Este important să înțelegeți că este curățată și la ce se poate transforma.
5) a lansat o solicitare de creare a unui indice care a fost salvat în fișier.
6) Traducerea bazei de date în modul cu un singur utilizator și lansată DBCC CHECKDB - de data aceasta nu a fost emisă o singură eroare.
7) a transferat baza de date înapoi în modul unic utilizator.
Totul ... problema este învinsă. Ei bine, în 1c lansat "Testarea și corectarea", totul a fost bine acolo, a fost normal, a oprit să jure într-un indice ne-unic.

3. În cazul în care unelativitatea se află în datele cu valorile zeroProblema este rezolvată prin crearea unei baze de date cu un parametru de deplasare până în anul 2000.

1. Dacă problema încărcării bazei de date, atunci:
1.1. Dacă faceți descărcarea (utilizați fișierul DT) în baza de date MS SQL Server, atunci când creați o bază înainte de a descărca, specificați offsetul datelor - 2000.
Dacă baza este deja creată cu deplasarea 0, apoi creați una nouă din 2000.

1.2. Dacă aveți posibilitatea de a lucra cu baza de date în fișier, veți testa și remedia, precum și configurarea - verificarea configurației - verificarea integrității logice a configurației + Căutați legături incorecte.

1.3 Dacă nu există o versiune de fișier, încercați să descărcați de la DT la o versiune client-server cu DB2 (care este mai puțin exigentă pentru unicitate), apoi efectuați testarea și fixarea, precum și verificarea configurației - verificarea integrității logice a configurației + căutați pentru link-uri incorecte.

1.4. Pentru a localiza problema, puteți defini datele obiectului, încărcarea căreia a eșuat. Pentru a face acest lucru, trebuie să activați următorul utilitar de profile în timpul descărcării sau să activați înregistrarea în jurnalul tehnologic DBMSSQL și EXCP.

2. Dacă problema neplăcutei se manifestă în timp ce utilizatorii:

2.1. Găsiți cu metoda de la punctul 1.4 Cererea de problemă.

2.1.2. Uneori apare eroarea în timpul executării cererilor, de exemplu:

Această eroare apare datorită faptului că, în modulul Registrului de registru "orele de lucru ale angajaților organizațiilor" în procedura "Registrykers", în cerere, nu costă cuvântul oficial "diferit".
Cod 1c v 8.x adică Ar trebui să fie:
Solicitare \u003d cerere nouă (
"Alegeți diferit
| Infoizori majori,
. . . . .
În cele mai recente versiuni lansate de ZUP și UPP, eroarea nu apare deoarece Sunt diferite".

2.2. După găsirea unui indice de problemă din elementul anterior, este necesar să găsiți o intrare ne-unică.
2.2.1. Script de "pește" pentru a determina intrările non-unice utilizând SQL:
Cod SQL S_ELECT Count (*) Counter,<перечисление всех полей соответствующего индекса> din.<имя таблицы>
A se grupa cu.<перечисление всех полей соответствующего индекса>
Având contra\u003e 1

2.2.2 Exemplu. Indicele din eroare este numit "_document140_vt1385_intkeyindng".
Lista câmpurilor de tabel:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Înainte de a efectua următoarea procedură, efectuați o copie de rezervă a bazei de date.
Rulați în analizerul de interogare MS SQL Server:
Sql s_elect numărare (*), _document140_idrref, _Keyfield
de la _document140_vt1385.
Grup de _document140_idrref, _Keyfield
Având numărul (*)\u003e 1
Cu aceasta, aflați valorile coloanei _document140_idrref, _keyfield, intrări duplicate (ID, cheie).

Folosind interogarea:
Sql s_elec * cod *
de la _document140_vt1385.
sau _document140_idrref \u003d ID2 și _Keyfield \u003d tasta2 sau ...
Uită-te la valorile altor coloane de înregistrări duplicate.
Dacă ambele înregistrări au valori semnificative și aceste valori sunt diferite, atunci corectați valoarea _Keyfield pe unul unic. Pentru a face acest lucru, determinați valoarea maximă ocupată _Keyfield (KeyMax):
SQL S_ELECT MAX (_KEYFIELD) cod
de la _document140_vt1385.
Unde _document140_idrref \u003d ID1
Înlocuiți valoarea _Keyfield într-una din înregistrările repetitive la corecte:
Cod sql update _document140_vt1385
Setați _Keyfield \u003d KeyMax + 1
Aici _lineno1386 \u003d - o condiție suplimentară care vă permite să selectați una din cele două înregistrări repetitive.

Dacă unul (sau ambele) din înregistrările repetitive are o valoare incorectă evidentă, atunci trebuie să fie eliminată:
SQL Ștergeți de la codul _document140_vt1385
Unde _document140_idrref \u003d ID1 și _lineno1386 \u003d lineno1
Dacă repetarea înregistrărilor au aceleași valori în toate coloanele, atunci trebuie să lăsați unul:
Cod SQL S_Electați distinct *
În # tmp1.
de la _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

Ștergeți de la _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

I_sert în _document140_vt1385.
S_ELECT # TMP1.

D_rop tabel # tmp1

Procedura descrisă trebuie efectuată pentru fiecare pereche de înregistrări recurente.

2.2.3. Al doilea exemplu:
Cod SQL S_ELECT Count (*) ca Expr2, _IDRREF ca Expr1, _Decription
De la _reference8_
Grup de _idrref, _description
Având (număr (*)\u003e 1)

2.3.4 Un exemplu de determinare a intrărilor non-unice utilizând cererea 1C: Intreprindere:
Cod 1c v 8.x Selectați link-ul Manualului
Din Manual. Manualul ca director
Grupul pe cartea de referință
Având cantitate (*)\u003e 1

Acest articol va descrie ce să facă dacă, atunci când lucrați cu 1C: întreprindere 8.1, ați întâlnit un mesaj care conține linii:

Nu se poate introduce rândul cheie duplicat în obiect

Încercarea de a introduce o valoare unică într-un indice unic.

Care este indicele?

Indicii sunt o structură care vă permite să efectuați acces accelerat la rândurile de masă pe baza valorilor uneia sau mai multor coloane.
Indicele conține tastele construite din una sau mai multe coloane de masă sau vizualizări și pointeri care sunt cartografiate la locația de stocare a datelor date.
Indicii reduc cantitatea de date care trebuie luate în considerare pentru a returna setul rezultat.

Deși indexul este asociat cu o anumită coloană (sau coloane) a tabelului, este încă un obiect de bază de date independent.

Indicii de masă în baza de date 1c: Compania este creată implicit atunci când creează obiecte de configurare, precum și aceste sau alte obiecte de configurare.

Esența fizică a indexurilor din dna SQL Server 2005.

Date stocate fizic. pe paginile cu 8 kB. Imediat după creație, până când tabelul are indici, tabelul arată ca un heap (heap) de date. Înregistrările nu au o anumită comandă de stocare.
Când doriți să accesați date, SQL Server va produce tabelul de scanare (Scanarea tabelului). SQL Server scanează întreaga masă pentru a găsi înregistrările dorite.
De aici, funcțiile de bază ale indexurilor devin înțelese:
- Creșterea vitezelor de acces la date
- Sprijin pentru unicitatea datelor.

În ciuda avantajelor, indicii au, de asemenea, o serie de deficiențe. Primul este indicii ocupa locul suplimentar Pe disc. și B. memorie cu acces aleator. De fiecare dată când creați un index, păstrați cheile în ordine descrescătoare sau ascendentă, care poate avea o structură pe mai multe niveluri. Și mai mult / mai mult cheia mai mult dimensiune index. Al doilea dezavantaj - operațiuni lente Introduceți, actualizări și ștergeți înregistrările.
În dna SQL Server 2005, sunt implementate mai multe tipuri de indice:

  • indexuri noncluster;
  • indicii cluster (sau clusterizat);
  • indicii unici;
  • indicii cu coloane incluse
  • vizualizări indexate
  • text complet

Index unic

Unicitatea valorilor din coloana indexată garantează indicii unici. Dacă este disponibil, serverul nu vă va permite să introduceți un nou sau să modificați valoarea existentă, astfel încât în \u200b\u200bcoloană să apară două valori identice ca urmare a acestei operații.
Indicele unic este un fel de suprastructură și poate fi implementat atât pentru cluster, cât și pentru un indice noncluster. O masă poate exista un cluster unic și multe indici unice noncus.
Indicii unici ar trebui să fie definiți numai atunci când este cu adevărat necesar. Pentru a asigura integritatea datelor într-o coloană, puteți defini integritatea cheii unice sau primare și nu puteți recurge la indici unici. Utilizarea lor numai pentru a asigura integritatea datelor este un spațiu de cheltuieli nejustificat în baza de date. În plus, timpul procesorului este cheltuit pe întreținerea lor.

1C: Întreprinderea 8.1 Începând cu versiunea 8.1 utilizează în mod activ indicii unici cluster. Aceasta înseamnă că, atunci când convertirea de la 8,0 sau trecerea de la 8.1.7, puteți obține o eroare a indicelui nedelărit.

Dacă subdepliniditatea se află în datele cu valorile zero, atunci problema este rezolvată prin crearea unei baze cu un parametru de deplasare până în 2000.

Ce să fac?

1. Dacă problema încărcării bazei de date, atunci:

1.1. Dacă faceți descărcarea (utilizați fișierul DT) în baza de date MS SQL Server, atunci când creați o bază înainte de a descărca, specificați offsetul datelor - 2000.

Dacă baza este deja creată cu deplasarea 0, apoi creați una nouă din 2000.

1.2. Dacă aveți posibilitatea de a lucra cu baza de date în fișier, veți testa și remedia, precum și configurarea - verificarea configurației - verificarea integrității logice a configurației + Căutați legături incorecte.

1.3 Dacă nu există o versiune de fișier, încercați să descărcați de la DT la o versiune client-server cu DB2 (care este mai puțin exigentă pentru unicitate), apoi efectuați testarea și fixarea, precum și verificarea configurației - verificarea integrității logice a configurației + căutați pentru link-uri incorecte.

1.4. Pentru a localiza problema, puteți defini datele obiectului, încărcarea căreia a eșuat. Pentru a face acest lucru, trebuie să activați urmărirea în utilitatea de profile în timpul descărcării sau activați înregistrarea jurnalului evenimentului DBMSSQL și EXCP.

1.5. Dacă nodul este disponibil (planuri de schimb), atunci efectuați schimbul. De asemenea, puteți completa schimbul pentru a executa clauza 2.3.5.

2. Dacă problema neplăcutei se manifestă în timp ce utilizatorii:

2.1. Găsiți cu metoda de la punctul 1.4 Cererea de problemă.

2.1.2. Uneori apare eroarea în timpul executării cererilor, de exemplu:

Această eroare apare din cauza faptului că, în registrul acumulării de "ore de lucru ale angajaților organizațiilor" în registrul de hârtie, cuvântul oficial "diferit" nu merită.

Acestea. Ar trebui să fie:

Solicitare \u003d cerere nouă (
"Alegeți diferit
| Infoizori majori,

În cele mai recente versiuni lansate de ZUP și UPP, eroarea nu apare deoarece Sunt diferite".

2.2. După găsirea unui indice de problemă din elementul anterior, este necesar să găsiți o intrare ne-unică.

2.2.1. Script de "pește" pentru a determina intrările non-unice utilizând SQL:
Selectați Counter Count (*),<перечисление всех полей соответствующего индекса> din.<имя таблицы>
A se grupa cu.<перечисление всех полей соответствующего индекса>
Având contra\u003e 1

2.2.2 Exemplu. Indicele din eroare este numit "_document140_vt1385_intkeyindng".

Lista câmpurilor de tabel:

Document140_idrref, _keyfield, _lineno1386, _FLD1387, _FLD1388, _FLD1389, _FLD1390, _FLD1391RREF, _FLD1393_TYPE, _FLD1393_RTREF, _FLD1393_RRRREF, _FLD1394,

Fld1395, _FLD1396, _FLD1398, _FLD1399Rref, _FLD22260_TYPE, _FLD22260_RTREF, _FLD22261_TYPE, _FLD22261_RTREF, _FLD22261_RRRREF

Înainte de a efectua următoarea procedură, efectuați o copie de rezervă a bazei de date.
Rulați în analizerul de interogare MS SQL Server:

selectați numărul (*), _document140_idrref, _Keyfield
de la _document140_vt1385.
Grup de _document140_idrref, _Keyfield
Având numărul (*)\u003e 1

Cu aceasta, aflați valorile coloanei _document140_idrref, _keyfield, intrări duplicate (ID, cheie).

Folosind interogarea:

sELECTAȚI *
de la _document140_vt1385.
sau _document140_idrref \u003d ID2 și _Keyfield \u003d tasta2 sau ...

uită-te la valorile altor coloane de înregistrări duplicate.

Dacă ambele înregistrări au valori semnificative și aceste valori sunt diferite, atunci corectați valoarea _Keyfield pe unul unic. Pentru a face acest lucru, determinați valoarea maximă ocupată _Keyfield (KeyMax):

selectați max (_keyfield)
de la _document140_vt1385.
Unde _document140_idrref \u003d ID1

Înlocuiți valoarea _Keyfield într-una din înregistrările repetitive la corecte:

actualizați _document140_vt1385.
Setați _Keyfield \u003d KeyMax + 1

Aici _lineno1386 \u003d - o condiție suplimentară care vă permite să selectați una din cele două înregistrări repetitive.

Dacă unul (sau ambele) din înregistrările repetitive are o valoare incorectă evidentă, atunci trebuie să fie eliminată:


Unde _document140_idrref \u003d ID1 și _lineno1386 \u003d lineno1

Dacă repetarea înregistrărilor au aceleași valori în toate coloanele, atunci trebuie să lăsați unul:

selectați distinct *
În # tmp1.
de la _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

Ștergeți de la _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

introduceți în _document140_vt1385.
Selectați # TMP1.

drop tabelul # tmp1

Procedura descrisă trebuie efectuată pentru fiecare pereche de înregistrări recurente.

2.2.3. Al doilea exemplu:

Selectați numărul (*) ca Expr2, _IDRREF ca Expr1, _Decripția
De la _reference8_
Grup de _idrref, _description
Având (număr (*)\u003e 1)

2.3.4 Un exemplu de determinare a intrărilor non-unice utilizând cererea 1C: Intreprindere:

sau pentru contabilitate

ALEGE
Subquery.Period,
SUBQUIRY
<измерения>,
Suma (subquery. Naționalitatea înregistrării) ca cantitate
DE
(ALEGE
Hosier.teriod ca o perioadă,
Hosier.Restistry ca registrator,
<измерения>,
1 ca o cantitate
DE
RegisterBuchelling. Sursa ca comerț) ca o subquery

Grupate de către
Subquery.Period,
SUBQUIRY
<измерения>

Având
Suma (subqueros.

2.3.5 Efectuarea indicelui DBMS nu este unic. SCISP indicele folosind studioul de management.

2.3.6 Cazul privat Când faceți schimb de RBD. O eroare cade pe tabelele "auxiliare" asociate cu calcularea rezultatelor sau analiticii. De exemplu:

Eroare la apelarea unei metode de context (scriere): o încercare de a introduce o valoare unică într-un indice unic:
Furnizor Microsoft OLE DB pentru SQL Server: Nu se poate introduce rândul de tastă duplicat în obiect "dbo._accntreged10319" cu index unic "_ACNT10319_byperiod_trnrn".
HRESULT \u003d 80040E2F, SQLSRVR: eroare de eroare \u003d 1, severitate \u003d E, nativ \u003d 2601, linia \u003d 1

În acest caz, înainte de descărcare, opriți utilizarea rezultatelor, descărcați mesajul, activați utilizarea rezultatelor și recalculați.

Ați întâlnit un mesaj care conține linii:
Microsoft OLE DB furnizor pentru SQL Server: Creați un indice unic terminat deoarece a fost găsită o tastă duplicată pentru ID-ul indexului
sau
Nu pot i_sert duplicat rândul cheie în obiect
sau
Încercarea de a introduce o valoare unică într-un indice unic.

Opțiuni de soluție:

1. În SQL Server Management Studio, distrugeți fizic indicele eșuat (în cazul meu a fost un index privind tabelul rezultatului registrului contabil). În 1c, vom scula documentele de eșec. În modul de testare și corecție, punem reintroducerea dungă a tabelelor + recalcularea rezultatelor. 1c recreează indicele fără eroare. Am făcut anterior documente.

2. 1) Utilizarea studioului de management 2005 a generat scriptul Creare pentru a crea un indice care a fost buggy și salvat în fișier.
2) a ucis manual un indice de sacou din tabelul _ACCUMGRGTN19455
3) a lansat o solicitare de vizualizare
Cod SQL S_ELECT COUNT (*), câmp_index
Fr Og showgtn19455.
Grup de câmpuri_index.
Având numărul (*)\u003e 1
După ce indicele a fost ucis, am dispărut 15 înregistrări duplicate, deși înainte de execuția alineatului (2), nu am returnat nimic.
4) Vizualizați toate înregistrările și duplicatele curățate manual. De fapt, am folosit și prelucrarea "structurii raportului" pentru a înțelege ceea ce am de-a face cu mine. Sa dovedit că tabelul _ACCUMRGTN19455 stochează registrul de acumulare "Producție (contabilitate fiscală)". Încă am săpat cereri SQL, am dezvăluit 15 documente nedorite și după încheierea tuturor actelor pe care le-am verificat în 1c că aceste documente sunt efectuate în mod normal, fără erori. Doar curățați tabelul Namaum, desigur, nu merită: Este important să înțelegeți că este curățată și la ce se poate transforma.
5) a lansat o solicitare de creare a unui indice care a fost salvat în fișier.
6) Traducerea bazei de date în modul cu un singur utilizator și lansată DBCC CHECKDB - de data aceasta nu a fost emisă o singură eroare.
7) a transferat baza de date înapoi în modul unic utilizator.
Totul ... problema este învinsă. Ei bine, în 1c lansat "Testarea și corectarea", totul a fost bine acolo, a fost normal, a oprit să jure într-un indice ne-unic.

3. În cazul în care unelativitatea se află în datele cu valorile zeroProblema este rezolvată prin crearea unei baze de date cu un parametru de deplasare până în anul 2000.

1. Dacă problema încărcării bazei de date, atunci:
1.1. Dacă faceți descărcarea (utilizați fișierul DT) în baza de date MS SQL Server, atunci când creați o bază înainte de a descărca, specificați offsetul datelor - 2000.
Dacă baza este deja creată cu deplasarea 0, apoi creați una nouă din 2000.

1.2. Dacă aveți posibilitatea de a lucra cu baza de date în fișier, veți testa și remedia, precum și configurarea - verificarea configurației - verificarea integrității logice a configurației + Căutați legături incorecte.

1.3 Dacă nu există o versiune de fișier, încercați să descărcați de la DT la o versiune client-server cu DB2 (care este mai puțin exigentă pentru unicitate), apoi efectuați testarea și fixarea, precum și verificarea configurației - verificarea integrității logice a configurației + căutați pentru link-uri incorecte.

1.4. Pentru a localiza problema, puteți defini datele obiectului, încărcarea căreia a eșuat. Pentru a face acest lucru, trebuie să activați următorul utilitar de profile în timpul descărcării sau să activați înregistrarea în jurnalul tehnologic DBMSSQL și EXCP.

2. Dacă problema neplăcutei se manifestă în timp ce utilizatorii:

2.1. Găsiți cu metoda de la punctul 1.4 Cererea de problemă.

2.1.2. Uneori apare eroarea în timpul executării cererilor, de exemplu:

Această eroare apare datorită faptului că, în modulul Registrului de registru "orele de lucru ale angajaților organizațiilor" în procedura "Registrykers", în cerere, nu costă cuvântul oficial "diferit".
Cod 1c v 8.x adică Ar trebui să fie:
Solicitare \u003d cerere nouă (
"Alegeți diferit
| Infoizori majori,
. . . . .
În cele mai recente versiuni lansate de ZUP și UPP, eroarea nu apare deoarece Sunt diferite".

2.2. După găsirea unui indice de problemă din elementul anterior, este necesar să găsiți o intrare ne-unică.
2.2.1. Script de "pește" pentru a determina intrările non-unice utilizând SQL:
Cod SQL S_ELECT Count (*) Counter,<перечисление всех полей соответствующего индекса> Fr om.<имя таблицы>
A se grupa cu.<перечисление всех полей соответствующего индекса>
Având contra\u003e 1

2.2.2 Exemplu. Indicele din eroare este numit "_document140_vt1385_intkeyindng".
Lista câmpurilor de tabel:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Înainte de a efectua următoarea procedură, efectuați o copie de rezervă a bazei de date.
Rulați în analizerul de interogare MS SQL Server:
Sql s_elect numărare (*), _document140_idrref, _Keyfield
Fr om _document140_vt1385.
Grup de _document140_idrref, _Keyfield
Având numărul (*)\u003e 1
Cu aceasta, aflați valorile coloanei _document140_idrref, _keyfield, intrări duplicate (ID, cheie).

Folosind interogarea:
Sql s_elec * cod *
Fr om _document140_vt1385.
Unde _document140_idrref \u003d ID1 și _keyfield \u003d tasta1 sau _document140_idrref \u003d id2 și _Keyfield \u003d tasta2 sau ...
Uită-te la valorile altor coloane de înregistrări duplicate.
Dacă ambele înregistrări au valori semnificative și aceste valori sunt diferite, atunci corectați valoarea _Keyfield pe unul unic. Pentru a face acest lucru, determinați valoarea maximă ocupată _Keyfield (KeyMax):
SQL S_ELECT MAX (_KEYFIELD) cod
Fr om _document140_vt1385.
Wh ere _document140_idrref \u003d ID1
Înlocuiți valoarea _Keyfield într-una din înregistrările repetitive la corecte:
SQL Upd Ate _Document140_vt1385 Cod
Setați _Keyfield \u003d KeyMax + 1

Aici _lineno1386 \u003d - o condiție suplimentară care vă permite să selectați una din cele două înregistrări repetitive.

Dacă unul (sau ambele) din înregistrările repetitive are o valoare incorectă evidentă, atunci trebuie să fie eliminată:
SQL Ștergeți de la codul _document140_vt1385
Whive _document140_idrref \u003d ID1 și _lineno1386 \u003d lineno1
Dacă repetarea înregistrărilor au aceleași valori în toate coloanele, atunci trebuie să lăsați unul:
Cod SQL S_Electați distinct *
În # tmp1.
de la _document140_vt1385.

Ștergeți de la _document140_vt1385.
Wh ere _document140_idrref \u003d ID1 și _Keyfield \u003d Key1

I_sert în _document140_vt1385.
S_ELECT # TMP1.

D_rop tabel # tmp1

Procedura descrisă trebuie efectuată pentru fiecare pereche de înregistrări recurente.

2.2.3. Al doilea exemplu:
Codul SQL S_ELECT Count (*) ca Expr2, _IDRREF ca expr1, _desriftion
De la _reference8_
Grup de _idrref, _description
Având (număr (*)\u003e 1)

2.3.4 Un exemplu de determinare a intrărilor non-unice utilizând cererea 1C: Intreprindere:
Cod 1c v 8.x Selectați link-ul Manualului
Din Manual. Manualul ca director
Grupul pe cartea de referință
Având cantitate (*)\u003e 1

Informații luate de pe site