Acasă › Multimedia › S-a încercat să se insereze o valoare non-unica într-un index unic. Eroare: se încearcă inserarea unei valori neunice într-un index unic: server microsoft sql. atunci când treceți de la profesionist contabil la corporativ și nu numai Eliminați indecșii neunici din fișierul 1c 8

S-a încercat să se insereze o valoare non-unica într-un index unic. Eroare: se încearcă inserarea unei valori neunice într-un index unic: server microsoft sql. atunci când treceți de la profesionist contabil la corporativ și nu numai Eliminați indecșii neunici din fișierul 1c 8

Ați primit un mesaj care conține rândurile:
Furnizor Microsoft OLE DB pentru SQL Server: CREATE UNIQUE INDEX sa încheiat deoarece a fost găsită o cheie duplicată pentru ID-ul indexului
sau
Nu pot I_insera rândul de chei duplicat în obiect
sau
S-a încercat să se insereze o valoare non-unica într-un index unic.

Solutii:

1. În studioul de management SQL Server, distrugem fizic indexul defect (în cazul meu a fost un index pe tabelul cu totaluri ale registrului contabil). În 1C vom distribui documentele defecte. În modul de testare și corecție, bifați casetele pentru reindexarea tabelului + recalcularea totalurilor. 1C recreează indexul fără eroare. Efectuăm documente eșuate anterior.

2. 1) Folosind Management Studio 2005, am generat un script de creare pentru a crea un index, care avea erori, și l-am salvat într-un fișier.
2) A ucis manual indexul jambului din tabel _AccumRgTn19455
3) A lansat o solicitare like
Cod SQL S_elect count(*), index_fields
DE LA AccumRgTn19455
GROUP BY câmp_index
AVÂND numărare(*)>1
După ce indexul a fost eliminat, am avut 15 înregistrări duplicat afișate, deși înainte de pasul 2 interogarea nu a returnat nimic.
4) Am parcurs toate intrările și am curățat manual duplicatele. De fapt, am folosit și procesarea „Structura raportului” pentru a înțelege cu ce am de-a face. S-a dovedit că tabelul _AccumRgTn19455 stochează registrul de acumulare „Ieșirea produsului (contabilitatea fiscală)”. De asemenea, m-am chinuit cu interogări sql, am identificat 15 documente neunice, iar după ce s-au finalizat toate acțiunile, am verificat în 1C că aceste documente au fost procesate normal, fără erori. Desigur, nu ar trebui să curățați doar mesele la întâmplare: este important să înțelegeți ce este curățat și cum poate rezulta.
5) A lansat o cerere de creare a unui index, care a fost salvat într-un fișier.
6) A trecut baza de date în modul utilizator unic și a lansat dbcc checkdb - de data aceasta nu au fost generate erori.
7) A trecut baza înapoi în modul pentru utilizator unic.
Gata... problema este depasita. Ei bine, în 1C am lansat „Testing and Correction”, totul a mers bine și acolo, am încetat să mă plâng de indexul neunic.

3. Dacă non-unicitatea constă în date cu valori zero, atunci problema este rezolvată prin crearea unei baze de date cu un parametru de offset egal cu 2000.

1. Dacă problema este încărcarea bazei de date, atunci:
1.1. Dacă încărcați (folosind un fișier dt) într-o bază de date MS SQL Server, atunci când creați baza de date, înainte de încărcare, specificați data offset - 2000.
Dacă baza de date a fost deja creată cu offset 0, atunci creați una nouă cu 2000.

1.2. Dacă este posibil să lucrați cu baza de date în versiunea de fișier, atunci efectuați Testare și Corectare, precum și Configurare - Verificare configurație - Verificare integrității logice a configurației + Căutare link-uri incorecte.

1.3. Dacă nu există o versiune de fișier, încercați să încărcați de la DT într-o versiune client-server cu DB2 (care este mai puțin solicitantă în ceea ce privește unicitatea), apoi efectuați Testare și corectare, precum și Configurare - Verificare configurație - Verificare integritatea logică a configurației + Căutați referințe nevalide.

1.4. Pentru a localiza problema, puteți determina datele obiectului a cărui încărcare a eșuat. Pentru a face acest lucru, trebuie să activați urmărirea în utilitarul Profiler în timpul pornirii sau să activați înregistrarea în jurnalul de evenimente ale procesului DBMSSQL și EXCP.

2. Dacă problema de non-unicitate apare în timp ce utilizatorii lucrează:

2.1. Găsiți cererea problematică folosind metoda din paragraful 1.4.

2.1.2. Uneori apare o eroare în timpul executării interogărilor, de exemplu:

Această eroare apare din cauza faptului că în modulul de registru de acumulare „Timpul de lucru al angajaților organizațiilor” din procedura „Recalculare înregistrări”, cuvântul de serviciu „DIFERIT” nu este inclus în cerere.
Cod 1C v 8.x I.e. ar trebui să fie:
Solicitare = Solicitare nouă(
„SELECTARE DIVERSE
| Basic.Individual,
. . . . .
În ultimele versiuni ale ZUP și UPP, eroarea nu apare, deoarece scrie „DIFERIT”.

2.2. După ce ați găsit indexul problematic din paragraful anterior, trebuie să găsiți o înregistrare non-unica.
2.2.1. Scriptul „Fish” pentru identificarea înregistrărilor neunice folosind SQL:
Cod SQL S_elect COUNT(*) Counter,<перечисление всех полей соответствующего индекса>din<имя таблицы>
A SE GRUPA CU<перечисление всех полей соответствующего индекса>
AVÂND Contor > 1

2.2.2 Exemplu. Indexul din eroare se numește „_Document140_VT1385_IntKeyIndNG”.
Lista câmpurilor tabelului:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef, _FldPE13,_Fld1393_TY1393_Fld1393 RR Ref, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RTRef, _Fld222fld22,61_Fld22260_RTRef, _Fld1399RRef Ref, _Fld22261_RRRef
Înainte de a efectua procedura de mai jos, faceți o copie de rezervă a bazei de date.
Rulați în MS SQL Server Query Analyzer:
Cod SQL S_elect count(*), _Document140_IDRRef, _KeyField
din _Document140_VT1385
grupați după _Document140_IDRRef, _KeyField
având număr (*) > 1
Folosiți-l pentru a afla valorile coloanelor _Document140_IDRRef, _KeyField, înregistrări duplicate (id, cheie).

Folosind cererea:
Cod SQL S_elect *
din _Document140_VT1385
sau _Document140_IDRRef = id2 și _KeyField = key2 sau...
uitați-vă la valorile celorlalte coloane ale intrărilor duplicate.
Dacă ambele intrări au valori semnificative și valorile sunt diferite, atunci modificați valoarea _KeyField pentru a fi unică. Pentru a face acest lucru, determinați valoarea maximă ocupată a _KeyField (keymax):
Cod SQL S_elect max(_KeyField)
din _Document140_VT1385
unde _Document140_IDRRef = id1
Înlocuiți valoarea _KeyField într-una dintre intrările duplicate cu cea corectă:
Actualizare cod SQL _Document140_VT1385
setați _KeyField = keymax + 1
Aici _LineNo1386 = este o condiție suplimentară care vă permite să selectați una dintre cele două înregistrări repetate.

Dacă una (sau ambele) dintre intrările duplicate are o semnificație evident incorectă, atunci ar trebui eliminată:
Ștergerea codului SQL din _Document140_VT1385
unde _Document140_IDRRef = id1 și _LineNo1386 = lineno1
Dacă intrările duplicate au aceleași valori în toate coloanele, atunci trebuie să lăsați una dintre ele:
Cod SQL S_elect distinct *
în #tmp1
din _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1

Ștergeți din _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1

I_inserez în _Document140_VT1385
S_alege #tmp1

D_rop tabelul #tmp1

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

2.2.3. Al doilea exemplu:
Cod SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Descriere
DE LA _Referință8_
GROUP BY _IDRRef, _Description
AVÂND (NUMĂRĂ(*) > 1)

2.3.4 Un exemplu de determinare a înregistrărilor neunice utilizând o interogare 1C:Enterprise:
Cod 1C v 8.x SELECT Directory.Link
DIN Directory.Directory AS Directory
GROUP BY Directory.Link
AVÂND CANTITATE(*) > 1

Acest articol va descrie ce trebuie să faceți dacă, când lucrați cu 1C:Enterprise 8.1, întâlniți un mesaj care conține rândurile:

Nu se poate introduce un rând de chei duplicat în obiect

S-a încercat să se insereze o valoare non-unica într-un index unic.

Ce este un index?

Indecii sunt o structură care permite accesul rapid la rândurile dintr-un tabel pe baza valorilor uneia sau mai multor coloane ale acestuia.
Un index conține chei, construite dintr-una sau mai multe coloane ale unui tabel sau vizualizare și indicatori care se mapează la locul în care sunt stocate datele specificate.
Indexurile reduc cantitatea de date care trebuie citite pentru a returna un set de rezultate.

Deși un index este asociat cu o anumită coloană (sau coloane) dintr-un tabel, este totuși un obiect de bază de date separat.

Indecșii tabelelor din baza de date 1C:Enterprise sunt creați implicit la crearea obiectelor de configurare, precum și la anumite setări ale obiectelor de configurare.

Esența fizică a indicilor în MS SQL Server 2005.

Fizic datele sunt stocate pe pagini de 8 Kb. Imediat după creare, în timp ce tabelul nu are indecși, tabelul arată ca o grămadă de date. Înregistrările nu au o ordine specifică de stocare.
Când doriți să accesați date, SQL Server va produce scanarea tabelului(scanare la masă). SQL Server scanează întregul tabel pentru a găsi înregistrările pe care le caută.
De aici devin clare funcțiile de bază ale indicilor:
— creșterea vitezei de acces la date,
— suport pentru unicitatea datelor.

În ciuda avantajelor lor, indicii au și o serie de dezavantaje. Primul este indici ocupă spațiu suplimentar pe discși în RAM. De fiecare dată când creați un index, stocați cheile în ordine descrescătoare sau crescătoare, care pot avea o structură pe mai multe niveluri. Și cu cât cheia este mai mare/mai lungă, cu atât dimensiunea indexului este mai mare. Al doilea dezavantaj este operațiunile încetinesc inserarea, actualizarea și ștergerea înregistrărilor.
În mediul MS SQL Server 2005, sunt implementate mai multe tipuri de indici:

indecși non-cluster;
indici grupați (sau grupați);
indici unici;
indexuri cu coloane incluse
vizualizări indexate
text complet

Index unic

Unicitatea valorilor din coloana indexată este garantată de indici unici. Dacă sunt prezente, serverul nu vă va permite să introduceți o nouă valoare sau să modificați o valoare existentă în așa fel încât în urma acestei operațiuni să apară două valori identice în coloană.
Un index unic este un fel de supliment și poate fi implementat atât pentru indecși în cluster, cât și pentru cei non-cluster. Un tabel poate avea un index unic grupat și mulți indecși unici necluster.
Indicii unici ar trebui definiți numai atunci când este cu adevărat necesar. Pentru a asigura integritatea datelor pe o coloană, puteți defini o constrângere de integritate UNIQUE sau PRIMARY KEY, în loc să apelați la indecși unici. Folosirea lor exclusiv pentru a asigura integritatea datelor este o risipă de spațiu în baza de date. În plus, timpul CPU este cheltuit și pentru întreținerea acestora.

1C:Enterprise 8.1, începând cu versiunea 8.1, utilizează în mod activ indici unici grupați. Aceasta înseamnă că la conversia de la 8.0 sau la migrarea de la 8.1.7 este posibil să primiți o eroare de index neunică.

Dacă non-unicitatea constă în date cu valori zero, atunci problema este rezolvată prin crearea unei baze de date cu un parametru de offset egal cu 2000.

Ce să fac?

1. Dacă problema este încărcarea bazei de date, atunci:

1.1. Dacă încărcați (folosind un fișier dt) într-o bază de date MS SQL Server, atunci când creați baza de date, înainte de încărcare, specificați data offset - 2000.

Dacă baza de date a fost deja creată cu offset 0, atunci creați una nouă cu 2000.

1.5. Dacă nodul (planurile de schimb) este disponibil, atunci efectuați schimbul. De asemenea, puteți completa și punctul 2.3.5 înainte de a schimba

2. Dacă problema de non-unicitate apare în timp ce utilizatorii lucrează:

2.1. Găsiți cererea problematică folosind metoda din paragraful 1.4.

2.1.2. Uneori apare o eroare în timpul executării interogărilor, de exemplu:

Acestea. ar trebui să fie:

Solicitare = Solicitare nouă(
„SELECTARE DIVERSE
| Basic.Individual,

În ultimele versiuni ale ZUP și UPP, eroarea nu apare, deoarece scrie „DIFERIT”.

2.2. După ce ați găsit indexul problematic din paragraful anterior, trebuie să găsiți o înregistrare non-unica.

2.2.1. Scriptul „Fish” pentru identificarea înregistrărilor neunice folosind SQL:
SELECTARE CONT(*) Contor,<перечисление всех полей соответствующего индекса>din<имя таблицы>
A SE GRUPA CU<перечисление всех полей соответствующего индекса>
AVÂND Contor > 1

2.2.2 Exemplu. Indexul din eroare se numește „_Document140_VT1385_IntKeyIndNG”.

Lista câmpurilor tabelului:

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef, _Fld1393_FldTYRef3,_Fld1393,_Fld1393,_Fld1393 _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22260_RRRef, _Fld22260_RRRef, _Fld222261_22261_22261_Fld22261_RT _RRRef

Înainte de a efectua procedura de mai jos, faceți o copie de rezervă a bazei de date.
Rulați în MS SQL Server Query Analyzer:

selectați count(*), _Document140_IDRRef, _KeyField
din _Document140_VT1385
grupați după _Document140_IDRRef, _KeyField
având număr (*) > 1

Folosiți-l pentru a afla valorile coloanelor _Document140_IDRRef, _KeyField, înregistrări duplicate (id, cheie).

Folosind cererea:

Selectați *
din _Document140_VT1385
sau _Document140_IDRRef = id2 și _KeyField = key2 sau...

uitați-vă la valorile celorlalte coloane ale intrărilor duplicate.

Dacă ambele intrări au valori semnificative și valorile sunt diferite, atunci modificați valoarea _KeyField pentru a fi unică. Pentru a face acest lucru, determinați valoarea maximă ocupată a _KeyField (keymax):

selectați max(_KeyField)
din _Document140_VT1385
unde _Document140_IDRRef = id1

Înlocuiți valoarea _KeyField într-una dintre intrările duplicate cu cea corectă:

update_Document140_VT1385
setați _KeyField = keymax + 1

Aici _LineNo1386 = este o condiție suplimentară care vă permite să selectați una dintre cele două înregistrări repetate.

Dacă una (sau ambele) dintre intrările duplicate are o semnificație evident incorectă, atunci ar trebui eliminată:

unde _Document140_IDRRef = id1 și _LineNo1386 = lineno1

Dacă intrările duplicate au aceleași valori în toate coloanele, atunci trebuie să lăsați una dintre ele:

selectați distinct *
în #tmp1
din _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1

ștergeți din _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1

introduceți în _Document140_VT1385
selectați #tmp1

drop tabelul #tmp1

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

2.2.3. Al doilea exemplu:

SELECTARE COUNT(*) AS Expr2, _IDRRef AS Expr1, _Descriere
DE LA _Referință8_
GROUP BY _IDRRef, _Description
AVÂND (NUMĂRĂ(*) > 1)

2.3.4 Un exemplu de determinare a înregistrărilor neunice utilizând o interogare 1C:Enterprise:

sau pentru contabilitate

ALEGE
Subinterogare.Perioada,
Subquery.Registrator,
<измерения>,
SUM(Subquery.Număr de înregistrări) AS Număr de înregistrări
DIN
(ALEGE
Perioada AS Perioada,
Self-supporting.Registrar AS Registrar,
<измерения>,
1 AS Număr de înregistrări
DIN
Registrul contabil.AS autoportant Autoportant) AS Subinterogare

A SE GRUPA CU
Subinterogare.Perioada,
Subquery.Registrator,
<измерения>

AVÂND
SUM(Subinterogare.Număr de înregistrări) > 1

2.3.5 Faceți ca indicele subd să nu fie unic. Scrieți indexul folosind Management Studio.

2.3.6 Un caz special la schimbul în RDB. Eroarea apare în tabelele „auxiliare” asociate cu calculul totalurilor sau analitice. De exemplu:

Eroare la apelarea metodei context (Write): încercarea de a insera o valoare non-unica într-un index unic:
Furnizor Microsoft OLE DB pentru SQL Server: Nu se poate introduce un rând de chei duplicat în obiectul „dbo._AccntRegED10319” cu index unic „_Accnt10319_ByPeriod_TRNRN”.
HRESULT=80040E2F, SQLSrvr: stare de eroare=1, gravitate=E, nativ=2601, linie=1

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

Solutii:

2. 1) Folosind Management Studio 2005, am generat un script de creare pentru a crea un index, care avea erori, și l-am salvat într-un fișier.
2) A ucis manual indexul jambului din tabel _AccumRgTn19455
3) A lansat o solicitare like
Cod SQL S_elect count(*), index_fields
DE LA OM AccumRgTn19455
GROUP BY câmp_index
AVÂND numărare(*)>1
După ce indexul a fost eliminat, am avut 15 înregistrări duplicat afișate, deși înainte de pasul 2 interogarea nu a returnat nimic.
4) Am parcurs toate intrările și am curățat manual duplicatele. De fapt, am folosit și procesarea „Structura raportului” pentru a înțelege cu ce am de-a face. S-a dovedit că tabelul _AccumRgTn19455 stochează registrul de acumulare „Ieșirea produsului (contabilitatea fiscală)”. De asemenea, m-am chinuit cu interogări sql, am identificat 15 documente neunice, iar după ce s-au finalizat toate acțiunile, am verificat în 1C că aceste documente au fost procesate normal, fără erori. Desigur, nu ar trebui să curățați doar mesele la întâmplare: este important să înțelegeți ce este curățat și cum poate rezulta.
5) A lansat o cerere de creare a unui index, care a fost salvat într-un fișier.
6) A trecut baza de date în modul utilizator unic și a lansat dbcc checkdb - de data aceasta nu au fost generate erori.
7) A trecut baza înapoi în modul pentru utilizator unic.
Gata... problema este depasita. Ei bine, în 1C am lansat „Testing and Correction”, totul a mers bine și acolo, am încetat să mă plâng de indexul neunic.

3. Dacă non-unicitatea constă în date cu valori zero, atunci problema este rezolvată prin crearea unei baze de date cu un parametru de offset egal cu 2000.

2. Dacă problema de non-unicitate apare în timp ce utilizatorii lucrează:

2.1. Găsiți cererea problematică folosind metoda din paragraful 1.4.

2.1.2. Uneori apare o eroare în timpul executării interogărilor, de exemplu:

2.2. După ce ați găsit indexul problematic din paragraful anterior, trebuie să găsiți o înregistrare non-unica.
2.2.1. Scriptul „Fish” pentru identificarea înregistrărilor neunice folosind SQL:
Cod SQL S_elect COUNT(*) Counter,<перечисление всех полей соответствующего индекса>din om<имя таблицы>
A SE GRUPA CU<перечисление всех полей соответствующего индекса>
AVÂND Contor > 1

2.2.2 Exemplu. Indexul din eroare se numește „_Document140_VT1385_IntKeyIndNG”.
Lista câmpurilor tabelului:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef, _FldPE13,_Fld1393_TY1393_Fld1393 RR Ref, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RTRef, _Fld222fld22,61_Fld22260_RTRef, _Fld1399RRef Ref, _Fld22261_RRRef
Înainte de a efectua procedura de mai jos, faceți o copie de rezervă a bazei de date.
Rulați în MS SQL Server Query Analyzer:
Cod SQL S_elect count(*), _Document140_IDRRef, _KeyField
din om _Document140_VT1385
grupați după _Document140_IDRRef, _KeyField
având număr (*) > 1
Folosiți-l pentru a afla valorile coloanelor _Document140_IDRRef, _KeyField, înregistrări duplicate (id, cheie).

Folosind cererea:
Cod SQL S_elect *
din om _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1 sau _Document140_IDRRef = id2 și _KeyField = key2 sau...
uitați-vă la valorile celorlalte coloane ale intrărilor duplicate.
Dacă ambele intrări au valori semnificative și valorile sunt diferite, atunci modificați valoarea _KeyField pentru a fi unică. Pentru a face acest lucru, determinați valoarea maximă ocupată a _KeyField (keymax):
Cod SQL S_elect max(_KeyField)
din om _Document140_VT1385
unde _Document140_IDRRef = id1
Înlocuiți valoarea _KeyField într-una dintre intrările duplicate cu cea corectă:
Actualizarea codului SQL _Document140_VT1385
setați _KeyField = keymax + 1

Aici _LineNo1386 = este o condiție suplimentară care vă permite să selectați una dintre cele două înregistrări repetate.

Ștergeți din _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1

I_inserez în _Document140_VT1385
S_alege #tmp1

D_rop tabelul #tmp1

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

2.2.3. Al doilea exemplu:
Cod SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Descriere
DE LA _Referință8_
GROUP BY _IDRRef, _Description
AVÂND (NUMĂRĂ(*) > 1)

Informatii preluate de pe site

Solutii:

3. Dacă non-unicitatea constă în date cu valori zero, atunci problema este rezolvată prin crearea unei baze de date cu un parametru de offset egal cu 2000.

2. Dacă problema de non-unicitate apare în timp ce utilizatorii lucrează:

2.1. Găsiți cererea problematică folosind metoda din paragraful 1.4.

2.1.2. Uneori apare o eroare în timpul executării interogărilor, de exemplu:

Ștergeți din _Document140_VT1385
unde _Document140_IDRRef = id1 și _KeyField = key1

I_inserez în _Document140_VT1385
S_alege #tmp1

D_rop tabelul #tmp1

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

2.2.3. Al doilea exemplu:
Cod SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Descriere
DE LA _Referință8_
GROUP BY _IDRRef, _Description
AVÂND (NUMĂRĂ(*) > 1)

Popular în categoria: