itthon › Multimédia › Kísérlet történt egy nem egyedi érték beszúrására egy egyedi indexbe. Hiba: Nem egyedi érték beszúrása egy egyedi indexbe: microsoft sql server. amikor a számviteli szakemberről a vállalatira vált, és nem csak Távolítsa el a nem egyedi indexeket az 1c 8 fájlban

Kísérlet történt egy nem egyedi érték beszúrására egy egyedi indexbe. Hiba: Nem egyedi érték beszúrása egy egyedi indexbe: microsoft sql server. amikor a számviteli szakemberről a vállalatira vált, és nem csak Távolítsa el a nem egyedi indexeket az 1c 8 fájlban

Ö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, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef3,9F_lTYd1,9F_lTYd1,3RT A _Fld22261_TYPE, _Fld222 61_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
from_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 *
from_Document140_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)
from_Document140_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 jelentése van, 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
from_Document140_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 szerkezetek, 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 kulcsokat tartalmaz, amelyek egy táblázat vagy nézet egy vagy több oszlopából épülnek fel, és mutatók, 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 adatokat tárolják 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ű szerkezettel is rendelkezhetnek. É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 megszorí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-s verzió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:

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef, _9_FlPE1386, _9_FRTD1 Fld1393_RRRef , _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRef_12PE2RT2 Ref., _Fld222 61_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
from_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:

válassz *
from_Document140_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
from_Document140_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 jelentése van, 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
from_Document140_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
Önhordó. 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,
<измерения>

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-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:

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.

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:

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 A _Fld22261_TYPE, _Fld222 61_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 jelentése van, akkor 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 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ó

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)

Népszerű a kategóriában: