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

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 „Timp 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, _fld1393 Rrref, _fld1394, _fld1395, _fld1396rref, _fld1397, _fld1398, _fld1399rref, _fld22260_type, _fld22260_fld Fld22261 _rtref, _fld222261_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, _Description
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
FROM 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 datele cu valori zero, atunci problema poate fi 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 Counter > 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, _Fld1393_Fld1393 , _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22260_RRRef, _Fld22226_2_2_2261 1_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
Auto-susținere Perioada AS.
Self-supporting.Registrar AS Registrar,
<измерения>,
1 AS Număr de înregistrări
DIN
Registrul contabil Autoportant AS 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:

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, _Description
DE LA _Referință8_
GROUP BY _IDRRef, _Description
AVÂND (NUMĂRĂ(*) > 1)

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, _fld1393 Rrref, _fld1394, _fld1395, _fld1396rref, _fld1397, _fld1398, _fld1399rref, _fld22260_type, _fld22260_fld Fld22261 _rtref, _fld222261_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, _Description
DE LA _Referință8_
GROUP BY _IDRRef, _Description
AVÂND (NUMĂRĂ(*) > 1)

Informatii preluate de pe site

Apare o eroare dacă unele obiecte, detalii, subconturi din baza de date au o valoare NULL, dar nu pot avea o astfel de valoare. Și această eroare apare doar în bazele de date SQL. Acestea. Dacă încărcați o astfel de bază de date într-un fișier, atunci această eroare nu va mai exista. Deoarece Baza de date de fișiere are propriile tabele (4 în total), iar SQL are propriile sale tabele. Și baza de date SQL reacționează critic la astfel de valori din tabelele sale.

Această problemă nu poate fi rezolvată prin nicio testare (nici externă, nici internă) în nicio versiune a bazei de date (SQL sau fișier) și nici chiar prin Procedura _1sp_DBReindex din managerul SQL, care pare să restructureze tabelele în SQL.

Să ne uităm la soluția problemei folosind exemplul de trecere de la Accounting 3.0 PROF la CORP. După tranziție, contul 68.01 are un nou subcont, Înregistrare la organul fiscal. Și apoi, în bazele de date SQL, toate documentele create în versiunea PRO care folosesc acest cont nu vor fi transferate. Va apărea eroarea afișată mai sus. Deoarece Acest nou subcont pentru documente vechi, în postări, va fi scris cu valoarea NULL (deși ar trebui să existe o valoare Golă, sau cumva autoritatea fiscală).

Pentru a remedia această eroare, trebuie să eliminați valorile NULL acolo unde nu ar trebui să fie. În acest caz, în documentele în care se utilizează subcontul Înregistrare la organul fiscal. Acest lucru se poate face prin scrierea unei procesări care va înlocui NULL cu o valoare goală (procesarea gata poate fi descărcată din acest articol). Fă-o prin procesare, pentru că O încercare de a modifica manual valoarea acestui subcont în înregistrările documentelor are ca rezultat aceeași eroare.

Procesarea pentru înlocuirea NULL-urilor în toate subcontactele de Înregistrare la Autoritatea Fiscală poate fi descărcată din acest articol de mai jos.

DAR nu va funcționa pentru a înlocui NULL în baza de date SQL în timpul procesării va fi generată aceeași eroare. Prin urmare, trebuie să faceți acest lucru:

1. Încărcați versiunea deja funcțională a bazei de date SQL, tradusă în CORP, în fișierul dt (în configuratorul Administrare – Încărcare bază de date – selectați unde să încărcați baza de date ca fișier *.dt)

2. Încărcați fișierul dt în baza de date de fișiere (într-o bază de date de fișiere curată sau inutilă sau pregătită în prealabil, în configuratorul Administrare - Încărcare bază de date - selectați fișierul dt încărcat anterior)

3. Efectuați procesarea în baza de date de fișiere (nu vor exista erori acolo și toate NULL-urile vor fi înlocuite corect) (cum se efectuează procesarea este descris mai jos)

5. Acum, dimpotrivă, descărcați fișierul dt din baza de date de fișiere și încărcați-l în baza de date SQL. Acum, la postarea documentelor procesate, erorile nu vor apărea.

În prelucrarea din acest articol se regăsesc toate documentele pentru perioada specificată în care afișările includ Înregistrarea subcontractului la Administrația Fiscală (care apare în varianta CORP), care are valoarea NULL. Și înlocuiește această valoare cu o valoare goală.

În procesare, trebuie să indicați perioada pentru care doriți să procesați documentele (puteți pentru întreaga perioadă în care înregistrările sunt păstrate în baza de date) și să faceți clic pe „Completați secțiunea tabelară”. Apoi puteți bifa casetele pentru a marca ce documente să procesați (le puteți selecta pe toate) și faceți clic pe butonul „Procesează”.

În consecință, dacă cineva are aceeași eroare, dar NU după ce a trecut la CORP, ci de exemplu după ce a schimbat, a încărcat niște date, a efectuat unele procesări etc. Apoi trebuie să identificați unde a fost atribuită valoarea NULL într-un anumit document/director și să eliminați acest NULL într-un mod similar, dar cu propria dvs. procesare, dar în ordinea descrisă mai sus. Amintiți-vă că NULL poate fi, ca și în postările de documente, inclusiv. nu doar contabile, ci și undeva pe forma unui document/carte de referință, în unele detalii, dar în acest caz probabil nici nu se va deschide.

De asemenea, dacă această eroare ți-a apărut la postarea unui document, după ce ai transferat baza de date a fișierelor Bukh KORP în SQL (și baza de date era cândva PROF), înseamnă că acele documente care au fost create în versiunea PROF sunt acum și în Înregistrarea subcontului în valoarea NULL de la Autoritatea Fiscală și baza de date SQL nu acceptă acest lucru. Și la încărcarea bazei de date în SQL, va apărea următoarea eroare. Aici, de fapt, nu vor exista valori NULL în baza de date de fișiere, dar SQL va încărca exact astfel de valori în tabelele sale. Prin urmare, aici trebuie să forțăm baza de date SQL să creeze aceste valori NULL și apoi să le corectăm în baza de date de fișiere, dar nu vă pot spune cum să faceți acest lucru.