3,0 60,59 chyba pri vkladaní nejedinečnej hodnoty. Uskutočnil sa pokus o vloženie nejedinečnej hodnoty do jedinečného indexu. Čo je index

Dostali ste správu obsahujúcu tieto riadky:
Poskytovateľ Microsoft OLE DB pre SQL Server: CREATE UNIQUE INDEX bol ukončený, pretože sa našiel duplicitný kľúč pre ID indexu
alebo
Nie je možné I_vložiť duplicitný kľúčový riadok v objekte
alebo
Uskutočnil sa pokus o vloženie nejedinečnej hodnoty do jedinečného indexu.

Možnosti riešenia:

1. V SQL Server managment studio fyzicky zničíme chybný index (v mojom prípade to bol index v tabuľke súčtov účtovného registra). V 1C budeme distribuovať chybné dokumenty. V testovacom a korekčnom režime zaškrtnite políčka pre reindexáciu tabuľky + prepočet súčtov. 1C znova vytvorí index bez chyby. Vykonávame predtým neúspešné dokumenty.

2. 1) Pomocou Management Studio 2005 som vygeneroval skript na vytvorenie indexu, ktorý bol chybný, a uložil som ho do súboru.
2) Manuálne zabitie indexu jamb z tabuľky _AccumRgTn19455
3) Spustil som požiadavku ako
SQL kód S_elect count(*), index_fields
OD AccumRgTn19455
GROUP BY index_field
MAJÚCI počet(*)>1
Po zabití indexu som mal zobrazených 15 duplicitných záznamov, hoci pred krokom 2 dotaz nevrátil nič.
4) Prešiel som všetky záznamy a ručne vyčistil duplikáty. V skutočnosti som tiež použil spracovanie „Štruktúra prehľadu“, aby som pochopil, s čím mám do činenia. Ukázalo sa, že v tabuľke _AccumRgTn19455 je uložený akumulačný register „Výstup produktu (daňové účtovníctvo)“. Pohral som sa aj s dotazmi sql, identifikoval som 15 nejedinečných dokumentov a po dokončení všetkých akcií som skontroloval v 1C, že tieto dokumenty boli spracované normálne, bez chýb. Samozrejme, stoly by ste nemali čistiť len náhodne: je dôležité pochopiť, čo sa čistí a ako to môže dopadnúť.
5) Spustená požiadavka na vytvorenie indexu, ktorý bol uložený do súboru.
6) Prepnutie databázy do režimu pre jedného používateľa a spustenie dbcc checkdb - tentoraz sa nevygenerovali žiadne chyby.
7) Prepnutie základne späť do režimu pre jedného používateľa.
To je všetko... problém je prekonaný. No, späť v 1C som spustil „Testovanie a opravy“, aj tam išlo všetko v poriadku, prestal som sa sťažovať na nejedinečný index.

3. Ak nejedinečnosť spočíva v dátumoch s nulovými hodnotami, potom sa problém vyrieši vytvorením databázy s parametrom offset rovným 2000.

1. Ak je problémom načítanie databázy, potom:
1.1. Ak načítavate (pomocou dt súboru) do databázy MS SQL Server, tak pri vytváraní databázy pred načítaním zadajte posun dátumu - 2000.
Ak už bola databáza vytvorená s posunom 0, vytvorte novú s 2000.

1.2. Ak je možné pracovať s databázou vo verzii súboru, tak vykonajte Testovanie a Korekciu, ako aj Konfiguráciu - Kontrola konfigurácie - Kontrola logickej integrity konfigurácie + Hľadanie nesprávnych odkazov.

1.3. Ak neexistuje žiadna verzia súboru, skúste načítať z DT do verzie klient-server s DB2 (ktorá je menej náročná na jedinečnosť) a potom vykonajte Test a opravu, ako aj Konfiguráciu - Overenie konfigurácie - Kontrola logickej integrity konfigurácie + Hľadať neplatné referencie.

1.4. Ak chcete problém lokalizovať, môžete určiť údaje objektu, ktorého načítanie zlyhalo. Ak to chcete urobiť, musíte povoliť sledovanie v nástroji Profiler počas zavádzania alebo povoliť zaznamenávanie v protokole udalostí procesov DBMSSQL a EXCP.

2. Ak sa problém nejedinečnosti vyskytne počas práce používateľov:

2.1. Nájdite problematickú požiadavku pomocou metódy v odseku 1.4.

2.1.2. Niekedy sa pri vykonávaní dotazov vyskytne chyba, napríklad:

Táto chyba vzniká z toho dôvodu, že v module evidencie akumulácie „Pracovný čas zamestnancov organizácií“ v procedúre „Prepočty evidencie“ nie je v požiadavke zahrnuté obslužné slovo „INNÉ“.
Kód 1C v 8.x T.j. by mala byť:
Žiadosť = Nová požiadavka(
"VYBERTE RÔZNE
| Základné. Individuálne,
. . . . .
V najnovších vydaniach ZUP a UPP sa chyba nevyskytuje, pretože je tam napísané „INNÉ“.

2.2. Po nájdení problematického indexu z predchádzajúceho odseku musíte nájsť nejedinečný záznam.
2.2.1. Skript "Fish" na identifikáciu nejedinečných záznamov pomocou SQL:
SQL kód S_elect COUNT(*) počítadlo,<перечисление всех полей соответствующего индекса>od om<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
MAJÚ počítadlo > 1

2.2.2 Príklad. Index v chybe sa nazýva "_Document140_VT1385_IntKeyIndNG".
Zoznam polí tabuľky:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef,_RTld_1393 TYPE_Fld11393 RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22ld2,260_Fld22f22_F RTref, _Fld22261_RRRef
Pred vykonaním nižšie uvedeného postupu si zálohujte databázu.
Spustite v MS SQL Server Query Analyzer:
Kód SQL S_elect count(*), _Document140_IDRRef, _KeyField
z dokumentu _Document140_VT1385
skupina podľa _Document140_IDRRef, _KeyField
s počtom (*) > 1
Použite ho na zistenie hodnôt stĺpcov _Document140_IDRRef, _KeyField, duplicitné záznamy (id, kľúč).

Pomocou žiadosti:
SQL kód S_elect *
z dokumentu _Document140_VT1385
kde _Document140_IDRRef = id1 a _KeyField = kľúč1 alebo _Document140_IDRRef = id2 a _KeyField = kľúč2 alebo ...
pozrite sa na hodnoty ostatných stĺpcov duplicitných záznamov.
Ak majú obe položky zmysluplné hodnoty a hodnoty sa líšia, zmeňte hodnotu _KeyField tak, aby bola jedinečná. Ak to chcete urobiť, určite maximálnu obsadenú hodnotu _KeyField (keymax):
SQL kód S_elect max(_KeyField)
z dokumentu _Document140_VT1385
kde je _Document140_IDRRef = id1
Nahraďte hodnotu _KeyField v jednom z duplicitných záznamov správnym:
Aktualizovaný kód SQL zhltol _Document140_VT1385
nastavte _KeyField = keymax + 1

Tu je _LineNo1386 = dodatočná podmienka, ktorá vám umožňuje vybrať jeden z dvoch opakujúcich sa záznamov.

Ak má jeden (alebo oba) z duplicitných záznamov zjavne nesprávny význam, mal by sa odstrániť:
Odstránenie kódu SQL z _Document140_VT1385
kde _Document140_IDRRef = id1 a _LineNo1386 = lineno1
Ak majú duplicitné položky rovnaké hodnoty vo všetkých stĺpcoch, musíte jeden z nich ponechať:
SQL kód S_elect odlišný *
do #tmp1
z_dokumentu140_VT1385

Odstrániť z _Dokument140_VT1385
kde _Document140_IDRRef = id1 a _KeyField = kľúč1

Vložím do _Document140_VT1385
S_select #tmp1

Tabuľka D_rop #tmp1

Opísaný postup sa musí vykonať pre každý pár duplicitných záznamov.

2.2.3. Druhý príklad:
Kód SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
Z _Referencie8_
GROUP BY _IDRRef, _Description
HAVING (POČET(*) > 1)

2.3.4 Príklad určenia nejedinečných záznamov pomocou dotazu 1C:Enterprise:
Kód 1C v 8.x SELECT Directory.Link
FROM Directory.Directory AS Adresár
GROUP BY Directory.Link
MAJÚCI MNOŽSTVO (*) > 1

Informácie prevzaté zo stránky

Možnosti riešenia:

2. 1) Pomocou Management Studio 2005 som vygeneroval skript na vytvorenie indexu, ktorý bol chybný, a uložil som ho do súboru.
2) Manuálne zabitie indexu jamb z tabuľky _AccumRgTn19455
3) Spustil som požiadavku ako
SQL kód S_elect count(*), index_fields
OD AccumRgTn19455
GROUP BY index_field
MAJÚCI počet(*)>1
Po zabití indexu som mal zobrazených 15 duplicitných záznamov, hoci pred krokom 2 dotaz nevrátil nič.
4) Prešiel som všetky záznamy a ručne vyčistil duplikáty. V skutočnosti som tiež použil spracovanie „Štruktúra prehľadu“, aby som pochopil, s čím mám do činenia. Ukázalo sa, že v tabuľke _AccumRgTn19455 je uložený akumulačný register „Výstup produktu (daňové účtovníctvo)“. Tiež som sa pohral s dotazmi sql, identifikoval som 15 nejedinečných dokumentov a po dokončení všetkých akcií som skontroloval v 1C, že tieto dokumenty boli spracované normálne, bez chýb. Samozrejme, stoly by ste nemali čistiť len náhodne: je dôležité pochopiť, čo sa čistí a ako to môže dopadnúť.
5) Spustená požiadavka na vytvorenie indexu, ktorý bol uložený do súboru.
6) Prepnutie databázy do režimu pre jedného používateľa a spustenie dbcc checkdb - tentoraz sa nevygenerovali žiadne chyby.
7) Prepnutie základne späť do režimu pre jedného používateľa.
To je všetko... problém je prekonaný. No, späť v 1C som spustil „Testovanie a korekcia“, aj tam išlo všetko v poriadku, prestal som sa sťažovať na nejedinečný index.

3. Ak nejedinečnosť spočíva v dátumoch s nulovými hodnotami, potom sa problém vyrieši vytvorením databázy s parametrom offsetu rovným 2000.

1.3. Ak neexistuje verzia súboru, skúste načítať z DT do verzie klient-server s DB2 (ktorá je menej náročná na jedinečnosť) a potom vykonajte Test a opravu, ako aj Konfiguráciu - Overenie konfigurácie - Kontrola logickej integrity konfigurácie + Hľadať neplatné referencie.

1.4. Ak chcete problém lokalizovať, môžete určiť údaje objektu, ktorého načítanie zlyhalo. Ak to chcete urobiť, musíte povoliť sledovanie v obslužnom programe Profiler počas zavádzania alebo povoliť záznam v protokole udalostí procesov DBMSSQL a EXCP.

2. Ak sa problém nejedinečnosti vyskytne počas práce používateľov:

2.1. Nájdite problematickú požiadavku pomocou metódy v odseku 1.4.

2.1.2. Niekedy sa vyskytne chyba pri vykonávaní dotazov, napríklad:

2.2. Po nájdení problematického indexu z predchádzajúceho odseku musíte nájsť nejedinečný záznam.
2.2.1. Skript "Fish" na identifikáciu nejedinečných záznamov pomocou SQL:
SQL kód S_elect COUNT(*) Počítadlo,<перечисление всех полей соответствующего индекса>od<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
MAJÚ počítadlo > 1

2.2.2 Príklad. Index v chybe sa nazýva "_Document140_VT1385_IntKeyIndNG".
Zoznam polí tabuľky:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef,_RTld_1393 TYPE_Fld11393 RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22ld2,260_Fld22f22_F RTref, _Fld22261_RRRef
Pred vykonaním nižšie uvedeného postupu si zálohujte databázu.
Spustite v MS SQL Server Query Analyzer:
Kód SQL S_elect count(*), _Document140_IDRRef, _KeyField
z_dokumentu140_VT1385
skupina podľa _Document140_IDRRef, _KeyField
s počtom (*) > 1
Použite ho na zistenie hodnôt stĺpcov _Document140_IDRRef, _KeyField, duplicitné záznamy (id, kľúč).

Pomocou žiadosti:
SQL kód S_elect *
z_dokumentu140_VT1385
alebo _Document140_IDRRef = id2 a _KeyField = kľúč2 alebo ...
pozrite sa na hodnoty ostatných stĺpcov duplicitných záznamov.
Ak majú obe položky zmysluplné hodnoty a hodnoty sa líšia, zmeňte hodnotu _KeyField tak, aby bola jedinečná. Ak to chcete urobiť, určite maximálnu obsadenú hodnotu _KeyField (keymax):
SQL kód S_elect max(_KeyField)
z_dokumentu140_VT1385
kde _Document140_IDRRef = id1
Nahraďte hodnotu _KeyField v jednom z duplicitných záznamov správnym:
Aktualizácia kódu SQL _Document140_VT1385
nastavte _KeyField = keymax + 1
Tu je _LineNo1386 = dodatočná podmienka, ktorá vám umožňuje vybrať jeden z dvoch opakujúcich sa záznamov.

Odstrániť z _Dokument140_VT1385
kde _Document140_IDRRef = id1 a _KeyField = kľúč1

Vložím do _Document140_VT1385
S_select #tmp1

Tabuľka D_rop #tmp1

Opísaný postup sa musí vykonať pre každý pár duplicitných záznamov.

2.2.3. Druhý príklad:
Kód SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
Z _Referencie8_
GROUP BY _IDRRef, _Description
HAVING (POČET(*) > 1)

Tento článok popisuje, čo robiť, ak pri práci s 1C:Enterprise 8.1 narazíte na správu obsahujúcu riadky:

Do objektu nie je možné vložiť duplicitný riadok kľúča

Uskutočnil sa pokus o vloženie nejedinečnej hodnoty do jedinečného indexu.

čo je index?

Indexy sú štruktúra, ktorá umožňuje rýchly prístup k riadkom v tabuľke na základe hodnôt jedného alebo viacerých jej stĺpcov.
Index obsahuje kľúče vytvorené z jedného alebo viacerých stĺpcov tabuľky alebo zobrazenia a ukazovatele, ktoré mapujú na miesto, kde sú uložené špecifikované údaje.
Indexy znižujú množstvo údajov, ktoré sa musia prečítať, aby sa vrátila sada výsledkov.

Hoci je index spojený s konkrétnym stĺpcom (alebo stĺpcami) tabuľky, stále je to samostatný databázový objekt.

Indexy tabuliek v databáze 1C:Enterprise sa vytvárajú implicitne pri vytváraní konfiguračných objektov, ako aj pri určitých nastaveniach konfiguračných objektov.

Fyzická podstata indexov v MS SQL Server 2005.

Fyzicky sú dáta uložené na 8Kb stránkach. Ihneď po vytvorení, zatiaľ čo tabuľka nemá indexy, tabuľka vyzerá ako hromada údajov. Záznamy nemajú žiadne konkrétne poradie ukladania.
Keď chcete získať prístup k údajom, SQL Server vyrobí skenovanie tabuľky(skenovanie tabuľky). SQL Server prehľadá celú tabuľku, aby našiel záznamy, ktoré hľadá.
Odtiaľ sú jasné základné funkcie indexov:
— zvýšenie rýchlosti prístupu k údajom,
— podpora jedinečnosti údajov.

Napriek svojim výhodám majú indexy aj množstvo nevýhod. Prvým sú indexy zaberajú ďalšie miesto na disku a v RAM. Zakaždým, keď vytvoríte index, uložíte kľúče v zostupnom alebo vzostupnom poradí, ktoré môže mať viacúrovňovú štruktúru. A čím väčší/dlhší kľúč, tým väčšia veľkosť indexu. Druhá nevýhoda je operácie sa spomaľujú vkladanie, aktualizácia a mazanie záznamov.
V prostredí MS SQL Server 2005 je implementovaných niekoľko typov indexov:

nezhlukované indexy;
zoskupené (alebo zoskupené) indexy;
jedinečné indexy;
indexy so zahrnutými stĺpcami
indexované zobrazenia
plné znenie

Jedinečný index

Jedinečnosť hodnôt v indexovanom stĺpci je zaručená jedinečnými indexmi. Ak sú prítomné, server vám nedovolí vložiť novú hodnotu alebo zmeniť existujúcu hodnotu tak, že v dôsledku tejto operácie sa v stĺpci objavia dve rovnaké hodnoty.
Jedinečný index je druh doplnku a môže byť implementovaný pre klastrované aj neklastrované indexy. Jedna tabuľka môže mať jeden jedinečný klastrovaný index a mnoho jedinečných nezhlukovaných indexov.
Jedinečné indexy by sa mali definovať iba vtedy, keď je to skutočne potrebné. Ak chcete zabezpečiť integritu údajov v stĺpci, môžete namiesto použitia jedinečných indexov definovať obmedzenie integrity UNIQUE alebo PRIMARY KEY. Ich používanie výlučne na zabezpečenie integrity údajov je plytvaním databázovým priestorom. Okrem toho sa čas CPU vynakladá aj na ich údržbu.

1C:Enterprise 8.1, počnúc verziou 8.1, aktívne používa zoskupené jedinečné indexy. To znamená, že pri konverzii z verzie 8.0 alebo migrácii z verzie 8.1.7 sa môže zobraziť nejedinečná chyba indexu.

Ak nejedinečnosť spočíva v dátumoch s nulovými hodnotami, potom je problém vyriešený vytvorením databázy s parametrom offsetu rovným 2000.

Čo robiť?

1. Ak je problémom načítanie databázy, potom:

1.1. Ak načítavate (pomocou súboru dt) do databázy MS SQL Server, potom pri vytváraní databázy pred načítaním zadajte posun dátumu - 2000.

Ak už bola databáza vytvorená s posunom 0, vytvorte novú s 2000.

1.4. Ak chcete problém lokalizovať, môžete určiť údaje objektu, ktorého načítanie zlyhalo. Ak to chcete urobiť, musíte povoliť sledovanie v nástroji Profiler počas zavádzania alebo povoliť záznam v protokole technologických udalostí DBMSSQL a EXCP.

1.5. Ak je uzol (výmenné plány) dostupný, vykonajte výmenu. Pred výmenou môžete dodatočne vyplniť aj odsek 2.3.5

2. Ak sa problém nejedinečnosti vyskytne počas práce používateľov:

2.1. Nájdite problematickú požiadavku pomocou metódy v odseku 1.4.

2.1.2. Niekedy sa vyskytne chyba pri vykonávaní dotazov, napríklad:

Tie. by mala byť:

Žiadosť = Nová požiadavka(
"VYBERTE RÔZNE
| Základné. Individuálne,

V najnovších vydaniach ZUP a UPP sa chyba nevyskytuje, pretože hovorí „INNÉ“.

2.2. Po nájdení problematického indexu z predchádzajúceho odseku musíte nájsť nejedinečný záznam.

2.2.1. Skript "Fish" na identifikáciu nejedinečných záznamov pomocou SQL:
SELECT COUNT(*) Počítadlo,<перечисление всех полей соответствующего индекса>od<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
MAJÚ počítadlo > 1

2.2.2 Príklad. Index v chybe sa nazýva "_Document140_VT1385_IntKeyIndNG".

Zoznam polí tabuľky:

Dokument140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393RTFldRe1TYPE,9393RTFldRe1TYPE,9 _Fld1394,

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

Pred vykonaním nižšie uvedeného postupu si zálohujte databázu.
Spustite v MS SQL Server Query Analyzer:

vyberte počet (*), _Document140_IDRRef, _KeyField
z_dokumentu140_VT1385
skupina podľa _Document140_IDRRef, _KeyField
s počtom (*) > 1

Použite ho na zistenie hodnôt stĺpcov _Document140_IDRRef, _KeyField, duplicitné záznamy (id, kľúč).

Pomocou žiadosti:

vybrať *
z_dokumentu140_VT1385
alebo _Document140_IDRRef = id2 a _KeyField = kľúč2 alebo …

pozrite sa na hodnoty ostatných stĺpcov duplicitných záznamov.

Ak majú obe položky zmysluplné hodnoty a hodnoty sa líšia, zmeňte hodnotu _KeyField tak, aby bola jedinečná. Za týmto účelom určite maximálnu obsadenú hodnotu _KeyField (keymax):

vybrať max(_KeyField)
z_dokumentu140_VT1385
kde _Document140_IDRRef = id1

Nahraďte hodnotu _KeyField v jednom z duplicitných záznamov správnym:

update_Document140_VT1385
nastavte _KeyField = keymax + 1

Tu je _LineNo1386 = dodatočná podmienka, ktorá vám umožňuje vybrať jeden z dvoch opakujúcich sa záznamov.

Ak má jeden (alebo oba) z duplicitných záznamov zjavne nesprávny význam, mal by sa odstrániť:

kde _Document140_IDRRef = id1 a _LineNo1386 = lineno1

Ak majú duplicitné položky rovnaké hodnoty vo všetkých stĺpcoch, musíte jeden z nich ponechať:

vybrať odlišné *
do #tmp1
z_dokumentu140_VT1385
kde _Document140_IDRRef = id1 a _KeyField = kľúč1

vymazať z _Dokumentu140_VT1385
kde _Document140_IDRRef = id1 a _KeyField = kľúč1

vložiť do _Dokumentu140_VT1385
vyberte #tmp1

vypustiť tabuľku #tmp1

Opísaný postup sa musí vykonať pre každý pár duplicitných záznamov.

2.2.3. Druhý príklad:

SELECT COUNT(*) AS Výraz2, _IDRRef AS Výraz1, _Popis
Z _Referencie8_
GROUP BY _IDRRef, _Description
HAVING (POČET(*) > 1)

2.3.4 Príklad určenia nejedinečných záznamov pomocou dotazu 1C:Enterprise:

alebo pre účtovníctvo

VYBERTE SI
Subquery.Period,
Subquery.Recorder,
<измерения>,
SUM(Subquery.Number of Records) AS Počet záznamov
OD
(VYBERTE si
Samonosné obdobie AS Obdobie,
Samonosný. Registrátor AS Registrátor,
<измерения>,
1 AS Počet záznamov
OD
Účtovný register Samonosný AS Samonosný) AS Poddotaz

GROUP BY
Subquery.Period,
Subquery.Recorder,
<измерения>

MAJÚCE
SUM(Poddotaz.Počet záznamov) > 1

2.3.5 Urobiť index subd nejedinečným. Skriptujte index pomocou Management Studio.

2.3.6 Osobitný prípad pri výmene v RDB. Chyba sa vyskytuje v „pomocných“ tabuľkách spojených s výpočtom súčtov alebo analýzou. Napríklad:

Chyba pri volaní kontextovej metódy (Write): Pokus o vloženie nejedinečnej hodnoty do jedinečného indexu:
Poskytovateľ Microsoft OLE DB pre SQL Server: Nie je možné vložiť duplicitný riadok kľúča do objektu 'dbo._AccntRegED10319' s jedinečným indexom '_Accnt10319_ByPeriod_TRNRN'.
HRESULT=80040E2F, SQLSrvr: Chybový stav=1, závažnosť=E, natívne=2601, riadok=1

V tomto prípade pred načítaním vypnite používanie súčtov, načítajte správu, povoľte používanie súčtov a prepočítajte.