Greška: Pokušaj umetanja nejedinstvene vrijednosti u jedinstveni indeks: microsoft sql server. pri prelasku sa buh prof na bldg i ne samo. Napravljen je pokušaj umetanja nejedinstvene vrijednosti u jedinstveni indeks. Duplicirana vrijednost se ne može umetnuti u jedinstveni indeks.

Primili ste poruku koja sadrži redove:
Microsoft OLE DB dobavljač za SQL Server: CREATE UNIQUE INDEX prekinut jer je pronađen duplikat ključa za ID indeksa
ili
Ne mogu I_umetnuti duplirani red ključa u objektu
ili
Napravljen je pokušaj umetanja nejedinstvene vrijednosti u jedinstveni indeks.

rješenja:

1. U studiju za upravljanje SQL Serverom fizički uništavamo neispravan indeks (u mom slučaju je to bio indeks u tabeli ukupnih registra računovodstva). U 1C ćemo distribuirati neispravne dokumente. U režimu testiranja i korekcije, potvrdite okvire za ponovno indeksiranje tabele + ponovno izračunavanje ukupnih vrednosti. 1C ponovo kreira indeks bez greške. Vršimo prethodno propale dokumente.

2. 1) Koristeći Management Studio 2005, generirao sam skriptu za kreiranje indeksa, koji je bio pogrešan, i spremio ga u datoteku.
2) Ručno ubio indeks jamb iz tabele _AccumRgTn19455
3) Pokrenuo zahtjev poput
SQL kod S_elect count(*), index_fields
OD AccumRgTn19455
GROUP BY indeks_polje
IMAJUĆI broj(*)>1
Nakon što je indeks ubijen, prikazao sam 15 duplikata, iako prije koraka 2 upit nije vratio ništa.
4) Prošao sam kroz sve unose i ručno očistio duplikate. U stvari, koristio sam i obradu „Strukture izvještaja“ da bih shvatio s čime se bavim. Ispostavilo se da tabela _AccumRgTn19455 pohranjuje registar akumulacije „Izlaz proizvoda (poresko računovodstvo)“. Bavio sam se i sql upitima, identifikovao 15 nejedinstvenih dokumenata, i nakon što su svi koraci obavljeni, proverio sam u 1C da li su ti dokumenti obrađeni normalno, bez grešaka. Naravno, ne biste trebali samo nasumično čistiti stolove: važno je razumjeti šta se čisti i kako to može ispasti.
5) Pokrenuo zahtjev za kreiranje indeksa, koji je sačuvan u fajlu.
6) Prebacio bazu podataka u jednokorisnički način rada i pokrenuo dbcc checkdb - ovaj put nije bilo generiranih grešaka.
7) Vratio bazu u režim za jednog korisnika.
To je to... problem je prevaziđen. Pa, još u 1C sam pokrenuo „Testiranje i ispravljanje“, i tu je sve prošlo u redu, prestao sam da se žalim na nejedinstveni indeks.

3. Ako nejedinstvenost leži u datumima sa nultim vrijednostima, tada se problem rješava kreiranjem baze podataka s parametrom pomaka jednakim 2000.

1. Ako je problem učitavanje baze podataka, tada:
1.1. Ako učitavate (koristeći dt-datoteku) u bazu podataka MS SQL Servera, tada prilikom kreiranja baze podataka prije učitavanja navedite pomak datuma - 2000.
Ako je baza podataka već kreirana sa pomakom 0, onda kreirajte novu sa 2000.

1.2. Ako je moguće raditi sa bazom podataka u verziji datoteke, onda izvršite Testiranje i ispravku, kao i Konfiguracija - Provjera konfiguracije - Provjera logičkog integriteta konfiguracije + Traženje neispravnih veza.

1.3. Ako ne postoji verzija datoteke, pokušajte učitati iz DT-a u verziju klijent-poslužitelj s DB2 (koja je manje zahtjevna za jedinstvenost), a zatim izvršite testiranje i ispravku, kao i konfiguraciju - provjerite konfiguraciju - provjerite logički integritet konfiguracije + Traži nevažeće reference.

1.4. Da biste lokalizirali problem, možete odrediti podatke objekta čije učitavanje nije uspjelo. Da biste to učinili, morate omogućiti praćenje u uslužnom programu Profiler tokom pokretanja ili omogućiti snimanje u DBMSSQL i EXCP evidenciji događaja procesa.

2. Ako se problem nejedinstvenosti pojavi dok korisnici rade:

2.1. Pronađite problematičan zahtjev koristeći metodu iz paragrafa 1.4.

2.1.2. Ponekad dođe do greške prilikom izvršavanja upita, na primjer:

Ova greška nastaje zbog činjenice da u modulu registra akumulacije „Radno vrijeme zaposlenih u organizacijama“ u proceduri „Preračuni registra“ u zahtjevu nije uključena servisna riječ „DRUGAČIJE“.
Kod 1C v 8.x tj. trebao bi biti:
Zahtjev = Novi zahtjev(
"IZABIR RAZNO
| Basic.Individual,
. . . . .
U najnovijim izdanjima ZUP-a i UPP-a greška se ne javlja, jer piše "DRUGAČIJE".

2.2. Nakon pronalaska problematičnog indeksa iz prethodnog paragrafa, potrebno je pronaći nejedinstveni zapis.
2.2.1. "Fish" skripta za identifikaciju nejedinstvenih zapisa pomoću SQL-a:
SQL kod S_odaberi COUNT(*) Brojač,<перечисление всех полей соответствующего индекса>od<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
IMAJUĆI Brojač > 1

2.2.2 Primjer. Indeks u grešci se zove "_Document140_VT1385_IntKeyIndNG".
Lista polja tabele:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_RT_, _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22f226 _Fld22f226 _RTRef, _Fld22261_RRRef
Prije izvođenja procedure u nastavku, uradite rezervna kopija baze podataka.
Pokrenite u MS SQL Server Query Analyzeru:
SQL kod S_odaberi broj(*), _Document140_IDRRef, _KeyField
iz_Dokumenta140_VT1385
grupirati po _Document140_IDRRef, _KeyField
imaju broj (*) > 1
Koristite ga da saznate vrijednosti stupaca _Document140_IDRRef, _KeyField, duplih zapisa (id, ključ).

Koristeći zahtjev:
SQL kod S_elect *
iz_Dokumenta140_VT1385
ili _Document140_IDRRef = id2 i _KeyField = ključ2 ili ...
pogledajte vrijednosti ostalih stupaca duplikata unosa.
Ako oba unosa imaju značajne vrijednosti i vrijednosti su različite, promijenite vrijednost _KeyField da bude jedinstvena. Da biste to učinili, odredite maksimalnu zauzetu vrijednost _KeyField (keymax):
SQL kod S_elect max(_KeyField)
iz_Dokumenta140_VT1385
gdje je _Document140_IDRRef = id1
Zamijenite vrijednost _KeyField u jednom od duplikata unosa ispravnim:
Ažuriranje SQL koda _Document140_VT1385
postavite _KeyField = keymax + 1
Ovdje _LineNo1386 = je dodatni uvjet koji vam omogućava da odaberete jedan od dva ponavljanja zapisa.

Ako jedan (ili oba) duplikat unosa ima očigledno pogrešno značenje, onda ga treba ukloniti:
Brisanje SQL koda iz _Document140_VT1385
gdje je _Document140_IDRRef = id1 i _LineNo1386 = lineno1
Ako dupli unosi imaju iste vrijednosti u svim stupcima, onda morate ostaviti jedan od njih:
SQL kod S_odaberi različit *
u #tmp1
iz_Dokumenta140_VT1385
gdje je _Document140_IDRRef = id1 i _KeyField = ključ1

Izbriši iz _Document140_VT1385
gdje je _Document140_IDRRef = id1 i _KeyField = ključ1

I_umetnuti u _Document140_VT1385
Odaberite #tmp1

D_rop tablica #tmp1

Opisani postupak se mora izvršiti za svaki par duplikata zapisa.

2.2.3. Drugi primjer:
SQL kod S_odaberi COUNT(*) AS Izraz2, _IDRRef AS Izraz1, _Opis
IZ _Reference8_
GROUP BY _IDRRef, _Description
IMATI (BROJ(*) > 1)

2.3.4 Primjer određivanja nejedinstvenih zapisa korištenjem 1C:Enterprise upita:
Kod 1C v 8.x SELECT Directory.Link
FROM Directory.Directory AS direktorij
GROUP BY Directory.Link
IMAJUĆI KOLIČINU(*) > 1

Greška se javlja ako neki objekti, detalji, podkontoi u bazi podataka imaju NULL vrijednost, ali ne mogu imati takvu vrijednost. I ova greška se pojavljuje samo u SQL bazama podataka. One. Ako takvu bazu podataka prenesete u datoteku, tada ove greške više neće biti. Jer Datotečna baza podataka ima svoje tablice (ukupno 4), a SQL ima svoje. I SQL baza podataka kritički reagira na takve vrijednosti u svojim tabelama.

Ovaj problem se ne može riješiti nikakvim testiranjem (ni eksternim ni internim) u bilo kojoj verziji baze podataka (SQL ili datoteka) pa čak ni _1sp_DBReindex procedurom u SQL menadžeru, koja izgleda treba da restrukturira tablice u SQL-u.

Pogledajmo rješenje problema na primjeru prelaska sa računovodstva 3.0 PROF na CORP. Nakon tranzicije, račun 68.01 ima novi podračun, registraciju kod Poreske uprave. I tada, u SQL bazama podataka, svi dokumenti kreirani u PRO verziji koji koriste ovaj račun neće biti prenijeti. Pojavit će se gore prikazana greška. Jer Ovaj novi podračun za stare dokumente, u knjiženjima, biće ispisan sa vrijednošću NULL (iako bi trebala postojati Empty vrijednost, ili nekako poreska uprava).

Da biste ispravili ovu grešku, morate ukloniti NULL vrijednosti tamo gdje ne bi trebale biti. U ovom slučaju, u dokumentima u kojima se koristi Registracija podračuna kod Poreske uprave. To se može učiniti pisanjem obrade koja će zamijeniti NULL vrijednošću Empty (spremna obrada može se preuzeti iz ovog članka). Uradite to obradom, jer Pokušaj da se vrijednost ovog podračuna ručno promijeni u knjiženjima dokumenata rezultira istom greškom.

Obradu za zamjenu NULL-ova u svim podkontaktima registracije kod Poreske uprave možete preuzeti iz ovog članka ispod.

ALI neće raditi zamjena NULL u SQL bazi podataka tokom obrade će se generirati ista greška. Stoga je potrebno da uradite sledeće:

1. Učitajte već radnu verziju SQL baze podataka, prevedenu u CORP, u dt datoteku (u konfiguratoru Administracija – Prenesi bazu podataka – odaberite gdje želite učitati bazu podataka kao *.dt datoteku)

2. Učitajte dt datoteku u datoteku baze podataka (u nepotrebnu ili unaprijed pripremljenu, čistu bazu podataka, u konfiguratoru Administracija - Učitaj bazu podataka - odaberite prethodno učitanu dt datoteku)

3. Izvršite obradu u bazi podataka (tamo neće biti grešaka i sve NULL-ove će biti ispravno zamijenjene) (način obrade je opisan u nastavku)

5. Sada, naprotiv, ispraznite dt datoteku iz baze podataka datoteka i učitajte je u SQL bazu podataka. Sada, prilikom knjiženja obrađenih dokumenata, greške neće biti.

Obradom iz ovog članka pronalaze se svi dokumenti za navedeni period u kojem knjiženja uključuju registraciju podugovora kod Poreske uprave (koja se pojavljuje u verziji CORP) koja ima vrijednost NULL. I zamjenjuje ovu vrijednost vrijednošću Empty.

U obradi morate naznačiti period za koji trebate obraditi dokumente (možete za cijeli period u kojem se vodi evidencija u bazi) i kliknite na „Popuni tabelarni dio" Zatim možete označiti kućice da označite koje dokumente želite obraditi (možete odabrati sve) i kliknite na dugme „Obradi“.

Shodno tome, ako neko ima istu grešku, ali NE nakon prelaska na CORP, već npr. nakon razmjene, učitavanja nekih podataka, obavljanja neke obrade itd. Zatim morate identificirati gdje je NULL vrijednost dodijeljena u određenom dokumentu/direktoriju i ukloniti ovu NULL vrijednost na sličan način, ali vlastitom obradom, ali gore opisanim redoslijedom. Zapamtite da NULL može biti, kao kod knjiženja dokumenata, uklj. ne samo računovodstvene, nego i negdje na formi dokumenta/uputnice, u nekim detaljima, ali u ovom slučaju se vjerovatno neće ni otvoriti.

Također, ako vam se ova greška pojavila prilikom objavljivanja dokumenta, nakon što ste prenijeli bazu podataka Bukh KORP u SQL (a baza je nekada bila PROF), to znači da su oni dokumenti koji su kreirani u PROF verziji sada također u Registracija podračuna u Poreskoj upravi NULL vrijednost i SQL baza to ne prihvaća. A prilikom učitavanja baze podataka u SQL pojavit će se sljedeća greška. Ovdje, u stvari, neće biti NULL vrijednosti u bazi podataka, ali će SQL učitati upravo takve vrijednosti u svoje tablice. Stoga, moramo da forsiramo SQL baza podataka kreirajte ove NULL-ove, a zatim ih ispravite u bazi podataka, ali ne mogu vam reći kako to učiniti.

Primili ste poruku koja sadrži redove:
Microsoft OLE DB dobavljač za SQL Server: CREATE UNIQUE INDEX prekinut jer je pronađen duplikat ključa za ID indeksa
ili
Ne mogu I_umetnuti duplirani red ključa u objektu
ili
Napravljen je pokušaj umetanja nejedinstvene vrijednosti u jedinstveni indeks.

rješenja:

1. U studiju za upravljanje SQL Serverom fizički uništavamo neispravan indeks (u mom slučaju je to bio indeks u tabeli ukupnih registra računovodstva). U 1C ćemo distribuirati neispravne dokumente. U režimu testiranja i korekcije, potvrdite okvire za ponovno indeksiranje tabele + ponovno izračunavanje ukupnih vrednosti. 1C ponovo kreira indeks bez greške. Vršimo prethodno propale dokumente.

2. 1) Koristeći Management Studio 2005, generirao sam skriptu za kreiranje indeksa, koji je bio pogrešan, i spremio ga u datoteku.
2) Ručno ubio indeks jamb iz tabele _AccumRgTn19455
3) Pokrenuo zahtjev poput
SQL kod S_elect count(*), index_fields
OD OM AccumRgTn19455
GROUP BY indeks_polje
IMAJUĆI broj(*)>1
Nakon što je indeks ubijen, prikazao sam 15 duplikata, iako prije koraka 2 upit nije vratio ništa.
4) Prošao sam kroz sve unose i ručno očistio duplikate. U stvari, koristio sam i obradu „Strukture izvještaja“ da bih shvatio s čime se bavim. Ispostavilo se da tabela _AccumRgTn19455 pohranjuje registar akumulacije „Izlaz proizvoda (poresko računovodstvo)“. Bavio sam se i sql upitima, identifikovao 15 nejedinstvenih dokumenata, i nakon što su svi koraci obavljeni, proverio sam u 1C da li su ti dokumenti obrađeni normalno, bez grešaka. Naravno, ne biste trebali samo nasumično čistiti stolove: važno je razumjeti šta se čisti i kako to može ispasti.
5) Pokrenuo zahtjev za kreiranje indeksa, koji je sačuvan u fajlu.
6) Prebacio bazu podataka u jednokorisnički način rada i pokrenuo dbcc checkdb - ovaj put nije bilo generiranih grešaka.
7) Vratio bazu u režim za jednog korisnika.
To je to... problem je prevaziđen. Pa, još u 1C sam pokrenuo „Testiranje i ispravljanje“, i tu je sve prošlo u redu, prestao sam da se žalim na nejedinstveni indeks.

3. Ako nejedinstvenost leži u datumima sa nultim vrijednostima, tada se problem rješava kreiranjem baze podataka s parametrom pomaka jednakim 2000.

1. Ako je problem učitavanje baze podataka, tada:
1.1. Ako učitavate (koristeći dt-datoteku) u bazu podataka MS SQL Servera, tada prilikom kreiranja baze podataka prije učitavanja navedite pomak datuma - 2000.
Ako je baza podataka već kreirana sa pomakom 0, onda kreirajte novu sa 2000.

1.2. Ako je moguće raditi sa bazom podataka u verziji datoteke, onda izvršite Testiranje i ispravku, kao i Konfiguracija - Provjera konfiguracije - Provjera logičkog integriteta konfiguracije + Traženje neispravnih veza.

1.3. Ako ne postoji verzija datoteke, pokušajte učitati iz DT-a u verziju klijent-poslužitelj s DB2 (koja je manje zahtjevna za jedinstvenost), a zatim izvršite testiranje i ispravku, kao i konfiguraciju - provjerite konfiguraciju - provjerite logički integritet konfiguracije + Traži nevažeće reference.

1.4. Da biste lokalizirali problem, možete odrediti podatke objekta čije učitavanje nije uspjelo. Da biste to učinili, morate omogućiti praćenje u uslužnom programu Profiler tokom pokretanja ili omogućiti snimanje u DBMSSQL i EXCP evidenciji događaja procesa.

2. Ako se problem nejedinstvenosti pojavi dok korisnici rade:

2.1. Pronađite problematičan zahtjev koristeći metodu iz paragrafa 1.4.

2.1.2. Ponekad dođe do greške prilikom izvršavanja upita, na primjer:

Ova greška nastaje zbog činjenice da u modulu registra akumulacije „Radno vrijeme zaposlenih u organizacijama“ u proceduri „Preračuni registra“ u zahtjevu nije uključena servisna riječ „DRUGAČIJE“.
Kod 1C v 8.x tj. trebao bi biti:
Zahtjev = Novi zahtjev(
"IZABIR RAZNO
| Basic.Individual,
. . . . .
U najnovijim izdanjima ZUP-a i UPP-a greška se ne javlja, jer piše "DRUGAČIJE".

2.2. Nakon pronalaska problematičnog indeksa iz prethodnog paragrafa, potrebno je pronaći nejedinstveni zapis.
2.2.1. "Fish" skripta za identifikaciju nejedinstvenih zapisa pomoću SQL-a:
SQL kod S_odaberi COUNT(*) brojač,<перечисление всех полей соответствующего индекса>fr om<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
IMAJUĆI Brojač > 1

2.2.2 Primjer. Indeks u grešci se zove "_Document140_VT1385_IntKeyIndNG".
Lista polja tabele:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_RT_, _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22f226 _Fld22f226 _RTRef, _Fld22261_RRRef
Prije nego što izvršite proceduru u nastavku, napravite sigurnosnu kopiju vaše baze podataka.
Pokrenite u MS SQL Server Query Analyzeru:
SQL kod S_odaberi broj(*), _Document140_IDRRef, _KeyField
od _Document140_VT1385
grupirati prema _Document140_IDRRef, _KeyField
imaju broj (*) > 1
Koristite ga da saznate vrijednosti stupaca _Document140_IDRRef, _KeyField, duplih zapisa (id, ključ).

Koristeći zahtjev:
SQL kod S_elect *
od _Document140_VT1385
gdje je _Document140_IDRRef = id1 i _KeyField = ključ1 ili _Document140_IDRRef = id2 i _KeyField = ključ2 ili ...
pogledajte vrijednosti ostalih kolona duplih unosa.
Ako oba unosa imaju značajne vrijednosti i vrijednosti su različite, promijenite vrijednost _KeyField da bude jedinstvena. Da biste to učinili, odredite maksimalnu zauzetu vrijednost _KeyField (keymax):
SQL kod S_elect max(_KeyField)
od _Document140_VT1385
gdje je _Document140_IDRRef = id1
Zamijenite vrijednost _KeyField u jednom od dupliranih unosa ispravnim:
Ažuriran SQL kod _Document140_VT1385
postavite _KeyField = keymax + 1

Ovdje _LineNo1386 = je dodatni uvjet koji vam omogućava da odaberete jedan od dva ponavljanja zapisa.

Ako jedan (ili oba) duplikat unosa ima očigledno pogrešno značenje, onda ga treba ukloniti:
Brisanje SQL koda iz _Document140_VT1385
gdje je _Document140_IDRRef = id1 i _LineNo1386 = lineno1
Ako dupli unosi imaju iste vrijednosti u svim stupcima, onda morate ostaviti jedan od njih:
SQL kod S_odaberi različit *
u #tmp1
iz _Dokumenta140_VT1385

Izbriši iz _Document140_VT1385
gdje su _Document140_IDRRef = id1 i _KeyField = key1

I_umetnuti u _Document140_VT1385
S_odaberite #tmp1

D_rop tablica #tmp1

Opisani postupak se mora izvršiti za svaki par duplikata zapisa.

2.2.3. Drugi primjer:
SQL kod S_odaberi COUNT(*) AS Izraz2, _IDRRef AS Izraz1, _Opis
IZ _Reference8_
GROUP BY _IDRRef, _Description
IMATI (BROJ(*) > 1)

2.3.4 Primjer određivanja nejedinstvenih zapisa korištenjem 1C:Enterprise upita:
Kod 1C v 8.x SELECT Directory.Link
FROM Directory.Directory AS direktorij
GROUP BY Directory.Link
IMAJUĆI KOLIČINU(*) > 1

Informacije preuzete sa stranice

Primili ste poruku koja sadrži redove:
Microsoft OLE DB dobavljač za SQL Server: CREATE UNIQUE INDEX prekinut jer je pronađen duplikat ključa za ID indeksa
ili
Ne mogu I_umetnuti duplirani red ključa u objektu
ili
Napravljen je pokušaj umetanja nejedinstvene vrijednosti u jedinstveni indeks.

rješenja:

1. U studiju za upravljanje SQL Serverom fizički uništavamo neispravan indeks (u mom slučaju je to bio indeks u tabeli ukupnih registra računovodstva). U 1C ćemo distribuirati neispravne dokumente. U režimu testiranja i korekcije, potvrdite okvire za ponovno indeksiranje tabele + ponovno izračunavanje ukupnih vrednosti. 1C ponovo kreira indeks bez greške. Vršimo prethodno propale dokumente.

2. 1) Koristeći Management Studio 2005, generirao sam skriptu za kreiranje indeksa, koji je bio pogrešan, i spremio ga u datoteku.
2) Ručno ubio indeks jamb iz tabele _AccumRgTn19455
3) Pokrenuo zahtjev poput
SQL kod S_elect count(*), index_fields
OD AccumRgTn19455
GROUP BY indeks_polje
IMAJUĆI broj(*)>1
Nakon što je indeks ubijen, prikazao sam 15 duplikata, iako prije koraka 2 upit nije vratio ništa.
4) Prošao sam kroz sve unose i ručno očistio duplikate. U stvari, koristio sam i obradu „Strukture izvještaja“ da bih shvatio s čime se bavim. Ispostavilo se da tabela _AccumRgTn19455 pohranjuje registar akumulacije „Izlaz proizvoda (poresko računovodstvo)“. Bavio sam se i sql upitima, identifikovao 15 nejedinstvenih dokumenata, i nakon što su svi koraci obavljeni, proverio sam u 1C da li su ti dokumenti obrađeni normalno, bez grešaka. Naravno, ne biste trebali samo nasumično čistiti stolove: važno je razumjeti šta se čisti i kako to može ispasti.
5) Pokrenuo zahtjev za kreiranje indeksa, koji je sačuvan u fajlu.
6) Prebacio bazu podataka u jednokorisnički način rada i pokrenuo dbcc checkdb - ovaj put nije bilo generiranih grešaka.
7) Vratio bazu u režim za jednog korisnika.
To je to... problem je prevaziđen. Pa, još u 1C sam pokrenuo „Testiranje i ispravljanje“, i tu je sve prošlo u redu, prestao sam da se žalim na nejedinstveni indeks.

3. Ako nejedinstvenost leži u datumima sa nultim vrijednostima, tada se problem rješava kreiranjem baze podataka s parametrom pomaka jednakim 2000.

1. Ako je problem učitavanje baze podataka, tada:
1.1. Ako učitavate (koristeći dt-datoteku) u bazu podataka MS SQL Servera, tada prilikom kreiranja baze podataka prije učitavanja navedite pomak datuma - 2000.
Ako je baza podataka već kreirana sa pomakom 0, onda kreirajte novu sa 2000.

1.2. Ako je moguće raditi sa bazom podataka u verziji datoteke, onda izvršite Testiranje i ispravku, kao i Konfiguracija - Provjera konfiguracije - Provjera logičkog integriteta konfiguracije + Traženje neispravnih veza.

1.3. Ako ne postoji verzija datoteke, pokušajte učitati iz DT-a u verziju klijent-poslužitelj s DB2 (koja je manje zahtjevna za jedinstvenost), a zatim izvršite testiranje i ispravku, kao i konfiguraciju - provjerite konfiguraciju - provjerite logički integritet konfiguracije + Traži nevažeće reference.

1.4. Da biste lokalizirali problem, možete odrediti podatke objekta čije učitavanje nije uspjelo. Da biste to učinili, morate omogućiti praćenje u uslužnom programu Profiler tokom pokretanja ili omogućiti snimanje u DBMSSQL i EXCP evidenciji događaja procesa.

2. Ako se problem nejedinstvenosti pojavi dok korisnici rade:

2.1. Pronađite problematičan zahtjev koristeći metodu iz paragrafa 1.4.

2.1.2. Ponekad dođe do greške prilikom izvršavanja upita, na primjer:

Ova greška nastaje zbog činjenice da u modulu registra akumulacije „Radno vrijeme zaposlenih u organizacijama“ u proceduri „Preračuni registra“ u zahtjevu nije uključena servisna riječ „DRUGAČIJE“.
Kod 1C v 8.x tj. trebao bi biti:
Zahtjev = Novi zahtjev(
"IZABIR RAZNO
| Basic.Individual,
. . . . .
U najnovijim izdanjima ZUP-a i UPP-a greška se ne javlja, jer piše "DRUGAČIJE".

2.2. Nakon pronalaska problematičnog indeksa iz prethodnog paragrafa, potrebno je pronaći nejedinstveni zapis.
2.2.1. "Fish" skripta za identifikaciju nejedinstvenih zapisa pomoću SQL-a:
SQL kod S_odaberi COUNT(*) Brojač,<перечисление всех полей соответствующего индекса>od<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
IMAJUĆI Brojač > 1

2.2.2 Primjer. Indeks u grešci se zove "_Document140_VT1385_IntKeyIndNG".
Lista polja tabele:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_RT_, _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22f226 _Fld22f226 _RTRef, _Fld22261_RRRef
Prije nego što izvršite proceduru u nastavku, napravite sigurnosnu kopiju vaše baze podataka.
Pokrenite u MS SQL Server Query Analyzeru:
SQL kod S_odaberi broj(*), _Document140_IDRRef, _KeyField
iz_Dokumenta140_VT1385
grupirati po _Document140_IDRRef, _KeyField
imaju broj (*) > 1
Koristite ga da saznate vrijednosti stupaca _Document140_IDRRef, _KeyField, duplih zapisa (id, ključ).

Koristeći zahtjev:
SQL kod S_elect *
iz_Dokumenta140_VT1385
ili _Document140_IDRRef = id2 i _KeyField = ključ2 ili ...
pogledajte vrijednosti ostalih stupaca duplikata unosa.
Ako oba unosa imaju značajne vrijednosti i vrijednosti su različite, promijenite vrijednost _KeyField da bude jedinstvena. Da biste to učinili, odredite maksimalnu zauzetu vrijednost _KeyField (keymax):
SQL kod S_elect max(_KeyField)
iz_Dokumenta140_VT1385
gdje je _Document140_IDRRef = id1
Zamijenite vrijednost _KeyField u jednom od duplikata unosa ispravnim:
Ažuriranje SQL koda _Document140_VT1385
postavite _KeyField = keymax + 1
Ovdje _LineNo1386 = je dodatni uvjet koji vam omogućava da odaberete jedan od dva ponavljanja zapisa.

Ako jedan (ili oba) duplikat unosa ima očigledno pogrešno značenje, onda ga treba ukloniti:
Brisanje SQL koda iz _Document140_VT1385
gdje je _Document140_IDRRef = id1 i _LineNo1386 = lineno1
Ako dupli unosi imaju iste vrijednosti u svim stupcima, onda morate ostaviti jedan od njih:
SQL kod S_odaberi različit *
u #tmp1
iz_Dokumenta140_VT1385
gdje je _Document140_IDRRef = id1 i _KeyField = ključ1

Izbriši iz _Document140_VT1385
gdje je _Document140_IDRRef = id1 i _KeyField = ključ1

I_umetnuti u _Document140_VT1385
Odaberite #tmp1

D_rop tablica #tmp1

Opisani postupak se mora izvršiti za svaki par duplikata zapisa.

2.2.3. Drugi primjer:
SQL kod S_odaberi COUNT(*) AS Izraz2, _IDRRef AS Izraz1, _Opis
IZ _Reference8_
GROUP BY _IDRRef, _Description
IMATI (BROJ(*) > 1)

2.3.4 Primjer određivanja nejedinstvenih zapisa korištenjem 1C:Enterprise upita:
Kod 1C v 8.x SELECT Directory.Link
FROM Directory.Directory AS direktorij
GROUP BY Directory.Link
IMAJUĆI KOLIČINU(*) > 1

Recenzije