A következő sorokat tartalmazó üzenettel találkoztál:
Microsoft OLE DB Provider for SQL Server: Az EGYEDI INDEX LÉTREHOZÁSA megszakadt, mert ismétlődő kulcs található az indexazonosítóhoz
vagy
Nem lehet duplikált kulcssort beszúrni az objektumba
vagy
Kísérlet történt egy nem egyedi érték beszúrására egy egyedi indexbe.

Megoldási lehetőségek:

1. Az SQL Server Management Studio-ban fizikailag megsemmisítjük a meghibásodott indexet (az én esetemben ez a számviteli nyilvántartás összesítő táblázatának indexe volt). Az 1C-ben a hibás dokumentumokat terjesztjük. Tesztelési és javítási módban jelölje be a táblák újraindexelése + az összegek újraszámítása jelölőnégyzeteket. Az 1C hiba nélkül újra létrehozza az indexet. Korábban meghiúsult dokumentumokat készítünk.

2. 1) A Management Studio 2005 segítségével létrehoztam egy létrehozási szkriptet egy index létrehozásához, amely hibás volt, és elmentettem egy fájlba.
2) Kézzel törölte az indexet a _AccumRgTn19455 táblából
3) Indított egy kérést, mint
SQL kód S_elect count(*), index_fields
AccumRgTn19455-TŐL
GROUP BY index_field
HAVING count(*)>1
Az index leállítása után 15 ismétlődő rekordot jelenítettem meg, bár a 2. lépés előtt a lekérdezés semmit sem adott vissza.
4) Átnéztem az összes rekordot, és manuálisan kitisztítottam a másolatokat. Valójában a "Jelentésstruktúra" feldolgozást is használtam, hogy megértsem, mivel foglalkozom általában. Kiderült, hogy az _AccumRgTn19455 tábla tárolja a „Termékkibocsátás (adóelszámolás)” felhalmozási regisztert. Körbebökdöstem az sql lekérdezéseket is, azonosítottam 15 nem egyedi dokumentumot, és az összes művelet elvégzése után az 1C-ben ellenőriztem, hogy ezek a dokumentumok rendesen, hibamentesen dolgoznak-e. Persze nem érdemes csak úgy véletlenszerűen takarítani az asztalokat: fontos megérteni, hogy mit takarítanak, és mivé válhat.
5) Indított egy lekérdezést egy index létrehozásához, amelyet fájlba mentett.
6) Egyfelhasználós módba kapcsolta az adatbázist, és futtatta a dbcc checkdb-t – ezúttal nem volt hiba.
7) Az alap visszahelyezése egyfelhasználós módba.
Minden... a probléma legyőzve. Nos, még az 1C-ben is elindítottam a "Tesztelést és javítást", ott is minden rendben ment, abbahagyta a nem egyedi indexre való káromkodást.

3. Ha a nem egyediség a tól származó dátumokban rejlik nulla értékek , akkor a probléma 2000 offset paraméterű bázis létrehozásával megoldódik.

1. Ha a probléma az adatbázis betöltése, akkor:
1.1. Ha betölt (dt-fájl segítségével) az MS SQL Server adatbázisba, akkor az adatbázis létrehozásakor a betöltés előtt adja meg a dátumeltolást - 2000.
Ha az alap már létrejött 0 eltolással, akkor hozzon létre egy újat 2000-el.

1.2. Ha lehetséges az adatbázissal a fájl verzióban dolgozni, akkor végezze el a Tesztelés és javítás, valamint a Konfiguráció - Konfiguráció ellenőrzése - A konfiguráció logikai integritásának ellenőrzése + Helytelen hivatkozások keresése.

1.3. Ha nincs fájlváltozat, próbáljon meg betölteni a DT-ből egy DB2 kliens/szerver változatra (amely kevésbé válogatós az egyediség tekintetében), majd futtassa a Teszt és javítás és Konfiguráció - Konfiguráció ellenőrzése - Konfiguráció logikai integritás ellenőrzése + Rossz hivatkozáskereső parancsot.

1.4. A probléma lokalizálásához meghatározhatja annak az objektumnak az adatait, amelynek betöltése nem sikerült. Ehhez engedélyeznie kell a nyomkövetést rendszerindításkor a Profiler segédprogramban, vagy engedélyeznie kell a naplózást a DBMSSQL és EXCP folyamateseménynaplóba.

2. Ha a nem egyediség problémája a felhasználók munkája során jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdés módszerével.

2.1.2. Néha hiba történik a kérések végrehajtása során, például:

Ez a hiba abból adódik, hogy a felhalmozási nyilvántartás „Szervezetek dolgozóinak munkaideje” moduljában a „Nyilvántartási újraszámítások” eljárásban a kérelemben nincs „MÁS” szolgáltatás szó.
Kód 1C v 8.x I.e. kellene:
Request = Új kérés(
"VÁLASSZON MÁST
| Alapvető. Egyéni,
. . . . .
A ZUP és UPP legújabb kiadásaiban a hiba nem jelentkezik, mert. azt írja, hogy "KÜLÖNBÖZŐ".

2.2. Miután megtalálta a problémás indexet az előző bekezdésben, meg kell találnia egy nem egyedi bejegyzést.
2.2.1. "Fish" szkript nem egyedi rekordok meghatározásához SQL használatával:
SQL kód S_elect COUNT(*) számláló,<перечисление всех полей соответствующего индекса>tól től<имя таблицы>
CSOPORTOSÍT<перечисление всех полей соответствующего индекса>
VAN SZÁMLÁLÓ > 1

2.2.2 Példa. A hibában szereplő index neve "_Document140_VT1385_IntKeyIndNG".
A táblázat mezőinek listája:
_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
Az alábbi eljárás végrehajtása előtt tegye meg biztonsági mentés Adatbázis.
MS SQL Server Query Analyzer futtatása:
SQL kód S_elect count(*), _Document140_IDRRef, _KeyField
innen: _Dokumentum140_VT1385
csoportosítás _Document140_IDRRef, _KeyField szerint
amelynek száma (*) > 1
Segítségével megtudhatja a _Document140_IDRRef, _KeyField, ismétlődő rekordok (id, kulcs) oszlopok értékét.

Egy kéréssel:
SQL kód S_elect *
innen: _Dokumentum140_VT1385
vagy _Document140_IDRRef = id2 és _KeyField = kulcs2 vagy ...
nézze meg az ismétlődő bejegyzések többi oszlopának értékét.
Ha mindkét bejegyzésnek van értelmes értéke, és ezek az értékek eltérőek, akkor rögzítse a _KeyField értékét egyedire. Ehhez adja meg a _KeyField(keymax) maximálisan foglalt értékét:
SQL kód S_elect max(_KeyField)
innen: _Dokumentum140_VT1385
ahol _Document140_IDRRef = id1
Cserélje ki a _KeyField értéket az egyik ismétlődő bejegyzésben a megfelelőre:
SQL-kód frissítése _Document140_VT1385
állítsa be a _KeyField = keymax + 1 értéket
Itt a _LineNo1386 = egy további feltétel, amely lehetővé teszi két ismétlődő bejegyzés egyikének kiválasztását.

Ha az ismétlődő bejegyzések egyikének (vagy mindkettőnek) nyilvánvalóan rossz az értéke, akkor azt el kell távolítani:
SQL-kód törlése innen: _Document140_VT1385
ahol _Document140_IDRRef = id1 és _LineNo1386 = lineno1
Ha ismétlődő bejegyzések vannak ugyanazok az értékek az összes oszlopban, akkor az egyiket meg kell hagyni:
SQL kód S_elect different *
a #tmp1-be
innen: _Dokumentum140_VT1385
ahol _Document140_IDRRef = id1 és _KeyField = kulcs1

Törlés innen: _Document140_VT1385
ahol _Document140_IDRRef = id1 és _KeyField = kulcs1

I_beszúrom a _Document140_VT1385-be
S_elect #tmp1

D_rop táblázat #tmp1

A leírt eljárást minden ismétlődő bejegyzéspárnál el kell végezni.

2.2.3. Második példa:
SQL kód S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Referencia8_
GROUP BY _IDRRef, _Description
HAVING (SZÁM(*) > 1)

2.3.4 Példa nem egyedi rekordok meghatározására 1C:Enterprise lekérdezéssel:
Code 1C v 8.x KÉZIKÖNYV KIVÁLASZTÁSA
FROM Directory. Directory AS címtár
CSOPORTOSÍT
MENNYISÉG (*) > 1

Hiba történik, ha egyes objektumok, attribútumok, részkontók NULL értékkel rendelkeznek az adatbázisban, de nem rendelkezhetnek ilyen értékkel. És ez a hiba csak az SQL adatbázisokban jelenik meg. Azok. ha egy ilyen adatbázist kirakunk egy fájlba, akkor ez a hiba nem lesz ott. Mert a fájlbázisnak saját táblája van (összesen 4), az SQL-nek pedig saját. És az SQL-adatbázis kritikusan reagál az ilyen értékekre a táblázataiban.

Ezt a problémát semmilyen (sem külső, sem belső) teszt nem oldja meg egyetlen adatbázisváltozatban sem (SQL vagy fájl), és még az SQL-kezelő _1sp_DBReindex eljárása sem, amely úgy tűnik, hogy átstrukturálja a táblákat az SQL-ben.

Elemezzük a probléma megoldását a Accounting 3.0 PROF-ról a CORP-ra való átállás példáján keresztül. Az átállás után a 68.01-es fióknak új alkontoja van Regisztráció az adóhatóságnál. Ezután az SQL-alapú adatbázisokban az ezt a fiókot használó dokumentumok PROF-verziójában végzett összes létrehozás nem kerül újrahuzalozásra. A fent látható hiba kijön. Mert ez az új alkonto a régi dokumentumokhoz, a feladásokba, NULL értékkel lesz írva (bár legyen Üres érték, hát, vagy valahogy az adóhatóság).

A hiba megoldásához el kell távolítania a NULL értékeket ott, ahol nem kellene. Ebben az esetben azokban a dokumentumokban, ahol a Regisztrációban adóhatóság alkonto használatos. Ezt úgy teheti meg, hogy ír egy feldolgozást, amely a NULL-t üres értékre cseréli (a kész feldolgozás letölthető ebből a cikkből). Végezzen feldolgozást, tk. az alkonto értékének manuális megváltoztatására tett kísérlet a dokumentum-feladásokban ugyanilyen hibához vezet.

Feldolgozás a NULL "-ek cseréjéhez az összes alkapcsolatban. A Regisztráció az adóhatóságnál letölthető ebből a cikkből, alább.

DE nem fog működni a NULL cseréje az SQL adatbázisban, ugyanaz a hiba jön létre a feldolgozás során. Ezért ezt kell tennie:

1. Töltsd fel a már működő, CORP-verzióra lefordított SQL adatbázist a dt'snik-be (a konfigurátor Adminisztráció - Adatbázis feltöltése -ban válassza ki, hogy hova szeretné feltölteni az adatbázist *.dt fájl formájában)

2. Töltsd fel a dt-ket a fájlbázisba (egy szükségtelen vagy előre elkészített, tiszta, fájl adatbázisban, a konfigurátor Adminisztráció - Adatbázis betöltése -ben válaszd ki a korábban ki nem töltött dt-ket)

3. Hajtsa végre a feldolgozást a fájlbázisban (nem lesz hiba, és minden NULL helyesen lesz cserélve) (a feldolgozás végrehajtásának leírása alább olvasható)

5. Most éppen ellenkezőleg, töltse ki a dt-ket a fájlbázisból, és töltse be az SQL adatbázisba. Mostantól a feldolgozott dokumentumok feladásakor nem lesz hiba.

Az ebből a cikkből történő feldolgozás megkeresi a megadott időszakra vonatkozó összes olyan dokumentumot, amelyben a tranzakciókban megjelenik a RegisterIn Tax Authority alkapcsolattartó (amely a CORP verzióban jelenik meg), amelynek NULL értéke van. És lecseréli ezt az értéket egy üres értékre.

A feldolgozásnál meg kell adni az időszakot, amelyre a dokumentumokat feldolgozni kell (lehetséges a teljes nyilvántartási időszakra, amíg a nyilvántartást az adatbázisban tárolják), majd kattintson a "Kitöltés" gombra. táblázatos rész". Ezt követően bejelölheti a jelölőnégyzeteket, hogy mely dokumentumokat kell feldolgozni (összes kijelölhető), és kattintson a „Feldolgozás végrehajtása” gombra.

Ennek megfelelően, ha valakinél ugyanez a hiba, de NEM CORP-ra váltás után, hanem például csere, valamilyen adat betöltése, valamilyen feldolgozás elvégzése, stb. Ezután meg kell határozni, hogy egy adott dokumentumban/könyvtárban hol lett hozzárendelve a NULL érték, és hasonló módon, de saját feldolgozásával, de a fent leírt sorrendben távolítsa el ezt a NULL értéket. Ne feledje, hogy a NULL lehet, mint a dokumentum-feladásoknál, beleértve. nem csak könyvelés, hanem valahol bizonylat/könyvtár formájában, néhány részletben, de ebben az esetben valószínűleg meg sem nyílik.

Továbbá, ha ez a hiba jelentkezett egy dokumentum feladásakor, miután átvitte a Bukh CORP fájlbázist az SQL-be ​​(és az adatbázis eredetileg PROF volt), ez azt jelenti, hogy a PRO verzióban létrehozott dokumentumok mostantól a Regisztrációs adóban is szerepelnek. A jogosultság alkontolja a NULL értéket, és az SQL adatbázis ezt nem fogadja el. És az adatbázis SQL-ben történő betöltésekor egy ilyen hiba jelenik meg. Itt valójában nem lesznek NULL értékek a fájlbázisban, de az SQL pontosan ilyen értékeket tölt be a tábláiba. Ezért itt kényszeríteni kell SQL adatbázis hozza létre ezeket a NULL-okat, majd javítsa ki őket a fájlbázisban. De nem mondom meg, hogyan kell ezt csinálni.

Ez a cikk leírja, mi a teendő, ha az 1C:Enterprise 8.1-el dolgozva a következő sorokat tartalmazó üzenettel találkozik:

Nem lehet duplikált kulcssort beszúrni az objektumba

Kísérlet történt egy nem egyedi érték beszúrására egy egyedi indexbe.

Mi az index?

Az indexek egy olyan struktúra, amely lehetővé teszi a táblázat sorainak gyors elérését egy vagy több oszlopának értékei alapján.
Az index egy táblázat vagy nézet egy vagy több oszlopából felépített kulcsokat és mutatókat tartalmaz, amelyek leképezik a megadott adatok tárolási helyét.
Az indexek csökkentik a beolvasandó adatok mennyiségét az eredményhalmaz visszaadásához.

Bár egy index egy tábla egy adott oszlopához (oszlopaihoz) van társítva, továbbra is önálló adatbázis-objektum.

Az 1C:Enterprise adatbázis táblaindexei implicit módon jönnek létre konfigurációs objektumok létrehozásakor, valamint a konfigurációs objektumok bizonyos beállításaival.

Az indexek fizikai lényege az MS SQL Server 2005-ben.

A fizikai adatok tárolásra kerülnek 8 Kb-os oldalakon. Közvetlenül a létrehozás után, bár a táblának nincsenek indexei, a tábla adathalomnak tűnik. A rekordoknak nincs meghatározott tárolási sorrendje.
Ha szeretne hozzáférni az adatokhoz, az SQL Server előállítja táblázat szkennelés(tábla szkennelés). Az SQL Server átvizsgálja a teljes táblát, hogy megtalálja a keresett rekordokat.
Innentől világossá válik alapvető funkciókat indexek:
- az adatelérés sebességének növelése,
- az adatok egyediségének támogatása.

Az előnyök ellenére az indexeknek számos hátránya is van. Az első az indexek. elfoglalni pótágy lemezenés be véletlen hozzáférésű memória. Minden alkalommal, amikor létrehoz egy indexet, a kulcsokat növekvő vagy csökkenő sorrendben tárolja, amelyek rétegezhetők. És minél nagyobb/hosszabb a kulcs, annál nagyobb az index mérete. A második hátrány az a műveletek lelassulnak rekordok beszúrása, frissítése és törlése.
Az MS SQL Server 2005 környezetben többféle indexet implementálnak:

• nem klaszterezett indexek;
• fürtözött (vagy fürtözött) indexek;
• egyedi indexek;
• indexek tartalmazott oszlopokkal
• indexelt nézetek
• teljes szöveg

Egyedi index

Az indexelt oszlopban lévő értékek egyediségét egyedi indexek garantálják. Ha jelen vannak, a szerver nem engedi új beszúrását vagy módosítását meglévő értékúgy, hogy a művelet eredményeként két azonos érték jelenjen meg az oszlopban.
Az egyedi index egyfajta kiegészítő, és fürtözött és nem fürtözött indexekhez is megvalósítható. Egy táblának egy egyedi fürtözött és több egyedi, nem fürtözött indexe lehet.
Egyedi indexeket csak akkor szabad megadni, ha feltétlenül szükséges. Egy oszlop adatintegritásának biztosítása érdekében egyedi indexek használata helyett meghatározhat egy EGYEDI vagy ELSŐDLEGES KULCS integritási megszorítást. Ha csak az adatok sértetlenségének biztosítására használja őket, az helypazarlás az adatbázisban. Ráadásul a CPU-időt a karbantartásukra is fordítják.

Az 1C:Enterprise 8.1 a 8.1-es verziótól kezdve aktívan használ fürtözött egyedi indexeket. Ez azt jelenti, hogy a 8.0-s verzióról történő konvertáláskor vagy a 8.1.7-ről való átálláskor nem egyedi indexhibát kaphat.

Ha a nem egyediség nulla értékű dátumokban rejlik, akkor a probléma megoldása egy bázis létrehozásával 2000-es offset paraméterrel.

Mit kell tenni?

1. Ha a probléma az adatbázis betöltése, akkor:

1.1. Ha betölt (dt-fájl segítségével) az MS SQL Server adatbázisba, akkor az adatbázis létrehozásakor a betöltés előtt adja meg a dátumeltolást - 2000.

Ha az alap már létrejött 0 eltolással, akkor hozzon létre egy újat 2000-el.

1.2. Ha lehetséges az adatbázissal a fájl verzióban dolgozni, akkor végezze el a Tesztelés és javítás, valamint a Konfiguráció - Konfiguráció ellenőrzése - A konfiguráció logikai integritásának ellenőrzése + Helytelen hivatkozások keresése.

1.3. Ha nincs fájlváltozat, próbáljon meg betölteni a DT-ről egy DB2 kliens/szerver változatra (amely kevésbé válogatós az egyediség tekintetében), majd futtassa a Teszt és javítás és Konfiguráció - Konfiguráció ellenőrzése - Konfiguráció ellenőrzése Logikai integritás + Rossz hivatkozások keresése parancsot.

1.4. A probléma lokalizálásához meghatározhatja annak az objektumnak az adatait, amelynek betöltése nem sikerült. Ehhez engedélyeznie kell a nyomkövetést rendszerindításkor a Profiler segédprogramban, vagy engedélyeznie kell a naplózást a DBMSSQL és EXCP folyamateseménynaplóba.

1.5. Ha elérhető csomópont (cseretervek), akkor hajtsa végre a cserét. Ezenkívül a 2.3.5. bekezdést is végrehajthatja a csere előtt

2. Ha a nem egyediség problémája a felhasználók munkája során jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdés módszerével.

2.1.2. Néha hiba történik a kérések végrehajtása során, például:

Ez a hiba abból adódik, hogy a felhalmozási nyilvántartás „Szervezetek dolgozóinak munkaideje” moduljában az „Újraszámítások nyilvántartása” eljárásban a kérelemben a „MÁS” szolgáltatás szó nem szerepel.

Azok. kellene:

Request = Új kérés(
"VÁLASSZON MÁST
| Alapvető. Egyéni,

A ZUP és UPP legújabb kiadásaiban a hiba nem jelentkezik, mert. azt írja MÁS.

2.2. Miután megtalálta a problémás indexet az előző bekezdésben, meg kell találnia egy nem egyedi bejegyzést.

2.2.1. "Fish" szkript nem egyedi rekordok meghatározásához SQL használatával:
SELECT COUNT(*) számláló,<перечисление всех полей соответствующего индекса>tól től<имя таблицы>
CSOPORTOSÍT<перечисление всех полей соответствующего индекса>
VAN SZÁMLÁLÓ > 1

2.2.2 Példa. A hibában szereplő index neve "_Document140_VT1385_IntKeyIndNG".

A táblázat mezőinek listája:

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef, _Fld1392RRef_,RREF_1,392RRef_1,392RRFld1,39FlFl11

Fld1395 _Fld1396RRef _Fld1397 _Fld1398 _Fld1399RRef _Fld22260_TYPE _Fld22260_RTRef

Az alábbi eljárás végrehajtása előtt készítsen biztonsági másolatot az adatbázisáról.
MS SQL Server Query Analyzer futtatása:

válassza ki a count(*), _Document140_IDRRef, _KeyField
innen: _Dokumentum140_VT1385
csoportosítás _Document140_IDRRef, _KeyField szerint
amelynek száma (*) > 1

Segítségével megtudhatja a _Document140_IDRRef, _KeyField, ismétlődő rekordok (id, kulcs) oszlopok értékét.

Egy kéréssel:

válassz *
innen: _Dokumentum140_VT1385
vagy _Document140_IDRRef = id2 és _KeyField = kulcs2 vagy…

nézze meg az ismétlődő bejegyzések többi oszlopának értékét.

Ha mindkét bejegyzésnek van értelmes értéke, és ezek az értékek eltérőek, akkor rögzítse a _KeyField értékét egyedire. Ehhez adja meg a _KeyField(keymax) maximálisan foglalt értékét:

max(_KeyField) kiválasztása
innen: _Dokumentum140_VT1385
ahol _Document140_IDRRef = id1

Cserélje ki a _KeyField értéket az egyik ismétlődő bejegyzésben a megfelelőre:

update_Document140_VT1385
állítsa be a _KeyField = keymax + 1 értéket

Itt a _LineNo1386 = egy további feltétel, amely lehetővé teszi két ismétlődő bejegyzés egyikének kiválasztását.

Ha az ismétlődő bejegyzések egyikének (vagy mindkettőnek) nyilvánvalóan rossz az értéke, akkor azt el kell távolítani:

ahol _Document140_IDRRef = id1 és _LineNo1386 = lineno1

Ha az ismétlődő bejegyzések értéke minden oszlopban azonos, akkor az egyiket meg kell hagyni:

válasszon külön *
a #tmp1-be
innen: _Dokumentum140_VT1385
ahol _Document140_IDRRef = id1 és _KeyField = kulcs1

törölje a _Document140_VT1385-ből
ahol _Document140_IDRRef = id1 és _KeyField = kulcs1

illessze be a _Document140_VT1385-be
válassza a #tmp1 lehetőséget

drop table #tmp1

A leírt eljárást minden ismétlődő bejegyzéspárnál el kell végezni.

2.2.3. Második példa:

SELECT COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Referencia8_
GROUP BY _IDRRef, _Description
HAVING (SZÁM(*) > 1)

2.3.4 Példa nem egyedi rekordok meghatározására 1C:Enterprise lekérdezéssel:

vagy könyvelésre

VÁLASZT
Subquery.Period,
Subquery.Registr,
<измерения>,
SUM(Subquery.Number of Records) AS Rekordok száma
TÓL TŐL
(VÁLASZT
Önfenntartó.Period AS időszak,
Önfenntartó. Regisztrátor AS Regisztrátor,
<измерения>,
1 AS Rekordok száma
TÓL TŐL
Számviteli nyilvántartás Self-supporting AS Self-supporting) AS részlekérdezés

CSOPORTOSÍT
Subquery.Period,
Subquery.Registr,
<измерения>

HAVING
SUM(allekérdezés.Rekordok száma) > 1

2.3.5 A subd index ne legyen egyedi. Írja le az indexet a Management Studio segítségével.

2.3.6 Speciális eset az RDB cseréjében. A hiba az összegek vagy az elemzések kiszámításához kapcsolódó "kiegészítő" táblákra esik. Például:

Hiba a kontextus metódusának hívásakor (írás): Kísérlet nem egyedi érték beszúrására az egyedi indexbe:
Microsoft OLE DB Provider for SQL Server: Nem lehet duplikált kulcssort beszúrni a „dbo._AccntRegED10319” objektumba, egyedi indexszel „_Accnt10319_ByPeriod_TRNRN”.
HRESULT=80040E2F, SQLSrvr: Hibaállapot=1, Súlyosság=E, natív=2601, sor=1

Ebben az esetben a betöltés előtt kapcsolja ki az összegek használatát, töltse le az üzenetet, kapcsolja be az összegek használatát és számolja újra.

A következő sorokat tartalmazó üzenettel találkoztál:
Microsoft OLE DB Provider for SQL Server: Az EGYEDI INDEX LÉTREHOZÁSA megszakadt, mert ismétlődő kulcs található az indexazonosítóhoz
vagy
Nem lehet duplikált kulcssort beszúrni az objektumba
vagy
Kísérlet történt egy nem egyedi érték beszúrására egy egyedi indexbe.

Megoldási lehetőségek:

1. Az SQL Server Management Studio-ban fizikailag megsemmisítjük a meghibásodott indexet (az én esetemben ez a számviteli nyilvántartás összesítő táblázatának indexe volt). Az 1C-ben a hibás dokumentumokat terjesztjük. Tesztelési és javítási módban jelölje be a táblák újraindexelése + az összegek újraszámítása jelölőnégyzeteket. Az 1C hiba nélkül újra létrehozza az indexet. Korábban meghiúsult dokumentumokat készítünk.

2. 1) A Management Studio 2005 segítségével létrehoztam egy létrehozási szkriptet egy index létrehozásához, amely hibás volt, és elmentettem egy fájlba.
2) Kézzel törölte az indexet a _AccumRgTn19455 táblából
3) Indított egy kérést, mint
SQL kód S_elect count(*), index_fields
FR OM AccumRgTn19455
GROUP BY index_field
HAVING count(*)>1
Az index leállítása után 15 ismétlődő rekordot jelenítettem meg, bár a 2. lépés előtt a lekérdezés semmit sem adott vissza.
4) Átnéztem az összes rekordot, és manuálisan kitisztítottam a másolatokat. Valójában a "Jelentésstruktúra" feldolgozást is használtam, hogy megértsem, mivel foglalkozom általában. Kiderült, hogy az _AccumRgTn19455 tábla tárolja a „Termékkibocsátás (adóelszámolás)” felhalmozási regisztert. Körbebökdöstem az sql lekérdezéseket is, azonosítottam 15 nem egyedi dokumentumot, és az összes művelet elvégzése után az 1C-ben ellenőriztem, hogy ezek a dokumentumok rendesen, hibamentesen dolgoznak-e. Persze nem érdemes csak úgy véletlenszerűen takarítani az asztalokat: fontos megérteni, hogy mit takarítanak, és mivé válhat.
5) Indított egy lekérdezést egy index létrehozásához, amelyet fájlba mentett.
6) Egyfelhasználós módba kapcsolta az adatbázist, és futtatta a dbcc checkdb-t – ezúttal nem volt hiba.
7) Az alap visszahelyezése egyfelhasználós módba.
Minden... a probléma legyőzve. Nos, még az 1C-ben is elindítottam a "Tesztelést és javítást", ott is minden rendben ment, abbahagyta a nem egyedi indexre való káromkodást.

3. Ha a nem egyediség nulla értékű dátumokban rejlik, akkor a probléma 2000 offset paraméterű bázis létrehozásával megoldódik.

1. Ha a probléma az adatbázis betöltése, akkor:
1.1. Ha betölt (dt-fájl segítségével) az MS SQL Server adatbázisba, akkor az adatbázis létrehozásakor a betöltés előtt adja meg a dátumeltolást - 2000.
Ha az alap már létrejött 0 eltolással, akkor hozzon létre egy újat 2000-el.

1.2. Ha lehetséges az adatbázissal a fájl verzióban dolgozni, akkor végezze el a Tesztelés és javítás, valamint a Konfiguráció - Konfiguráció ellenőrzése - A konfiguráció logikai integritásának ellenőrzése + Helytelen hivatkozások keresése.

1.3. Ha nincs fájlváltozat, próbáljon meg betölteni a DT-ből egy DB2 kliens/szerver változatra (amely kevésbé válogatós az egyediség tekintetében), majd futtassa a Teszt és javítás és Konfiguráció - Konfiguráció ellenőrzése - Konfiguráció logikai integritás ellenőrzése + Rossz hivatkozáskereső parancsot.

1.4. A probléma lokalizálásához meghatározhatja annak az objektumnak az adatait, amelynek betöltése nem sikerült. Ehhez engedélyeznie kell a nyomkövetést rendszerindításkor a Profiler segédprogramban, vagy engedélyeznie kell a naplózást a DBMSSQL és EXCP folyamateseménynaplóba.

2. Ha a nem egyediség problémája a felhasználók munkája során jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdés módszerével.

2.1.2. Néha hiba történik a kérések végrehajtása során, például:

Ez a hiba abból adódik, hogy a felhalmozási nyilvántartás „Szervezetek dolgozóinak munkaideje” moduljában a „Nyilvántartási újraszámítások” eljárásban a kérelemben nincs „MÁS” szolgáltatás szó.
Kód 1C v 8.x I.e. kellene:
Request = Új kérés(
"VÁLASSZON MÁST
| Alapvető. Egyéni,
. . . . .
A ZUP és UPP legújabb kiadásaiban a hiba nem jelentkezik, mert. azt írja, hogy "KÜLÖNBÖZŐ".

2.2. Miután megtalálta a problémás indexet az előző bekezdésben, meg kell találnia egy nem egyedi bejegyzést.
2.2.1. "Fish" szkript nem egyedi rekordok meghatározásához SQL használatával:
SQL kód S_elect COUNT(*) számláló,<перечисление всех полей соответствующего индекса>tól től<имя таблицы>
CSOPORTOSÍT<перечисление всех полей соответствующего индекса>
VAN SZÁMLÁLÓ > 1

2.2.2 Példa. A hibában szereplő index neve "_Document140_VT1385_IntKeyIndNG".
A táblázat mezőinek listája:
_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
Az alábbi eljárás végrehajtása előtt készítsen biztonsági másolatot az adatbázisáról.
MS SQL Server Query Analyzer futtatása:
SQL kód S_elect count(*), _Document140_IDRRef, _KeyField
forrás: _Document140_VT1385
csoportosítás _Document140_IDRRef, _KeyField szerint
amelynek száma (*) > 1
Segítségével megtudhatja a _Document140_IDRRef, _KeyField, ismétlődő rekordok (id, kulcs) oszlopok értékét.

Egy kéréssel:
SQL kód S_elect *
forrás: _Document140_VT1385
ahol _Document140_IDRRef = id1 és _KeyField = kulcs1 vagy _Document140_IDRRef = id2 és _KeyField = kulcs2 vagy ...
nézze meg az ismétlődő bejegyzések többi oszlopának értékét.
Ha mindkét bejegyzésnek van értelmes értéke, és ezek az értékek eltérőek, akkor rögzítse a _KeyField értékét egyedire. Ehhez adja meg a _KeyField(keymax) maximálisan foglalt értékét:
SQL kód S_elect max(_KeyField)
forrás: _Document140_VT1385
wh ere_Document140_IDRRef=id1
Cserélje ki a _KeyField értéket az egyik ismétlődő bejegyzésben a megfelelőre:
SQL-kód frissítése _Document140_VT1385
állítsa be a _KeyField = keymax + 1 értéket

Itt a _LineNo1386 = egy további feltétel, amely lehetővé teszi két ismétlődő bejegyzés egyikének kiválasztását.

Ha az ismétlődő bejegyzések egyikének (vagy mindkettőnek) nyilvánvalóan rossz az értéke, akkor azt el kell távolítani:
SQL-kód törlése innen: _Document140_VT1385
hol van a _Document140_IDRRef = id1 és a _LineNo1386 = lineno1
Ha az ismétlődő bejegyzések értéke minden oszlopban azonos, akkor az egyiket meg kell hagyni:
SQL kód S_elect different *
a #tmp1-be
innen: _Dokumentum140_VT1385

Törlés innen: _Document140_VT1385
hol van a _Document140_IDRRef = id1 és _KeyField = kulcs1

I_beszúrom a _Document140_VT1385-be
S_elect #tmp1

D_rop táblázat #tmp1

A leírt eljárást minden ismétlődő bejegyzéspárnál el kell végezni.

2.2.3. Második példa:
SQL kód S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Referencia8_
GROUP BY _IDRRef, _Description
HAVING (SZÁM(*) > 1)

2.3.4 Példa nem egyedi rekordok meghatározására 1C:Enterprise lekérdezéssel:
Code 1C v 8.x KÉZIKÖNYV KIVÁLASZTÁSA
FROM Directory. Directory AS címtár
CSOPORTOSÍT
MENNYISÉG (*) > 1

Az oldalról vett információ