Klaida: bandoma įterpti neunikalią reikšmę į unikalų indeksą: microsoft sql server. pereinant iš buh prof į bldg ir ne tik. Į unikalų indeksą buvo bandoma įterpti neunikalią reikšmę. Pasikartojančios reikšmės negalima įterpti į unikalų indeksą.

Gavote pranešimą, kuriame yra šios eilutės:
Microsoft OLE DB teikėjas, skirtas SQL serveriui: CREATE UNIQUE INDEX nutrauktas, nes buvo rastas pasikartojantis indekso ID raktas
arba
Į objektą negalima įterpti pasikartojančios raktų eilutės
arba
Į unikalų indeksą buvo bandoma įterpti neunikalią reikšmę.

Sprendimai:

1. SQL Server valdymo studijoje mes fiziškai sunaikiname sugedusį indeksą (mano atveju tai buvo apskaitos registro sumų lentelės indeksas). 1C išplatinsime sugedusius dokumentus. Testavimo ir taisymo režimu pažymėkite langelius lentelės perindeksavimas + sumų perskaičiavimas. 1C atkuria indeksą be klaidos. Atliekame anksčiau nevykusius dokumentus.

2. 1) Naudodamas „Management Studio 2005“, sukūriau kūrimo scenarijų, kad sukurčiau indeksą, kuris buvo klaidingas, ir išsaugojau jį faile.
2) Rankiniu būdu iš lentelės _AccumRgTn19455 pašalintas stulpelio indeksas
3) Pateikė užklausą kaip
SQL kodas S_elect count(*), index_fields
IŠ AccumRgTn19455
GROUP BY rodyklės_laukas
Skaičiuojant (*)>1
Kai indeksas buvo nužudytas, man buvo rodoma 15 pasikartojančių įrašų, nors prieš 2 veiksmą užklausa nieko nepateikė.
4) Peržiūrėjau visus įrašus ir rankiniu būdu išvaliau dublikatus. Tiesą sakant, aš taip pat naudojau „ataskaitos struktūros“ apdorojimą, kad suprasčiau, su kuo turiu reikalų. Paaiškėjo, kad lentelėje _AccumRgTn19455 saugomas kaupimo registras „Produktų produkcija (mokesčių apskaita)“. Taip pat padirbėjau su sql užklausomis, identifikavau 15 neunikalių dokumentų ir atlikus visus veiksmus patikrinau 1C, ar šie dokumentai tvarkomi normaliai, be klaidų. Žinoma, nereikėtų stalų valyti tik atsitiktinai: svarbu suprasti, kas valoma ir kaip tai gali pasirodyti.
5) Paleido prašymą sukurti indeksą, kuris buvo išsaugotas faile.
6) Perjungė duomenų bazę į vieno vartotojo režimą ir paleido dbcc checkdb – šį kartą klaidų nesugeneruota.
7) Perjungė bazę atgal į vieno vartotojo režimą.
Tai tiek... problema įveikta. Na, o dar 1C paleidau „Testing and Correction“, ten irgi viskas gerai, nustojau skųstis dėl neunikalaus indekso.

3. Jei nepakartojamumas slypi datose su nulinėmis reikšmėmis, tada problema išspręsta sukuriant duomenų bazę, kurios poslinkio parametras lygus 2000.

1. Jei problema kyla dėl duomenų bazės įkėlimo, tada:
1.1. Jei įkeliate (naudodami dt failą) į MS SQL Server duomenų bazę, tada kurdami duomenų bazę prieš įkeldami nurodykite datos poslinkį - 2000.
Jei duomenų bazė jau buvo sukurta su poslinkiu 0, sukurkite naują su 2000.

1.2. Jei yra galimybė dirbti su duomenų baze failo versijoje, tada atlikite testavimą ir taisymą, taip pat Konfigūraciją - Konfigūracijos patikrinimą - Konfigūracijos loginio vientisumo patikrinimą + Neteisingų nuorodų paiešką.

1.3. Jei failo versijos nėra, pabandykite įkelti iš DT į kliento-serverio versiją su DB2 (kuris mažiau reikalauja unikalumo), tada atlikite testą ir taisymą, taip pat konfigūraciją – patikrinkite konfigūraciją – patikrinkite konfigūracijos loginį vientisumą. + Ieškokite netinkamų nuorodų.

1.4. Norėdami lokalizuoti problemą, galite nustatyti objekto, kurio įkelti nepavyko, duomenis. Norėdami tai padaryti, įkrovos metu turite įgalinti sekimą Profiler paslaugų programoje arba įgalinti įrašymą DBMSSQL ir EXCP proceso įvykių žurnale.

2. Jei neunikalumo problema iškyla naudotojams dirbant:

2.1. Raskite probleminę užklausą naudodami 1.4 punkte nurodytą metodą.

2.1.2. Kartais vykdant užklausas įvyksta klaida, pavyzdžiui:

Ši klaida atsiranda dėl to, kad kaupimo registro modulyje „Organizacijų darbuotojų darbo laikas“ procedūroje „Regitros perskaičiavimai“ į užklausą neįtrauktas tarnybinis žodis „KITOKIA“.
Kodas 1C v 8.x T.y. turėtų būti:
Užklausa = nauja užklausa(
„PASIRINKITE ĮVAIRIUS
| Pagrindinis. Asmuo,
. . . . .
Naujausiuose ZUP ir UPP leidimuose klaida neįvyksta, nes sakoma "KITOKIA".

2.2. Suradę probleminę rodyklę iš ankstesnės pastraipos, turite rasti neunikalią įrašą.
2.2.1. „Fish“ scenarijus, skirtas identifikuoti neunikalius įrašus naudojant SQL:
SQL kodas S_elect COUNT(*) skaitiklis,<перечисление всех полей соответствующего индекса>iš<имя таблицы>
GRUPĖ BY<перечисление всех полей соответствующего индекса>
TURIMAS skaitiklis > 1

2.2.2 Pavyzdys. Klaidos indeksas vadinamas „_Document140_VT1385_IntKeyIndNG“.
Lentelės laukų sąrašas:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1389, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392_RRef1,9_F_lTY1,9 _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _6_2RRFlf2 ld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Prieš atlikdami toliau nurodytą procedūrą, atlikite atsarginė kopija duomenų bazės.
Paleiskite MS SQL Server Query Analyzer:
SQL kodas S_elect count(*), _Document140_IDRRef, _KeyField
iš_Dokumento140_VT1385
sugrupuoti pagal _Document140_IDRRef, _KeyField
kurių skaičius (*) > 1
Naudokite jį norėdami sužinoti stulpelių _Document140_IDRRef, _KeyField, pasikartojančių įrašų (id, raktas) reikšmes.

Naudojant užklausą:
SQL kodas S_elect*
iš_Dokumento140_VT1385
arba _Document140_IDRRef = id2 ir _KeyField = key2 arba ...
pažiūrėkite į kitų pasikartojančių įrašų stulpelių reikšmes.
Jei abu įrašai turi reikšmingas reikšmes ir vertės skiriasi, pakeiskite _KeyField reikšmę į unikalią. Norėdami tai padaryti, nustatykite maksimalią užimtą _KeyField reikšmę (keymax):
SQL kodas S_elect max(_KeyField)
iš_Dokumento140_VT1385
kur _Document140_IDRRef = id1
Pakeiskite _KeyField reikšmę viename iš pasikartojančių įrašų teisingu:
SQL kodo naujinimas _Document140_VT1385
nustatyti _KeyField = keymax + 1
Čia _LineNo1386 = yra papildoma sąlyga, leidžianti pasirinkti vieną iš dviejų pasikartojančių įrašų.

Jei vienas (arba abu) pasikartojantys įrašai turi akivaizdžiai neteisingą reikšmę, jis turėtų būti pašalintas:
SQL kodo ištrynimas iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _LineNo1386 = lineno1
Jei pasikartojančių įrašų reikšmės visuose stulpeliuose yra vienodos, turite palikti vieną iš jų:
SQL kodas S_elect atskiras *
į #tmp1
iš_Dokumento140_VT1385
kur _Document140_IDRRef = id1 ir _KeyField = raktas1

Ištrinti iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _KeyField = raktas1

Įterpti į _Dokumentą140_VT1385
S_elect #tmp1

D_rop lentelė #tmp1

Apibūdinta procedūra turi būti atlikta kiekvienai pasikartojančių įrašų porai.

2.2.3. Antras pavyzdys:
SQL kodas S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
IŠ _8 nuoroda_
GROUP BY _IDRRef, _Aprašymas
TURIMAS (SKAIČIUS(*) > 1)

2.3.4 Neunikalių įrašų nustatymo naudojant 1C:Enterprise užklausą pavyzdys:
Kodas 1C v 8.x SELECT Directory.Link
IŠ Directory.Directory AS Katalogas
GROUP BY Directory.Link
KIEKIS (*) > 1

Klaida įvyksta, jei kai kurie objektai, detalės, subkontai duomenų bazėje turi NULL reikšmę, bet negali turėti tokios reikšmės. Ir ši klaida atsiranda tik SQL duomenų bazėse. Tie. Jei įkelsite tokią duomenų bazę į failą, šios klaidos nebebus. Nes Failų duomenų bazė turi savo lenteles (iš viso 4), o SQL – savo. Ir SQL duomenų bazė kritiškai reaguoja į tokias vertes savo lentelėse.

Šios problemos negalima išspręsti jokiu testavimu (nei išoriniu, nei vidiniu) bet kurioje duomenų bazės versijoje (SQL ar faile) ir net naudojant _1sp_DBReindex procedūrą SQL tvarkyklėje, kuri, atrodo, turėtų pertvarkyti lenteles SQL.

Pažvelkime į problemos sprendimą, naudodami pavyzdį, kaip perjungti iš apskaitos 3.0 PROF į CORP. Po pakeitimo paskyra 68.01 turi naują subsąskaitą Registracija mokesčių inspekcijoje. Tada SQL duomenų bazėse visi dokumentai, sukurti PRO versijoje, naudojantys šią paskyrą, nebus perkelti. Pasirodys aukščiau parodyta klaida. Nes Ši nauja senų dokumentų subsąskaita įrašuose bus parašyta reikšme NULL (nors turėtų būti reikšmė Tuščia, arba kaip nors mokesčių institucija).

Norėdami ištaisyti šią klaidą, turite pašalinti NULL reikšmes ten, kur jų neturėtų būti. Šiuo atveju dokumentuose, kuriuose naudojama subkonto Registracija mokesčių inspekcijoje. Tai galima padaryti parašius apdorojimą, kuris pakeis NULL reikšme Empty (paruoštą apdorojimą galima atsisiųsti iš šio straipsnio). Padarykite tai perdirbdami, nes Bandymas rankiniu būdu pakeisti šios subsąskaitos vertę dokumentų įrašuose sukelia tą pačią klaidą.

Apdorojimą, skirtą NULL pakeitimui visuose registracijos mokesčių inspekcijoje antriniuose kontaktuose, galite atsisiųsti iš šio straipsnio toliau.

BET SQL duomenų bazėje pakeisti NULL neveiks ta pati klaida. Todėl jums reikia tai padaryti:

1. Įkelkite jau veikiančią SQL duomenų bazės versiją, išverstą į CORP, į dt failą (konfigūratoriaus Administravimas – Įkelti duomenų bazę – pasirinkite, kur įkelti duomenų bazę *.dt failo pavidalu)

2. Įkelkite dt failą į failų duomenų bazę (nereikalingoje arba iš anksto paruoštoje, švarioje failų duomenų bazėje, konfigūratoriuje Administravimas - Įkelti duomenų bazę - pasirinkite anksčiau įkeltą dt failą)

3. Atlikite apdorojimą failų duomenų bazėje (ten nebus klaidų ir visi NULL bus pakeisti teisingai) (kaip atlikti apdorojimą aprašyta toliau)

5. Dabar, priešingai, iškelkite dt failą iš failų duomenų bazės ir įkelkite jį į SQL duomenų bazę. Dabar, registruojant apdorotus dokumentus, klaidų nebus.

Apdorojant šį straipsnį, randami visi nurodyto laikotarpio dokumentai, kuriuose yra subrangos registracija mokesčių inspekcijoje (kuri pateikiama CORP versijoje), kurios reikšmė NULL. Ir pakeičia šią reikšmę reikšme Tuščia.

Tvarkant turite nurodyti laikotarpį, kuriam reikia tvarkyti dokumentus (galite visą laikotarpį, kurį įrašai saugomi duomenų bazėje) ir paspausti „Pildyti lentelės dalis“ Tada galite pažymėti langelius, kad pažymėtumėte, kuriuos dokumentus tvarkyti (galite pasirinkti visus) ir spustelėkite mygtuką „Apdoroti“.

Atitinkamai, jei kas nors turi tą pačią klaidą, bet NE perjungus į CORP, o pavyzdžiui, pasikeitus, įkėlus tam tikrus duomenis, atlikus tam tikrą apdorojimą ir pan. Tada turite nustatyti, kur NULL reikšmė buvo priskirta konkrečiame dokumente / kataloge, ir pašalinti šią NULL panašiu būdu, bet apdorojant savo pačių, bet aukščiau aprašyta tvarka. Atminkite, kad NULL gali būti, kaip ir dokumentų registravime, įskaitant. ne tik buhalterinės, bet ir kažkur ant dokumento/žinyno formos, kai kuriose smulkmenose, bet šiuo atveju turbūt net neatsivers.

Be to, jei ši klaida jums pasirodė skelbiant dokumentą, kai perkėlėte Bukh KORP failų duomenų bazę į SQL (o duomenų bazė kadaise buvo PROF), tai reiškia, kad tie dokumentai, kurie buvo sukurti PROF versijoje, dabar taip pat yra subsąskaita Registruojantis mokesčių inspekcijoje NULL reikšmė ir SQL duomenų bazė to nepriima. O įkeliant duomenų bazę į SQL atsiras tokia klaida. Čia iš tikrųjų failų duomenų bazėje nebus NULL reikšmių, tačiau SQL į savo lenteles įkels būtent tokias reikšmes. Todėl turime priversti SQL duomenų bazė sukurkite šiuos NULL ir ištaisykite juos failų duomenų bazėje, bet aš negaliu pasakyti, kaip tai padaryti.

Gavote pranešimą, kuriame yra šios eilutės:
Microsoft OLE DB teikėjas, skirtas SQL serveriui: CREATE UNIQUE INDEX nutrauktas, nes buvo rastas pasikartojantis indekso ID raktas
arba
Į objektą negalima įterpti pasikartojančios raktų eilutės
arba
Į unikalų indeksą buvo bandoma įterpti neunikalią reikšmę.

Sprendimai:

1. SQL Server valdymo studijoje mes fiziškai sunaikiname sugedusį indeksą (mano atveju tai buvo apskaitos registro sumų lentelės indeksas). 1C išplatinsime sugedusius dokumentus. Testavimo ir taisymo režimu pažymėkite langelius lentelės perindeksavimas + sumų perskaičiavimas. 1C atkuria indeksą be klaidos. Atliekame anksčiau nevykusius dokumentus.

2. 1) Naudodamas „Management Studio 2005“, sukūriau kūrimo scenarijų, kad sukurčiau indeksą, kuris buvo klaidingas, ir išsaugojau jį faile.
2) Rankiniu būdu iš lentelės _AccumRgTn19455 pašalintas stulpelio indeksas
3) Pateikė užklausą kaip
SQL kodas S_elect count(*), index_fields
FR OM AccumRgTn19455
GROUP BY rodyklės_laukas
Skaičiuojant (*)>1
Kai indeksas buvo nužudytas, man buvo rodoma 15 pasikartojančių įrašų, nors prieš 2 veiksmą užklausa nieko nepateikė.
4) Peržiūrėjau visus įrašus ir rankiniu būdu išvaliau dublikatus. Tiesą sakant, aš taip pat naudojau „ataskaitos struktūros“ apdorojimą, kad suprasčiau, su kuo turiu reikalų. Paaiškėjo, kad lentelėje _AccumRgTn19455 saugomas kaupimo registras „Produktų produkcija (mokesčių apskaita)“. Taip pat padirbėjau su sql užklausomis, identifikavau 15 neunikalių dokumentų ir atlikus visus veiksmus patikrinau 1C, ar šie dokumentai tvarkomi normaliai, be klaidų. Žinoma, nereikėtų stalų valyti tik atsitiktinai: svarbu suprasti, kas valoma ir kaip tai gali pasirodyti.
5) Paleido prašymą sukurti indeksą, kuris buvo išsaugotas faile.
6) Perjungė duomenų bazę į vieno vartotojo režimą ir paleido dbcc checkdb – šį kartą klaidų nesugeneruota.
7) Perjungė bazę atgal į vieno vartotojo režimą.
Tai tiek... problema įveikta. Na, o dar 1C paleidau „Testing and Correction“, ten irgi viskas gerai, nustojau skųstis dėl neunikalaus indekso.

3. Jei nepakartojamumas slypi datose su nulinėmis reikšmėmis, tada problema išspręsta sukuriant duomenų bazę, kurios poslinkio parametras lygus 2000.

1. Jei problema kyla dėl duomenų bazės įkėlimo, tada:
1.1. Jei įkeliate (naudodami dt failą) į MS SQL Server duomenų bazę, tada kurdami duomenų bazę prieš įkeldami nurodykite datos poslinkį - 2000.
Jei duomenų bazė jau buvo sukurta su poslinkiu 0, sukurkite naują su 2000.

1.2. Jei yra galimybė dirbti su duomenų baze failo versijoje, tada atlikite testavimą ir taisymą, taip pat Konfigūraciją - Konfigūracijos patikrinimą - Konfigūracijos loginio vientisumo patikrinimą + Neteisingų nuorodų paiešką.

1.3. Jei failo versijos nėra, pabandykite įkelti iš DT į kliento-serverio versiją su DB2 (kuris mažiau reikalauja unikalumo), tada atlikite testą ir taisymą, taip pat konfigūraciją – patikrinkite konfigūraciją – patikrinkite konfigūracijos loginį vientisumą. + Ieškokite netinkamų nuorodų.

1.4. Norėdami lokalizuoti problemą, galite nustatyti objekto, kurio įkelti nepavyko, duomenis. Norėdami tai padaryti, įkrovos metu turite įgalinti sekimą Profiler paslaugų programoje arba įgalinti įrašymą DBMSSQL ir EXCP proceso įvykių žurnale.

2. Jei ne unikalumo problema iškyla naudotojams dirbant:

2.1. Raskite probleminę užklausą naudodami 1.4 punkte nurodytą metodą.

2.1.2. Kartais vykdant užklausas įvyksta klaida, pavyzdžiui:

Ši klaida atsiranda dėl to, kad kaupimo registro modulyje „Organizacijų darbuotojų darbo laikas“ procedūroje „Regitros perskaičiavimai“ į užklausą neįtrauktas tarnybinis žodis „KITOKIA“.
Kodas 1C v 8.x T.y. turėtų būti:
Užklausa = nauja užklausa(
„PASIRINKITE ĮVAIRIUS
| Pagrindinis. Asmuo,
. . . . .
Naujausiuose ZUP ir UPP leidimuose klaida neįvyksta, nes sakoma "KITOKIA".

2.2. Suradę probleminę rodyklę iš ankstesnės pastraipos, turite rasti neunikalią įrašą.
2.2.1. „Fish“ scenarijus, skirtas identifikuoti neunikalius įrašus naudojant SQL:
SQL kodas S_elect COUNT(*) skaitiklis,<перечисление всех полей соответствующего индекса>nuo om<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
TURIMAS skaitiklis > 1

2.2.2 Pavyzdys. Klaidos indeksas vadinamas „_Document140_VT1385_IntKeyIndNG“.
Lentelės laukų sąrašas:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1389, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392_RRef1,9_F_lTY1,9 _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _6_2RRFlf2 ld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Prieš atlikdami toliau nurodytą procedūrą, sukurkite atsarginę duomenų bazės kopiją.
Paleiskite MS SQL Server Query Analyzer:
SQL kodas S_elect count(*), _Document140_IDRRef, _KeyField
iš _Document140_VT1385
sugrupuoti pagal _Document140_IDRRef, _KeyField
kurių skaičius (*) > 1
Naudokite jį norėdami sužinoti stulpelių _Document140_IDRRef, _KeyField, pasikartojančių įrašų (id, raktas) reikšmes.

Naudojant užklausą:
SQL kodas S_elect*
iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _KeyField = raktas1 arba _Document140_IDRRef = id2 ir _KeyField = raktas2 arba ...
pažiūrėkite į kitų pasikartojančių įrašų stulpelių reikšmes.
Jei abu įrašai turi reikšmingas reikšmes ir reikšmės skiriasi, pakeiskite _KeyField reikšmę į unikalią. Norėdami tai padaryti, nustatykite maksimalią užimtą _KeyField reikšmę (keymax):
SQL kodas S_elect max(_KeyField)
iš _Document140_VT1385
kur _Document140_IDRRef = id1
Pakeiskite _KeyField reikšmę viename iš pasikartojančių įrašų teisingu:
SQL kodas atnaujintas _Document140_VT1385
nustatyti _KeyField = max max + 1

Čia _LineNo1386 = yra papildoma sąlyga, leidžianti pasirinkti vieną iš dviejų pasikartojančių įrašų.

Jei vienas (arba abu) pasikartojantys įrašai turi akivaizdžiai neteisingą reikšmę, jis turėtų būti pašalintas:
SQL kodo ištrynimas iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _LineNo1386 = lineno1
Jei pasikartojančių įrašų reikšmės visuose stulpeliuose yra vienodos, turite palikti vieną iš jų:
SQL kodas S_elect atskiras *
į #tmp1
iš_Dokumento140_VT1385

Ištrinti iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _KeyField = raktas1

Įterpti į _Dokumentą140_VT1385
S_elect #tmp1

D_rop lentelė #tmp1

Apibūdinta procedūra turi būti atlikta kiekvienai pasikartojančių įrašų porai.

2.2.3. Antras pavyzdys:
SQL kodas S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
IŠ _8 nuoroda_
GROUP BY _IDRRef, _Aprašymas
TURIMAS (SKAIČIUS(*) > 1)

2.3.4 Neunikalių įrašų nustatymo naudojant 1C:Enterprise užklausą pavyzdys:
Kodas 1C v 8.x SELECT Directory.Link
IŠ Directory.Directory AS Katalogas
GROUP BY Directory.Link
KIEKIS (*) > 1

Informacija paimta iš svetainės

Gavote pranešimą, kuriame yra šios eilutės:
Microsoft OLE DB teikėjas, skirtas SQL serveriui: CREATE UNIQUE INDEX nutrauktas, nes buvo rastas pasikartojantis indekso ID raktas
arba
Į objektą negalima įterpti pasikartojančios raktų eilutės
arba
Į unikalų indeksą buvo bandoma įterpti neunikalią reikšmę.

Sprendimai:

1. SQL Server valdymo studijoje mes fiziškai sunaikiname sugedusį indeksą (mano atveju tai buvo apskaitos registro sumų lentelės indeksas). 1C išplatinsime sugedusius dokumentus. Testavimo ir taisymo režimu pažymėkite langelius lentelės perindeksavimas + sumų perskaičiavimas. 1C atkuria indeksą be klaidos. Atliekame anksčiau nevykusius dokumentus.

2. 1) Naudodamas „Management Studio 2005“, sukūriau kūrimo scenarijų, kad sukurčiau indeksą, kuris buvo klaidingas, ir išsaugojau jį faile.
2) Rankiniu būdu iš lentelės _AccumRgTn19455 pašalintas stulpelio indeksas
3) Pateikė užklausą kaip
SQL kodas S_elect count(*), index_fields
IŠ AccumRgTn19455
GROUP BY rodyklės_laukas
Skaičiuojant (*)>1
Kai indeksas buvo nužudytas, man buvo rodoma 15 pasikartojančių įrašų, nors prieš 2 veiksmą užklausa nieko nepateikė.
4) Peržiūrėjau visus įrašus ir rankiniu būdu išvaliau dublikatus. Tiesą sakant, aš taip pat naudojau „ataskaitos struktūros“ apdorojimą, kad suprasčiau, su kuo turiu reikalų. Paaiškėjo, kad lentelėje _AccumRgTn19455 saugomas kaupimo registras „Produktų produkcija (mokesčių apskaita)“. Taip pat padirbėjau su sql užklausomis, identifikavau 15 neunikalių dokumentų ir atlikus visus veiksmus patikrinau 1C, ar šie dokumentai tvarkomi normaliai, be klaidų. Žinoma, nereikėtų stalų valyti tik atsitiktinai: svarbu suprasti, kas valoma ir kaip tai gali pasirodyti.
5) Paleido prašymą sukurti indeksą, kuris buvo išsaugotas faile.
6) Perjungė duomenų bazę į vieno vartotojo režimą ir paleido dbcc checkdb – šį kartą klaidų nesugeneruota.
7) Perjungė bazę atgal į vieno vartotojo režimą.
Tai tiek... problema įveikta. Na, o dar 1C paleidau „Testing and Correction“, ten irgi viskas gerai, nustojau skųstis dėl neunikalaus indekso.

3. Jei nepakartojamumas slypi datose su nulinėmis reikšmėmis, tada problema išspręsta sukuriant duomenų bazę, kurios poslinkio parametras lygus 2000.

1. Jei problema kyla dėl duomenų bazės įkėlimo, tada:
1.1. Jei įkeliate (naudodami dt failą) į MS SQL Server duomenų bazę, tada kurdami duomenų bazę prieš įkeldami nurodykite datos poslinkį - 2000.
Jei duomenų bazė jau buvo sukurta su poslinkiu 0, sukurkite naują su 2000.

1.2. Jei yra galimybė dirbti su duomenų baze failo versijoje, tada atlikite testavimą ir taisymą, taip pat Konfigūraciją - Konfigūracijos patikrinimą - Konfigūracijos loginio vientisumo patikrinimą + Neteisingų nuorodų paiešką.

1.3. Jei failo versijos nėra, pabandykite įkelti iš DT į kliento-serverio versiją su DB2 (kuris mažiau reikalauja unikalumo), tada atlikite testą ir taisymą, taip pat konfigūraciją – patikrinkite konfigūraciją – patikrinkite konfigūracijos loginį vientisumą. + Ieškokite netinkamų nuorodų.

1.4. Norėdami lokalizuoti problemą, galite nustatyti objekto, kurio įkelti nepavyko, duomenis. Norėdami tai padaryti, įkrovos metu turite įgalinti sekimą Profiler paslaugų programoje arba įgalinti įrašymą DBMSSQL ir EXCP proceso įvykių žurnale.

2. Jei neunikalumo problema iškyla naudotojams dirbant:

2.1. Raskite probleminę užklausą naudodami 1.4 punkte nurodytą metodą.

2.1.2. Kartais vykdant užklausas įvyksta klaida, pavyzdžiui:

Ši klaida atsiranda dėl to, kad kaupimo registro modulyje „Organizacijų darbuotojų darbo laikas“ procedūroje „Regitros perskaičiavimai“ į užklausą neįtrauktas tarnybinis žodis „KITOKIA“.
Kodas 1C v 8.x T.y. turėtų būti:
Užklausa = nauja užklausa(
„PASIRINKITE ĮVAIRIUS
| Pagrindinis. Asmuo,
. . . . .
Naujausiuose ZUP ir UPP leidimuose klaida neįvyksta, nes sakoma "KITOKIA".

2.2. Suradę probleminę rodyklę iš ankstesnės pastraipos, turite rasti neunikalią įrašą.
2.2.1. „Fish“ scenarijus, skirtas identifikuoti neunikalius įrašus naudojant SQL:
SQL kodas S_elect COUNT(*) skaitiklis,<перечисление всех полей соответствующего индекса>iš<имя таблицы>
GRUPĖ BY<перечисление всех полей соответствующего индекса>
TURIMAS skaitiklis > 1

2.2.2 Pavyzdys. Klaidos indeksas vadinamas „_Document140_VT1385_IntKeyIndNG“.
Lentelės laukų sąrašas:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1389, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392_RRef1,9_F_lTY1,9 _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _6_2RRFlf2 ld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Prieš atlikdami toliau nurodytą procedūrą, sukurkite atsarginę duomenų bazės kopiją.
Paleiskite MS SQL Server Query Analyzer:
SQL kodas S_elect count(*), _Document140_IDRRef, _KeyField
iš_Dokumento140_VT1385
sugrupuoti pagal _Document140_IDRRef, _KeyField
kurių skaičius (*) > 1
Naudokite jį norėdami sužinoti stulpelių _Document140_IDRRef, _KeyField, pasikartojančių įrašų (id, raktas) reikšmes.

Naudojant užklausą:
SQL kodas S_elect*
iš_Dokumento140_VT1385
arba _Document140_IDRRef = id2 ir _KeyField = key2 arba ...
pažiūrėkite į kitų pasikartojančių įrašų stulpelių reikšmes.
Jei abu įrašai turi reikšmingas reikšmes ir vertės skiriasi, pakeiskite _KeyField reikšmę į unikalią. Norėdami tai padaryti, nustatykite maksimalią užimtą _KeyField reikšmę (keymax):
SQL kodas S_elect max(_KeyField)
iš_Dokumento140_VT1385
kur _Document140_IDRRef = id1
Pakeiskite _KeyField reikšmę viename iš pasikartojančių įrašų teisingu:
SQL kodo naujinimas _Document140_VT1385
nustatyti _KeyField = keymax + 1
Čia _LineNo1386 = yra papildoma sąlyga, leidžianti pasirinkti vieną iš dviejų pasikartojančių įrašų.

Jei vienas (arba abu) pasikartojantys įrašai turi akivaizdžiai neteisingą reikšmę, jis turėtų būti pašalintas:
SQL kodo ištrynimas iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _LineNo1386 = lineno1
Jei pasikartojančių įrašų reikšmės visuose stulpeliuose yra vienodos, turite palikti vieną iš jų:
SQL kodas S_elect atskiras *
į #tmp1
iš_Dokumento140_VT1385
kur _Document140_IDRRef = id1 ir _KeyField = raktas1

Ištrinti iš _Document140_VT1385
kur _Document140_IDRRef = id1 ir _KeyField = raktas1

Įterpti į _Dokumentą140_VT1385
S_elect #tmp1

D_rop lentelė #tmp1

Apibūdinta procedūra turi būti atlikta kiekvienai pasikartojančių įrašų porai.

2.2.3. Antras pavyzdys:
SQL kodas S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
IŠ _8 nuoroda_
GROUP BY _IDRRef, _Aprašymas
TURIMAS (SKAIČIUS(*) > 1)

2.3.4 Neunikalių įrašų nustatymo naudojant 1C:Enterprise užklausą pavyzdys:
Kodas 1C v 8.x SELECT Directory.Link
IŠ Directory.Directory AS Katalogas
GROUP BY Directory.Link
KIEKIS (*) > 1

Atsiliepimai