Tika atklāti neunikāli ieraksti ar lauka vērtībām 1c. Kļūda: unikālā rādītājā tiek mēģināts ievietot neunikālu vērtību: microsoft sql server

31.10.2021

Jūs esat saņēmis ziņojumu, kurā ir šādas rindas:
Microsoft OLE DB nodrošinātājs SQL serverim: UNIKĀLA INDEKSA IZVEIDE ir pārtraukta, jo indeksa ID tika atrasta atslēgas dublikāts
vai
Objektā nevar ievietot dublikātu atslēgas rindu
vai
Unikālā indeksā tika mēģināts ievietot neunikālu vērtību.

Risinājumi:

1. SQL Server pārvaldības studijā mēs fiziski iznīcinām bojāto indeksu (manā gadījumā tas bija indekss grāmatvedības reģistra kopsummu tabulā). 1C mēs izplatīsim bojātos dokumentus. Pārbaudes un labošanas režīmā atzīmējiet izvēles rūtiņas tabulas atkārtotai indeksēšanai + kopsummu pārrēķiniem. 1C atkārtoti izveido indeksu bez kļūdas. Mēs veicam iepriekš neizdevušos dokumentus.

2. 1) Izmantojot Management Studio 2005, es ģenerēju izveides skriptu, lai izveidotu indeksu, kas bija kļūdains, un saglabāju to failā.
2) Manuāli nogalināja jamb indeksu no tabulas _AccumRgTn19455
3) Uzsākts pieprasījums patīk
SQL kods S_elect count(*), index_fields
FR OM AccumRgTn19455
GROUP BY index_field
ARĪ SKAITĀ(*)>1
Pēc indeksa iznīcināšanas man tika parādīti 15 ierakstu dublikāti, lai gan pirms 2. darbības vaicājums neko neatgrieza.
4) Es izgāju cauri visiem ierakstiem un manuāli notīrīju dublikātus. Patiesībā es izmantoju arī “Pārskata struktūras” apstrādi, lai saprastu, ar ko man ir darīšana. Izrādījās, ka tabulā _AccumRgTn19455 glabājas uzkrājumu reģistrs “Produktu izlaide (nodokļu uzskaite)”. Es arī pastrādāju ar sql vaicājumiem, identificēju 15 neunikālus dokumentus un pēc visu darbību pabeigšanas 1C pārbaudīju, vai šie dokumenti tiek apstrādāti normāli, bez kļūdām. Protams, nevajadzētu tīrīt galdus tikai pēc nejaušības principa: ir svarīgi saprast, kas tiek tīrīts un kā tas var izrādīties.
5) Uzsākts pieprasījums izveidot indeksu, kas tika saglabāts failā.
6) Pārslēdzu datubāzi uz viena lietotāja režīmu un palaižu dbcc checkdb - šoreiz kļūdas netika ģenerētas.
7) Pārslēdza bāzi atpakaļ uz viena lietotāja režīmu.
Tas tā... problēma ir pārvarēta. Nu jau 1C es palaidu “Testēšana un labošana”, arī tur viss gāja labi, es pārstāju sūdzēties par neunikālo indeksu.

3. Ja neunikalitāte ir datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot datu bāzi ar nobīdes parametru, kas vienāds ar 2000.

1. Ja problēma ir datu bāzes ielāde, veiciet tālāk norādītās darbības.
1.1. Ja ielādē (izmantojot dt failu) MS SQL Server datu bāzē, tad veidojot datu bāzi, pirms ielādes norādiet datuma nobīdi - 2000.
Ja datu bāze jau ir izveidota ar nobīdi 0, tad izveidojiet jaunu ar 2000.

1.2. Ja ir iespēja strādāt ar datu bāzi faila versijā, tad veiciet Testēšanu un labošanu, kā arī Konfigurācija - Konfigurācijas pārbaude - Konfigurācijas loģiskās integritātes pārbaude + Nepareizu saišu meklēšana.

1.3. Ja nē faila versija, mēģiniet ielādēt no DT klienta-servera versijā ar DB2 (kas ir mazāk prasīga pēc unikalitātes), un pēc tam veiciet testēšanu un labošanu, kā arī Konfigurācija - Konfigurācijas pārbaude - Konfigurācijas loģiskās integritātes pārbaude + Nepareizu saišu atrašana.

1.4. Lai lokalizētu problēmu, varat noteikt tā objekta datus, kura ielāde neizdevās. Lai to izdarītu, sāknēšanas laikā ir jāiespējo izsekošana utilītprogrammā Profiler vai jāiespējo ierakstīšana DBMSSQL un EXCP procesa notikumu žurnālā.

2. Ja neunikalitātes problēma rodas, kad lietotāji strādā:

2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.

2.1.2. Dažreiz, izpildot vaicājumus, rodas kļūda, piemēram:

Šī kļūda rodas tāpēc, ka uzkrāšanas reģistra modulī " Darba laiks organizāciju darbinieki" "Reģistra pārrēķinu" kārtībā, pieprasījumā nav dienesta vārda "ATŠĶIRĪGI".
Kods 1C v 8.x T.i. jābūt:
Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,
. . . . .
Jaunākajos ZUP un UPP laidienos kļūda nerodas, jo tur ir rakstīts "ATŠĶIRĪGI".

2.2. Pēc problemātiskā rādītāja atrašanas no iepriekšējās rindkopas jums jāatrod neunikāls ieraksts.
2.2.1. "Fish" skripts neunikālu ierakstu identificēšanai, izmantojot SQL:
SQL kods S_elect COUNT(*) skaitītājs,<перечисление всех полей соответствующего индекса>no om<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
IR skaitītājs > 1

2.2.2. Piemērs. Kļūdas rādītājs tiek saukts par "_Document140_VT1385_IntKeyIndNG".
Tabulas lauku saraksts:
Dokuments _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _2RRF2 _6 ld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Pirms tālāk norādītās procedūras veikšanas veiciet rezerves kopija datubāzēm.
Palaist programmā MS SQL Server Query Analyzer:
SQL kods S_elect count(*), _Document140_IDRRef, _KeyField
no om _Document140_VT1385
grupēt pēc _Document140_IDRRef, _KeyField
kuru skaits (*) > 1
Izmantojiet to, lai uzzinātu kolonnu _Document140_IDRRef, _KeyField, dublēto ierakstu (id, atslēga) vērtības.

Izmantojot pieprasījumu:
SQL kods S_elect*
no om _Document140_VT1385
kur _Document140_IDRRef = id1 un _KeyField = atslēga1 vai _Document140_IDRRef = id2 un _KeyField = atslēga2 vai ...
apskatiet citu dublēto ierakstu kolonnu vērtības.
Ja abiem ierakstiem ir nozīmīgas vērtības un vērtības atšķiras, mainiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, nosakiet _KeyField (keymax) maksimālo aizņemto vērtību:
SQL kods S_elect max(_KeyField)
no om _Document140_VT1385
kur _Document140_IDRRef = id1
Aizstājiet _KeyField vērtību vienā no dublētajiem ierakstiem ar pareizo:
SQL koda atjauninājums _Document140_VT1385
iestatīt _KeyField = keymax + 1

Šeit _LineNo1386 = ir papildu nosacījums, kas ļauj atlasīt vienu no diviem atkārtotiem ierakstiem.

Ja vienam (vai abiem) no dublētajiem ierakstiem ir acīmredzami nepareiza nozīme, tas ir jānoņem:
SQL koda dzēšana no _Document140_VT1385
kur _Document140_IDRRef = id1 un _LineNo1386 = lineno1
Ja dublētiem ierakstiem visās kolonnās ir vienādas vērtības, jums ir jāatstāj viena no tām:
SQL kods S_elect atšķirīgs *
uz #tmp1
no _Dokuments140_VT1385

Dzēst no _Document140_VT1385
kur _Document140_IDRRef = id1 un _KeyField = atslēga1

I_ievietojiet _dokumentā140_VT1385
S_elect #tmp1

D_rop tabula #tmp1

Aprakstītā procedūra jāveic katram ierakstu dublikātu pārim.

2.2.3. Otrais piemērs:
SQL kods S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
NO _8. atsauces_
GROUP BY _IDRRef, _Apraksts
ARĪ (SKAITS(*) > 1)

2.3.4. Neunikālu ierakstu noteikšanas piemērs, izmantojot vaicājumu 1C:Enterprise:
Kods 1C v 8.x SELECT Directory.Link
NO Directory.Directory AS Katalogs
GROUP BY Directory.Link
KAS DAUDZUMS(*) > 1

Informācija ņemta no vietnes

Kļūda rodas, ja dažiem objektiem, detaļām, apakškontēmām datu bāzē ir NULL vērtība, bet tiem nevar būt šāda vērtība. Un šī kļūda parādās tikai SQL datu bāzēs. Tie. Ja augšupielādējat šādu datu bāzi failā, šīs kļūdas vairs nebūs. Jo Failu datu bāzei ir savas tabulas (kopā 4), un SQL ir savas. Un SQL datu bāze kritiski reaģē uz šādām vērtībām savās tabulās.

Šo problēmu nevar atrisināt ar testēšanu (ne ārējo, ne iekšējo) nevienā datu bāzes versijā (SQL vai failā) un pat ar _1sp_DBReindex procedūru SQL pārvaldniekā, kurai, šķiet, ir jāpārstrukturē tabulas SQL.

Apskatīsim problēmas risinājumu, izmantojot piemēru par pāreju no grāmatvedības 3.0 PROF uz CORP. Pēc pārejas kontam 68.01 ir jauns apakškonts Reģistrācija nodokļu iestādē. Un tad SQL datu bāzēs visi PRO versijā izveidotie dokumenti, kas izmanto šo kontu, netiks pārsūtīti. Parādīsies iepriekš redzamā kļūda. Jo Šis jaunais veco dokumentu apakškonts grāmatojumos tiks rakstīts ar vērtību NULL (lai gan ir jābūt vērtībai Tukšs vai nodokļu iestādei).

Lai labotu šo kļūdu, jums ir jānoņem NULL vērtības, kur tām nevajadzētu būt. Šajā gadījumā dokumentos, kuros tiek izmantota apakškonto Reģistrācija nodokļu iestādē. To var izdarīt, rakstot apstrādi, kas aizstās NULL ar vērtību Tukšs (gatavu apstrādi var lejupielādēt no šī raksta). Dariet to apstrādājot, jo Mēģinājums manuāli mainīt šī apakškonta vērtību dokumentu grāmatojumos rada tādu pašu kļūdu.

Apstrādi NULL aizstāšanai visos Reģistrācijas nodokļu iestādē apakškontaktos var lejupielādēt no šī raksta tālāk.

BET tas nedarbosies, lai aizstātu NULL SQL datu bāzē apstrādes laikā tiks ģenerēta tā pati kļūda. Tāpēc jums ir jādara šādi:

1. Augšupielādējiet dt failā jau strādājošo SQL datu bāzes versiju, kas pārtulkota uz CORP (konfiguratorā Administrācija – Augšupielādēt datu bāzi – atlasiet, kur augšupielādēt datubāzi kā *.dt failu)

2. Augšupielādējiet dt’shnik failu datu bāzē (nevajadzīgā vai iepriekš sagatavotā, tīrā, failu datu bāze, konfiguratorā Administrēšana – Ielādēt datu bāzi – atlasiet iepriekš lejupielādēto dt failu)

3. Veiciet apstrādi failu datu bāzē (tur nebūs kļūdu un visi NULL tiks pareizi nomainīti) (kā veikt apstrādi ir aprakstīts zemāk)

5. Tagad, gluži pretēji, izlādējiet dt failu no failu datu bāzes un ielādējiet to SQL datu bāzē. Tagad, grāmatojot apstrādātos dokumentus, kļūdas neradīsies.

Apstrādājot šo rakstu, tiek atrasti visi dokumenti par norādīto periodu, kurā ir iekļauta apakšlīguma reģistrācija nodokļu iestādē (kas ir redzama CORP versijā), kura vērtība ir NULL. Un aizstāj šo vērtību ar tukšu vērtību.

Apstrādē jānorāda periods, kurā nepieciešams apstrādāt dokumentus (var par visu periodu, kurā tiek glabāti ieraksti datu bāzē) un jānospiež “Aizpildīt tabulas daļa" Pēc tam varat atzīmēt izvēles rūtiņas, lai atzīmētu, kurus dokumentus apstrādāt (var atlasīt visus), un noklikšķiniet uz pogas “Veikt apstrādi”.

Attiecīgi, ja kādam ir tāda pati kļūda, bet NE pēc pārejas uz CORP, bet, piemēram, pēc apmaiņas, kādu datu ielādes, kādas apstrādes veikšanas utt. Pēc tam ir jāidentificē, kur konkrētajā dokumentā/direktorijā ir piešķirta NULL vērtība un jānoņem šī NULL līdzīgā veidā, bet ar savu apstrādi, bet iepriekš aprakstītajā secībā. Atcerieties, ka NULL var būt, tāpat kā dokumentu grāmatojumos, t.sk. ne tikai grāmatvedības, bet arī kaut kur uz dokumenta/uzziņu grāmatiņas veidlapas, kaut kādās detaļās, bet šinī gadījumā laikam pat neatvērsies.

Turklāt, ja šī kļūda jums parādījās, ievietojot dokumentu, pēc tam, kad esat pārsūtījis Bukh KORP failu datubāzi uz SQL (un datu bāze savulaik bija PROF), tas nozīmē, ka tie dokumenti, kas tika izveidoti PROF versijā, tagad ir arī apakškonta reģistrācija nodokļu iestādes NULL vērtībā un SQL datubāze to nepieņem. Un, ielādējot datu bāzi SQL, parādīsies šāda kļūda. Šeit faktiski failu datu bāzē nebūs NULL vērtību, bet SQL savās tabulās ielādēs tieši šādas vērtības. Tāpēc šeit mums ir jāpiespiež SQL datu bāze izveidot šos NULL un pēc tam labot tos failu datu bāzē, taču es nevaru jums pateikt, kā to izdarīt.

Šajā rakstā ir aprakstīts, kā rīkoties, ja, strādājot ar 1C:Enterprise 8.1, tiek parādīts ziņojums, kurā ir šādas rindas:

Objektā nevar ievietot atslēgas rindas dublikātu

Unikālā indeksā tika mēģināts ievietot neunikālu vērtību.

Kas ir indekss?

Indeksi ir struktūra, kas ļauj ātri piekļūt tabulas rindām, pamatojoties uz vienas vai vairāku tās kolonnu vērtībām.
Indeksā ir atslēgas, kas izveidotas no vienas vai vairākām tabulas vai skata kolonnām, un norādes, kas norāda uz norādīto datu glabāšanas vietu.
Indeksi samazina datu apjomu, kas jālasa, lai atgrieztu rezultātu kopu.

Lai gan indekss ir saistīts ar konkrētu tabulas kolonnu (vai kolonnām), tas joprojām ir atsevišķs datu bāzes objekts.

Tabulu indeksi 1C:Enterprise datubāzē tiek izveidoti netieši, veidojot konfigurācijas objektus, kā arī veicot noteiktus konfigurācijas objektu iestatījumus.

Indeksu fiziskā būtība programmā MS SQL Server 2005.

Fiziski dati tiek saglabāti uz 8Kb lapām. Tūlīt pēc izveides, kamēr tabulai nav indeksu, tabula izskatās kā datu kaudze. Ierakstiem nav noteikta uzglabāšanas secības.
Kad vēlaties piekļūt datiem, SQL Server radīs galda skenēšana(tabulas skenēšana). SQL Server skenē visu tabulu, lai atrastu meklējamos ierakstus.
No šejienes kļūst skaidras indeksu pamatfunkcijas:
— datu piekļuves ātruma palielināšana,
— atbalsts datu unikalitātei.

Neskatoties uz to priekšrocībām, indeksiem ir arī vairāki trūkumi. Pirmais ir indeksi aizņem papildu vietu diskā un iekšā RAM. Katru reizi, kad veidojat indeksu, atslēgas tiek saglabātas dilstošā vai augošā secībā, kurai var būt daudzlīmeņu struktūra. Un jo lielāka/garāka atslēga, jo lielāks izmērs rādītājs. Otrs trūkums ir operācijas palēninās ierakstu ievietošana, atjaunināšana un dzēšana.
MS SQL Server 2005 vidē tiek ieviesti vairāku veidu indeksi:

negrupēti indeksi;
klasterizēti (vai klasterizēti) indeksi;
unikālie indeksi;
indeksi ar iekļautām kolonnām
indeksēti skati
pilns teksts

Unikāls indekss

Indeksētās kolonnas vērtību unikalitāti garantē unikāli indeksi. Ja tie ir klāt, serveris neļaus jums ievietot jaunu vai mainīt esošo vērtību lai šīs darbības rezultātā kolonnā parādītos divas identiskas vērtības.
Unikāls indekss ir sava veida papildinājums, un to var ieviest gan grupētiem, gan negrupētiem indeksiem. Vienai tabulai var būt viens unikāls klasterizēts indekss un daudzi unikāli negrupēti indeksi.
Unikālie indeksi jādefinē tikai tad, ja tie patiešām ir nepieciešami. Lai kolonnā nodrošinātu datu integritāti, varat definēt UNIKĀLĀ vai PRIMARY KEY integritātes ierobežojumu, nevis izmantot unikālus indeksus. To izmantošana tikai datu integritātes nodrošināšanai ir datu bāzes vietas izniekošana. Turklāt CPU laiks tiek tērēts arī to uzturēšanai.

1C: Enterprise 8.1, sākot no versijas 8.1, aktīvi izmanto klasterētus unikālus indeksus. Tas nozīmē, ka, konvertējot no 8.0 vai migrējot no 8.1.7, var tikt parādīta neunikāla indeksa kļūda.

Ja neunikalitāte slēpjas datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot datu bāzi ar nobīdes parametru, kas vienāds ar 2000.

Ko darīt?

1. Ja problēma ir datu bāzes ielāde, veiciet tālāk norādītās darbības.

1.1. Ja veicat ielādi (izmantojot dt failu) MS SQL Server datu bāzē, tad, veidojot datu bāzi pirms ielādes, norādiet datuma nobīdi - 2000.

Ja datu bāze jau ir izveidota ar nobīdi 0, tad izveidojiet jaunu ar 2000.

1.3. Ja faila versijas nav, mēģiniet ielādēt no DT klienta-servera versijā ar DB2 (kas ir mazāk prasīga pēc unikalitātes), un pēc tam veiciet testēšanu un labošanu, kā arī konfigurāciju - pārbaudiet konfigurāciju - pārbaudiet konfigurācijas loģisko integritāti. + Meklēt nederīgas atsauces.

1.5. Ja mezgls (apmaiņas plāni) ir pieejams, veiciet apmaiņu. Pirms apmaiņas varat arī papildus aizpildīt 2.3.5. punktu

2. Ja neunikalitātes problēma rodas, kad lietotāji strādā:

2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.

2.1.2. Dažreiz, izpildot vaicājumus, rodas kļūda, piemēram:

Tie. jābūt:

Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,

Jaunākajos ZUP un UPP laidienos kļūda nerodas, jo tur ir rakstīts "ATŠĶIRĪGI".

2.2. Pēc problemātiskā rādītāja atrašanas no iepriekšējās rindkopas jums jāatrod neunikāls ieraksts.

2.2.1. "Fish" skripts neunikālu ierakstu identificēšanai, izmantojot SQL:
SELECT COUNT(*) Skaitītājs,<перечисление всех полей соответствующего индекса>no<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
IR skaitītājs > 1

2.2.2. Piemērs. Kļūdas rādītājs tiek saukts par "_Document140_VT1385_IntKeyIndNG".

Tabulas lauku saraksts:

dokuments ld1393_RRRef, _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RR_2REf f, _Fld2226 1_RRRef

Pirms tālāk norādītās darbības veikšanas, lūdzu, dublējiet savu datubāzi.
Palaist programmā MS SQL Server Query Analyzer:

atlasiet skaitu (*), _Document140_IDRRef, _KeyField
no _Dokuments140_VT1385
grupēt pēc _Document140_IDRRef, _KeyField
kuru skaits (*) > 1

Izmantojiet to, lai uzzinātu kolonnu _Document140_IDRRef, _KeyField, dublēto ierakstu (id, atslēga) vērtības.

Izmantojot pieprasījumu:

izvēlieties *
no _Dokuments140_VT1385
vai _Document140_IDRRef = id2 un _KeyField = atslēga2 vai…

apskatiet citu dublēto ierakstu kolonnu vērtības.

Ja abiem ierakstiem ir nozīmīgas vērtības un vērtības atšķiras, mainiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, nosakiet _KeyField (keymax) maksimālo aizņemto vērtību:

atlasīt maks.(_KeyField)
no _Dokuments140_VT1385
kur _Document140_IDRRef = id1

Aizstājiet _KeyField vērtību vienā no dublētajiem ierakstiem ar pareizo:

update_Document140_VT1385
iestatīt _KeyField = keymax + 1

Šeit _LineNo1386 = ir papildu nosacījums, kas ļauj atlasīt vienu no diviem atkārtotiem ierakstiem.

Ja vienam (vai abiem) no dublētajiem ierakstiem ir acīmredzami nepareiza nozīme, tas ir jānoņem:

kur _Document140_IDRRef = id1 un _LineNo1386 = lineno1

Ja dublikātu ierakstiem visās kolonnās ir vienādas vērtības, jums ir jāatstāj viena no tām:

atlasīt atsevišķus *
uz #tmp1
no _Dokuments140_VT1385
kur _Document140_IDRRef = id1 un _KeyField = atslēga1

dzēst no _Document140_VT1385
kur _Document140_IDRRef = id1 un _KeyField = atslēga1

ievietojiet _Document140_VT1385
atlasiet #tmp1

nolaižamā tabula #tmp1

Aprakstītā procedūra jāveic katram ierakstu dublikātu pārim.

2.2.3. Otrais piemērs:

SELECT COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
NO _8. atsauces_
GROUP BY _IDRRef, _Apraksts
ARĪ (SKAITS(*) > 1)

2.3.4. Neunikālu ierakstu noteikšanas piemērs, izmantojot vaicājumu 1C:Enterprise:

vai grāmatvedībai

IZVĒLIES
Apakšvaicājums.Periods,
Apakšvaicājums.Ierakstītājs,
<измерения>,
SUM(Subquery.Number of Records) AS Ierakstu skaits
NO
(IZVĒLIES
Pašpietiekams periods AS periods,
Pašnodrošinošs.Registrar AS reģistrators,
<измерения>,
1 AS Ierakstu skaits
NO
Grāmatvedības reģistrs Self-supporting AS Self-supporting) AS Apakšvaicājums

GROUP BY
Apakšvaicājums.Periods,
Apakšvaicājums.Ierakstītājs,
<измерения>

ŅEMOT
SUM(Apakšvaicājums.Ierakstu skaits) > 1

2.3.5. Padarīt apakšindeksu par unikālu. Skriptējiet indeksu, izmantojot Management Studio.

2.3.6. Īpašs gadījums, veicot apmaiņu RDB. Kļūda rodas “palīgtabulās, kas saistītas ar kopsummu vai analītikas aprēķināšanu. Piemēram:

Kļūda, izsaucot konteksta metodi (rakstīšana): unikālā rādītājā tiek mēģināts ievietot neunikālu vērtību:
Microsoft OLE DB nodrošinātājs SQL serverim: nevar ievietot dublikātu atslēgu rindu objektā "dbo._AccntRegED10319" ar unikālu indeksu "_Accnt10319_ByPeriod_TRNRN".
HRESULT=80040E2F, SQLSrvr: kļūdas stāvoklis=1, smaguma pakāpe=E, native=2601, rinda=1

Šādā gadījumā pirms ielādes izslēdziet kopsummas izmantošanu, ielādējiet ziņojumu, iespējojiet kopējo summu izmantošanu un pārrēķiniet.

Jūs esat saņēmis ziņojumu ar šādām rindām:
Microsoft OLE DB nodrošinātājs SQL serverim: UNIKĀLA INDEKSA IZVEIDE ir pārtraukta, jo indeksa ID tika atrasta atslēgas dublikāts
vai
Objektā nevar ievietot dublikātu atslēgas rindu
vai
Unikālā indeksā tika mēģināts ievietot neunikālu vērtību.

Risinājumi:

2. 1) Izmantojot Management Studio 2005, es ģenerēju izveides skriptu, lai izveidotu indeksu, kas bija kļūdains, un saglabāju to failā.
2) Manuāli nogalināja jamb indeksu no tabulas _AccumRgTn19455
3) Uzsākts pieprasījums patīk
SQL kods S_elect count(*), index_fields
NO AccumRgTn19455
GROUP BY index_field
ARĪ SKAITĀ(*)>1
Pēc indeksa nogalināšanas man tika parādīti 15 ierakstu dublikāti, lai gan pirms 2. darbības vaicājums neko neatgrieza.
4) Es izgāju cauri visiem ierakstiem un manuāli notīrīju dublikātus. Patiesībā es izmantoju arī “Pārskata struktūras” apstrādi, lai saprastu, ar ko man ir darīšana. Izrādījās, ka tabulā _AccumRgTn19455 glabājas uzkrājumu reģistrs “Produktu izlaide (nodokļu uzskaite)”. Es arī pastrādāju ar sql vaicājumiem, identificēju 15 neunikālus dokumentus un pēc visu darbību pabeigšanas 1C pārbaudīju, vai šie dokumenti tiek apstrādāti normāli, bez kļūdām. Protams, nevajadzētu tīrīt galdus tikai pēc nejaušības principa: ir svarīgi saprast, kas tiek tīrīts un kā tas var izrādīties.
5) Uzsākts pieprasījums izveidot indeksu, kas tika saglabāts failā.
6) Pārslēdzu datu bāzi uz viena lietotāja režīmu un palaidu dbcc checkdb - šoreiz kļūdas netika ģenerētas.
7) Pārslēdza bāzi atpakaļ uz viena lietotāja režīmu.
Tas tā... problēma ir pārvarēta. Nu jau 1C es palaidu “Testēšana un labošana”, arī tur viss noritēja labi, pārstāju sūdzēties par neunikālo indeksu.

3. Ja neunikalitāte ir datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot datu bāzi ar nobīdes parametru, kas vienāds ar 2000.

2. Ja neunikalitātes problēma rodas, kad lietotāji strādā:

2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.

2.1.2. Dažreiz, izpildot vaicājumus, rodas kļūda, piemēram:

Šī kļūda rodas tādēļ, ka uzkrāšanas reģistra modulī “Organizāciju darbinieku darba laiks” procedūrā “Reģistra pārrēķini” pieprasījumā nav iekļauts dienesta vārds “ATŠĶIRĪGI”.
Kods 1C v 8.x T.i. jābūt:
Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,
. . . . .
Jaunākajos ZUP un UPP laidienos kļūda nerodas, jo tur ir rakstīts "ATŠĶIRĪGI".

2.2. Pēc problemātiskā rādītāja atrašanas no iepriekšējās rindkopas jums jāatrod neunikāls ieraksts.
2.2.1. "Fish" skripts neunikālu ierakstu identificēšanai, izmantojot SQL:
SQL kods S_elect COUNT(*) skaitītājs,<перечисление всех полей соответствующего индекса>no<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
IR skaitītājs > 1

2.2.2. Piemērs. Kļūdas rādītājs tiek saukts par "_Document140_VT1385_IntKeyIndNG".
Tabulas lauku saraksts:
Dokuments _Fld1393_ RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _2RRF2 _6 ld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Pirms tālāk norādītās darbības veikšanas, lūdzu, dublējiet savu datubāzi.
Palaist programmā MS SQL Server Query Analyzer:
SQL kods S_elect count(*), _Document140_IDRRef, _KeyField
no _Dokuments140_VT1385
grupēt pēc _Document140_IDRRef, _KeyField
kuru skaits (*) > 1
Izmantojiet to, lai uzzinātu kolonnu _Document140_IDRRef, _KeyField, dublēto ierakstu (id, atslēga) vērtības.

Izmantojot pieprasījumu:
SQL kods S_elect*
no _Dokuments140_VT1385
vai _Document140_IDRRef = id2 un _KeyField = atslēga2 vai ...
apskatiet citu dublēto ierakstu kolonnu vērtības.
Ja abiem ierakstiem ir nozīmīgas vērtības un vērtības atšķiras, mainiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, nosakiet _KeyField (keymax) maksimālo aizņemto vērtību:
SQL kods S_elect max(_KeyField)
no _Dokuments140_VT1385
kur _Document140_IDRRef = id1
Aizstājiet _KeyField vērtību vienā no dublētajiem ierakstiem ar pareizo:
SQL koda atjauninājums _Document140_VT1385
iestatīt _KeyField = keymax + 1
Šeit _LineNo1386 = ir papildu nosacījums, kas ļauj atlasīt vienu no diviem atkārtotiem ierakstiem.

Dzēst no _Document140_VT1385
kur _Document140_IDRRef = id1 un _KeyField = atslēga1

I_ievietojiet _dokumentā140_VT1385
S_elect #tmp1

D_rop tabula #tmp1

Aprakstītā procedūra jāveic katram ierakstu dublikātu pārim.

2.2.3. Otrais piemērs:
SQL kods S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
NO _8. atsauces_
GROUP BY _IDRRef, _Apraksts
ARĪ (SKAITS(*) > 1)

Saistītie raksti