Nem egyedi értéket szúr be egy egyedi indexbe. Kísérlet történt egy nem egyedi érték beszúrására egy egyedi indexbe. Mi az index

Ön kapott egy üzenetet, amely a következő sorokat tartalmazza:
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ások:

1. Az SQL Server menedzsment stúdióban fizikailag megsemmisítjük a hibás indexet (az én esetemben a számviteli regiszter összesítő táblázatának indexe volt). 1C-ben kiosztjuk a hibás dokumentumokat. Tesztelési és korrekciós módban jelölje be a táblázat ú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 a jamb indexet a _AccumRgTn19455 táblázatbó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ő rekord jelent meg, bár a 2. lépés előtt a lekérdezés nem adott vissza semmit.
4) Végignéztem az összes bejegyzést, é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. Kiderült, hogy az _AccumRgTn19455 tábla tárolja a „Termékkibocsátás (adóelszámolás)” felhalmozási regisztert. Az sql lekérdezéseken is bíbelődtem, azonosítottam 15 nem egyedi dokumentumot, és az összes művelet elvégzése után az 1C-ben ellenőriztem, hogy ezeket a dokumentumokat rendesen, hiba nélkül dolgozták fel. Természetesen nem szabad véletlenszerűen takarítani az asztalokat: fontos megérteni, hogy mit takarítanak meg, és hogyan lehet az.
5) Indított egy kérést egy index létrehozására, amelyet fájlba mentett.
6) Átkapcsolta az adatbázist egyfelhasználós módba, és elindította a dbcc checkdb-t – ezúttal nem keletkezett hiba.
7) Visszakapcsolta a bázist egyfelhasználós módba.
Ennyi... a probléma leküzdve. Nos, még az 1C-ben elindítottam a „Tesztelés és javítás”-ot, ott is minden rendben ment, nem panaszkodtam a nem egyedi index miatt.

3. Ha a nem egyediség nulla értékű dátumokban rejlik, akkor a probléma megoldódik egy adatbázis létrehozásával, amelynek eltolási paramétere 2000.

1. Ha a probléma az adatbázis betöltése, akkor:
1.1. Ha MS SQL Server adatbázisba tölt be (dt-fájl használatával), akkor az adatbázis létrehozásakor a betöltés előtt adja meg a dátumeltolást - 2000.
Ha az adatbázis már létrejött 0 eltolás mellett, 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ájlverzió, próbáljon meg betölteni a DT-ből egy kliens-szerver verzióba DB2-vel (amely kevésbé igényli az egyediséget), majd hajtsa végre a Teszt és javítás, valamint a Konfiguráció - Konfiguráció ellenőrzése - A konfiguráció logikai integritásának ellenőrzése műveletet. + Érvénytelen hivatkozások keresése.

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 a Profiler segédprogramban a rendszerindítás során, vagy engedélyeznie kell a rögzítést a DBMSSQL és EXCP folyamateseménynaplóban.

2. Ha a nem egyediséggel kapcsolatos probléma a felhasználók munka közben jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdésben leírt módszerrel.

2.1.2. Néha hiba történik a lekérdezések végrehajtása közben, például:

Ez a hiba abból adódik, hogy a „Szervezetek dolgozóinak munkaideje” felhalmozási nyilvántartás modulban a „Nyilvántartási újraszámítások” eljárásban a „MÁS” szolgáltatás szó nem szerepel a kérelemben.
Kód 1C v 8.x I.e. kellene:
Request = Új kérés(
"VÁLASZTÁS KÜLÖNBÖZŐ
| Alapvető. Egyéni,
. . . . .
A ZUP és UPP legújabb kiadásaiban a hiba nem jelentkezik, mert azt írja, hogy "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 rekordot.
2.2.1. "Fish" szkript a nem egyedi rekordok azonosítá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, _Fld1389, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392_RRef1,9_F_lRRef1,9_FlTY1,9 _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _6_2RRF2 ld22261_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
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 (azonosító, kulcs) oszlopok értékeit.

A kérés felhasználása:
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 az értékek eltérőek, akkor módosítsa a _KeyField értéket egyedire. Ehhez határozza 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ő rekord egyikének kiválasztását.

Ha az ismétlődő bejegyzések egyikének (vagy mindkettőnek) nyilvánvalóan helytelen a jelentése, akkor 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 hagynia:
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 rekordpá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 a nem egyedi rekordok meghatározására 1C:Enterprise lekérdezéssel:
Code 1C v 8.x SELECT Directory.Link
FROM Directory.Directory AS Directory
GROUP BY Directory.Link
MENNYISÉG (*) > 1

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 olyan struktúrák, amelyek gyors hozzáférést tesznek lehetővé egy táblázat soraihoz egy vagy több oszlop értéke 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 a megadott adatok tárolási helyére utalnak.
Az indexek csökkentik az eredményhalmaz visszaadásához beolvasandó adatok mennyiségét.

Bár egy index egy tábla egy adott oszlopához (oszlopaihoz) van társítva, mégis egy különálló adatbázis-objektum.

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

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

Fizikailag az 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 úgy néz ki, mint egy halom adat. 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álnak az indexek alapvető funkciói:
- az adathozzáférés sebességének növelése,
— az adatok egyediségének támogatása.

Előnyeik ellenére az indexeknek számos hátránya is van. Az első az indexek további lemezterületet foglal elés a RAM-ban. Minden alkalommal, amikor létrehoz egy indexet, a kulcsokat csökkenő vagy növekvő sorrendben tárolja, amelyek többszintű szerkezetűek lehetnek. É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 index van megvalósítva:

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 meg új érték beszúrását vagy egy meglévő érték megváltoztatását oly módon, 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 indexe és több egyedi nem fürtözött indexe lehet.
Egyedi indexeket csak akkor szabad meghatározni, ha valóban 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 megkötést. Kizárólag az adatok integritásának biztosítására való felhasználásuk az adatbázisterület pazarlása. 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-ról való konvertáláskor vagy a 8.1.7-ről való átálláskor nem egyedi indexhiba jelenhet meg.

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

Mit kell tenni?

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

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

Ha az adatbázis már létrejött 0 eltolás mellett, akkor hozzon létre egy újat 2000-el.

1.5. Ha a csomópont (cseretervek) elérhető, akkor hajtsa végre a cserét. A csere előtt kiegészítheti a 2.3.5. bekezdést is

2. Ha a nem egyediséggel kapcsolatos probléma a felhasználók munka közben jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdésben leírt módszerrel.

2.1.2. Néha hiba történik a lekérdezések végrehajtása közben, például:

Azok. kellene:

Request = Új kérés(
"VÁLASZTÁS KÜLÖNBÖZŐ
| 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 rekordot.

2.2.1. "Fish" szkript a nem egyedi rekordok azonosítá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:

dokumentum ld1393_RRRef, _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RR_Ref f, _Fld2226 1_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:

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 (azonosító, kulcs) oszlopok értékeit.

A kérés felhasználása:

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 az értékek eltérőek, akkor módosítsa a _KeyField értéket egyedire. Ehhez határozza 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ő rekord egyikének kiválasztását.

Ha az ismétlődő bejegyzések egyikének (vagy mindkettőnek) nyilvánvalóan helytelen a jelentése, akkor 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 hagynia:

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 rekordpá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 a nem egyedi rekordok meghatározására 1C:Enterprise lekérdezéssel:

vagy könyvelésre

VÁLASZT
Subquery.Period,
Subquery.Registrator,
<измерения>,
SUM(Subquery.Number of Records) AS Rekordok száma
TÓL TŐL
(VÁLASZT
Önfenntartó időszak AS időszak,
Önfenntartó.Registrar 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.Registrator,
<измерения>

HAJNÁL
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-ben történő csere során. A hiba az összegek kiszámításához vagy az elemzésekhez kapcsolódó „kiegészítő” táblákban fordul elő. Például:

Hiba a kontextus metódus (Write) hívásakor: Nem egyedi érték beszúrása egy 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 be az üzenetet, engedélyezze az összegek használatát és számolja újra.

Megoldások:

3. Ha a nem egyediség nulla értékű dátumokban rejlik, akkor a probléma megoldódik egy adatbázis létrehozásával, amelynek eltolási paramétere 2000.

2. Ha a nem egyediséggel kapcsolatos probléma a felhasználók munka közben jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdésben leírt módszerrel.

2.1.2. Néha hiba történik a lekérdezések végrehajtása közben, például:

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 rekordpá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)

Megoldások:

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 a jamb indexet a _AccumRgTn19455 táblázatbó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ő rekord jelent meg, bár a 2. lépés előtt a lekérdezés nem adott vissza semmit.
4) Végignéztem az összes bejegyzést, é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. Kiderült, hogy az _AccumRgTn19455 tábla tárolja a „Termékkibocsátás (adóelszámolás)” felhalmozási regisztert. Az sql lekérdezéseken is bíbelődtem, azonosítottam 15 nem egyedi dokumentumot, és az összes művelet elvégzése után az 1C-ben ellenőriztem, hogy ezeket a dokumentumokat rendesen, hiba nélkül dolgozták fel. Természetesen nem szabad véletlenszerűen takarítani az asztalokat: fontos megérteni, hogy mit takarítanak meg, és hogyan lehet az.
5) Indított egy kérést egy index létrehozására, amelyet fájlba mentett.
6) Átkapcsolta az adatbázist egyfelhasználós módba, és elindította a dbcc checkdb-t – ezúttal nem keletkezett hiba.
7) Visszakapcsolta a bázist egyfelhasználós módba.
Ennyi... a probléma leküzdve. Nos, még az 1C-ben elindítottam a „Tesztelés és javítás”-ot, ott is minden rendben ment, nem panaszkodtam a nem egyedi index miatt.

3. Ha a nem egyediség nulla értékű dátumokban rejlik, akkor a probléma megoldódik egy adatbázis létrehozásával, amelynek eltolási paramétere 2000.

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ó - A konfiguráció ellenőrzése - A konfiguráció logikai integritásának ellenőrzése + Helytelen hivatkozások keresése.

2. Ha a nem egyediség probléma a felhasználók munka közben jelentkezik:

2.1. Keresse meg a problémás kérést az 1.4. bekezdésben leírt módszerrel.

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

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, _Fld1389, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392_RRef1,9_F_lRRef1,9_FlTY1,9 _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _6_2RRF2 ld22261_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 (azonosító, kulcs) oszlopok értékeit.

A kérés felhasználása:
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 az értékek eltérőek, akkor módosítsa a _KeyField értéket egyedire. Ehhez határozza meg a _KeyField (keymax) maximálisan foglalt értékét:
SQL kód S_elect max(_KeyField)
forrás: _Document140_VT1385
hol van a _Document140_IDRRef = id1
Cserélje ki a _KeyField értéket az egyik ismétlődő bejegyzésben a megfelelőre:
Az 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ő rekord egyikének kiválasztását.

Ha az ismétlődő bejegyzések egyikének (vagy mindkettőnek) nyilvánvalóan helytelen a jelentése, akkor el kell távolítani:
SQL-kód törlése innen: _Document140_VT1385
hol van a _Document140_IDRRef = id1 és _LineNo1386 = lineno1
Ha az ismétlődő bejegyzések értéke minden oszlopban azonos, akkor az egyiket meg kell hagynia:
SQL kód S_elect different *
a #tmp1-be
from_Document140_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 rekordpá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)

Az oldalról vett információ

Hiba történik, ha az adatbázisban egyes objektumok, részletek, alkontosztok NULL értékkel rendelkeznek, de nem rendelkezhetnek ilyen értékkel. És ez a hiba csak az SQL adatbázisokban jelenik meg. Azok. Ha feltölt egy ilyen adatbázist egy fájlba, akkor ez a hiba többé nem jelenik meg. Mert A fájl adatbá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 nem lehet megoldani semmilyen (sem külső, sem belső) teszteléssel az adatbázis bármely verziójában (SQL vagy fájl), és még az SQL-kezelő _1sp_DBReindex eljárásával sem, amely úgy tűnik, hogy átstrukturálja a táblákat az SQL-ben.

Nézzük meg a probléma megoldását a Accounting 3.0 PROF-ról CORP-ra való váltás példáján keresztül. Az átállás után a 68.01-es számlának új alszámlája van, Adóhatósági regisztráció. Ezután az SQL-adatbázisokban a PRO verzióban létrehozott, ezt a fiókot használó dokumentumok nem kerülnek átvitelre. Megjelenik a fent látható hiba. Mert Ez az új alszámla a régi bizonylatokhoz, a könyvelésekben, NULL értékkel lesz kiírva (bár legyen Üres érték, vagy valahogy az adóhatóság).

A hiba kijavításához el kell távolítania a NULL értékeket ott, ahol nem kellene. Ebben az esetben azokban a dokumentumokban, ahol az Adóhatósági regisztráció alszámla 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). Csináld feldolgozással, mert Ugyanezt a hibát eredményezi, ha megpróbálja manuálisan módosítani az alszámla értékét a bizonylatok könyvelésében.

Az alábbi cikkből letölthető a NULL-ok cseréjére vonatkozó feldolgozás az adóhatósági regisztráció összes alkapcsolatában.

DE nem fog működni a NULL lecserélése az SQL adatbázisban a feldolgozás során ugyanaz a hiba keletkezik. Ezért ezt kell tennie:

1. Töltse fel az SQL-adatbázis már működő, CORP-re lefordított verzióját a dt fájlba (a konfigurátor Adminisztráció – Adatbázis feltöltése – válassza ki, hogy hova töltse fel az adatbázist *.dt fájlként)

2. Töltse be a dt fájlt a fájl adatbázisba (egy szükségtelen vagy előre elkészített, tiszta fájl adatbázisban, a konfigurátorban Adminisztráció - Adatbázis betöltése - válassza ki a korábban feltöltött dt fájlt)

3. Végezze el a feldolgozást a fájl adatbázisban (nem lesz ott 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 fájlt a fájl adatbázisból, és töltse be az SQL adatbázisba. Mostantól a feldolgozott dokumentumok feladásakor nem fordulnak elő hibák.

Az ebből a cikkből származó feldolgozás megkeresi a megadott időszakra vonatkozó összes olyan dokumentumot, amelyben a feladások tartalmazzák az alvállalkozói regisztrációt az adóhatóságnál (amely a CORP verzióban jelenik meg), amelynek értéke NULL. És lecseréli ezt az értéket egy Üres értékre.

A feldolgozásnál meg kell jelölni azt az időszakot, amelyre a dokumentumokat feldolgozni kívánják (ezt megteheti az adatbázisban való nyilvántartás teljes időtartamára), majd kattintson a „Táblázatos rész kitöltése” gombra. Ezután bejelölheti a jelölőnégyzeteket, hogy mely dokumentumokat kell feldolgozni (kijelölheti az összeset), és kattintson a „Feldolgozás” gombra.

Ennek megfelelően, ha valakinél ugyanez a hiba, de NEM CORP-ra váltás után, hanem például valamilyen adatcsere, betöltés, valamilyen feldolgozás elvégzése, stb. Ezután meg kell határoznia, hogy egy adott dokumentumban/könyvtárban hol volt hozzárendelve a NULL érték, és hasonló módon, de saját feldolgozással, 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 számvitelieket, hanem valahol bizonylat/referenciakönyv formájában is, néhány részletben, de ebben az esetben valószínűleg nem is nyílik meg.

Továbbá, ha ez a hiba egy dokumentum feladásakor jelent meg, miután átvitte a Bukh KORP fájl adatbázist SQL-be (és az adatbázis egykor eredetileg PROF volt), ez azt jelenti, hogy a PROF verzióban létrehozott dokumentumok most is a alszámla Az adóhatósági NULL értékben történő regisztráció és az SQL adatbázis ezt nem fogadja el. Az adatbázis SQL-be való betöltésekor pedig a következő hibaüzenet jelenik meg. Valójában itt nem lesznek NULL értékek a fájl adatbázisban, de az SQL pontosan ilyen értékeket tölt be a tábláiba. Ezért itt kényszerítenünk kell az SQL adatbázist, hogy hozza létre ezeket a NULL-okat, majd javítsa ki őket a fájl adatbázisban, de nem tudom megmondani, hogyan kell ezt megtenni.