Egyedi index 1c sql. Hiba: Kísérlet nem egyedi érték beszúrására az egyedi indexbe: microsoft sql server

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) C Menedzsment A Studio 2005 létrehozott egy létrehozási szkriptet egy index létrehozásához, amely hibás volt, és elmentette 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 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 a 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, _Fld1392RRef3,9F_lTYd1,9F_lTYd1,3RT , _Fld1393_RR Ref _Fld1394,_Fld1395 _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 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
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

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 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, _Fld1392RRef3,9F_lTYd1,9F_lTYd1,3RT , _Fld1393_RR Ref _Fld1394,_Fld1395 _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
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 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
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ásokban NULL értékkel lesz írva (bár ennek kellene lennie üres érték, nos, 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 be a dt'snik fájlt a fájlbázisba (egy szükségtelen vagy előre előkészített, tiszta, fájlbázis, a konfigurátorban Adminisztráció - Adatbázis betöltése - válassza 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 arra kell kényszeríteni az SQL adatbázist, hogy hozza létre ezeket a NULL "-okat, majd javítsa ki őket a fájl adatbázisban. De nem mondom meg, hogyan kell ezt csinálni.

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 "Testing and Correction"-t, ott is minden rendben ment, abbahagyta a káromkodást egy nem egyedi indexre.

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, _Fld1392RRef3,9F_lTYd1,9F_lTYd1,3RT , _Fld1393_RR Ref _Fld1394,_Fld1395 _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ó