Unikālā indeksā tika mēģināts ievietot neunikālu vērtību. Kļūda: mēģinājums ievietot neunikālu vērtību unikālajā indeksā: microsoft sql server. pārejot no grāmatvedības prof uz corp un ne tikai Noņemiet neunikālos indeksus 1s 8 failā
Jūs esat saskāries ar 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ājuma iespējas:
1. SQL Server pārvaldības studijā mēs fiziski iznīcinām neveiksmīgo indeksu (manā gadījumā tas bija indekss grāmatvedības reģistra kopsummu tabulā). 1C mēs izplatīsim bojātus dokumentus. Pārbaudes un labošanas režīmā atzīmējiet izvēles rūtiņas tabulu atkārtotai indeksēšanai + kopsummu pārrēķiniem. 1C bez kļūdām atjauno indeksu. Mēs veicam iepriekš neizdevušos dokumentus.
2.
1) Ar Management Studio 2005 palīdzību es ģenerēju izveides skriptu indeksa izveidei, kas bija kļūdains, un saglabāju to failā.
2) Manuāli nogalināja 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 iznīcināšanas es parādīju 15 dublētus ierakstus, lai gan pirms 2. darbības vaicājums neko neatgrieza.
4) Es izskatīju visus ierakstus un manuāli notīrīju dublikātus. Patiesībā es izmantoju arī "Pārskatu struktūras" apstrādi, lai saprastu, ar ko vispār nodarbojos. Izrādījās, ka tabulā _AccumRgTn19455 glabājas uzkrājumu reģistrs "Produktu izlaide (nodokļu uzskaite)". Es arī papētīju sql vaicājumus, identificēju 15 neunikālus dokumentus un pēc visu darbību veikšanas 1C pārbaudīju, vai šie dokumenti tiek apstrādāti normāli, bez kļūdām. Protams, nav vērts tīrīt galdus nejauši tāpat vien: ir svarīgi saprast, kas tiek tīrīts un par ko tas var pārvērsties.
5) Uzsākts vaicājums, lai izveidotu indeksu, kas tika saglabāts failā.
6) Pārslēdzu datubāzi uz viena lietotāja režīmu un palaidu dbcc checkdb - šoreiz kļūdu nebija.
7) Pārsūtīja bāzi atpakaļ uz viena lietotāja režīmu.
Tas arī viss... problēma ir pārvarēta. Nu pat 1C palaidu "Testēšanu un labošanu", arī tur viss gāja labi, pārstāja bļaustīties par neunikālu indeksu.
3. Ja neunikalitāte ir datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot bāzi ar nobīdes parametru 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ējat (izmantojot dt-failu) MS SQL Server datu bāzē, tad, veidojot datu bāzi, pirms ielādes norādiet datuma nobīdi - 2000.
Ja 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 faila varianta nav, mēģiniet ielādēt no DT uz DB2 klienta/servera variantu (kas ir mazāk izvēlīgs attiecībā uz unikalitāti) un pēc tam palaidiet Test and Fix un Configuration — Configuration Check — Configuration Logical Integrity Check + Bad Reference Finder.
1.4. Lai lokalizētu problēmu, varat noteikt tā objekta datus, kura ielāde neizdevās. Lai to izdarītu, utilītprogrammā Profiler ir jāiespējo izsekošana sāknēšanas laikā vai jāiespējo reģistrēšana DBMSSQL un EXCP procesa notikumu žurnālā.
2. Ja neunikalitātes problēma izpaužas lietotāju darba laikā:
2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.
2.1.2. Dažreiz pieprasījumu izpildes laikā rodas kļūda, piemēram:
Šī kļūda rodas tādēļ, ka uzkrāšanas reģistra modulī "Organizāciju darbinieku darba laiks" kārtībā "Pārrēķinu reģistrs" pieprasījumā nav dienesta vārda "ATŠĶIRĪGI".
Kods 1C v 8.x T.i. vajadzētu būt:
Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,
. . . . .
Jaunākajos ZUP un UPP izlaidumos kļūda nerodas, jo. tas saka "DAŽĀDI".
2.2. Pēc problemātiskā indeksa atrašanas no iepriekšējā punkta jāatrod neunikāls ieraksts.
2.2.1. "Fish" skripts neunikālu ierakstu definēš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:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef,9F_lTY1,9F_lTY1,9F_lTY1,9FlTY , _Fld1393_RR Ref _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Pirms tālāk norādītās darbības, 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, ierakstu dublikātu (id, atslēga) vērtības.
Ar 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 šīs vērtības atšķiras, fiksējiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, definējiet _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 dublētiem ierakstiem.
Ja vienam (vai abiem) no dublētajiem ierakstiem ir acīmredzami nepareiza vērtība, tā ir jānoņem:
SQL koda dzēšana no _Document140_VT1385
kur _Document140_IDRRef = id1 un _LineNo1386 = lineno1
Ja dublikātu ierakstiem visās kolonnās ir vienādas vērtības, tad viena no tām ir jāatstāj:
SQL kods S_elect atšķirīgs *
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
I_ievietojiet _Dokumentā140_VT1385
S_elect #tmp1
D_rop tabula #tmp1
Aprakstītā procedūra jāveic katram dublēto ierakstu 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 definēšanas piemērs, izmantojot vaicājumu 1C:Enterprise:
Kods 1C v8.x IZVĒLIES rokasgrāmatu. Saite
NO direktorija. Katalogs AS Katalogs
GROUP BY
KAS DAUDZUMS(*) > 1
Šajā rakstā ir aprakstīts, kā rīkoties, ja, strādājot ar 1C:Enterprise 8.1, jūs saskaraties ar ziņojumu, 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ī ar noteiktiem konfigurācijas objektu iestatījumiem.
Indeksu fiziskā būtība programmā MS SQL Server 2005.
Fiziskie 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 pasūtījuma.
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:
- palielināt datu piekļuves ātrumu,
- atbalsts datu unikalitātei.
Neskatoties uz priekšrocībām, indeksiem ir arī vairāki trūkumi. Pirmais ir indeksi. aizņem papildu vietu diskā un RAM. Katru reizi, kad veidojat indeksu, atslēgas tiek saglabātas augošā vai dilstošā secībā, ko var slāņot. Un jo lielāka/garāka atslēga, jo lielāks indeksa izmērs. Otrs trūkums ir operācijas palēninās ierakstu ievietošana, atjaunināšana un dzēšana.
MS SQL Server 2005 vidē ir ieviesti vairāki indeksu veidi:
- 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
Vērtību unikalitāti indeksētā kolonnā garantē unikāli indeksi. Ja tās ir, serveris neļaus ievietot jaunu vērtību vai mainīt esošo vērtību tā, ka šīs darbības rezultātā kolonnā parādās 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 un daudzi unikāli negrupēti indeksi.
Unikālie indeksi jādefinē tikai tad, ja tas ir absolūti nepieciešams. Lai kolonnā nodrošinātu datu integritāti, unikālo indeksu izmantošanas vietā varat definēt UNIKĀLĀ vai PRIMARY KEY integritātes ierobežojumu. To izmantošana tikai datu integritātes nodrošināšanai ir vietas izšķiešana datu bāzē. 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, varat iegūt neunikālu indeksa kļūdu.
Ja neunikalitāte ir datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot 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 ielādējat (izmantojot dt-failu) MS SQL Server datu bāzē, tad, veidojot datu bāzi, pirms ielādes norādiet datuma nobīdi - 2000.
Ja 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 faila varianta nav, mēģiniet ielādēt no DT uz DB2 klienta/servera variantu (kas ir mazāk izvēlīgs attiecībā uz unikalitāti) un pēc tam palaidiet Test and Fix un pēc tam Konfigurācija - Konfigurācijas pārbaude - Konfigurācijas loģiskās integritātes pārbaude + Pārbaudīt, vai nav sliktas atsauces. .
1.4. Lai lokalizētu problēmu, varat noteikt tā objekta datus, kura ielāde neizdevās. Lai to izdarītu, utilītprogrammā Profiler ir jāiespējo izsekošana sāknēšanas laikā vai jāiespējo reģistrēšana DBMSSQL un EXCP procesa notikumu žurnālā.
1.5. Ja mezgls ir pieejams (apmaiņas plāni), veiciet apmaiņu. Varat arī papildus veikt 2.3.5. punktu pirms apmaiņas
2. Ja neunikalitātes problēma izpaužas lietotāju darba laikā:
2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.
2.1.2. Dažreiz pieprasījumu izpildes laikā rodas kļūda, piemēram:
Šī kļūda rodas tādēļ, ka uzkrāšanas reģistra modulī "Organizāciju darbinieku darba laiks" kārtībā "Pārrēķinu reģistrs" pieprasījumā nav dienesta vārda "ATŠĶIRĪGI".
Tie. vajadzētu būt:
Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,
Jaunākajos ZUP un UPP izlaidumos kļūda nerodas, jo. tas saka DAŽĀDI.
2.2. Pēc problemātiskā indeksa atrašanas no iepriekšējā punkta jāatrod neunikāls ieraksts.
2.2.1. "Fish" skripts neunikālu ierakstu definēš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:
Document140_IDRRef _KeyField _LineNo1386 _Fld1387 _Fld1388 _Fld1389 _Fld1390 _Fld1391RRef _Fld1392RRef _Fld1394,
Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RF_lRef21,2RT2,6 Atsauce, _Fld222 61_RRRef
Pirms tālāk norādītās darbības, 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, ierakstu dublikātu (id, atslēga) vērtības.
Ar pieprasījumu:
atlasīt*
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 šīs vērtības atšķiras, fiksējiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, definējiet _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 dublētiem ierakstiem.
Ja vienam (vai abiem) no dublētajiem ierakstiem ir acīmredzami nepareiza vērtība, tā 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, tad viena no tām ir jāatstāj:
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 dublēto ierakstu 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 definēšanas piemērs, izmantojot vaicājumu 1C:Enterprise:
vai grāmatvedībai
IZVĒLIES
Apakšvaicājums.Periods,
Apakšvaicājums. Reģistrs,
<измерения>,
SUM(Subquery.Number of Records) AS Ierakstu skaits
NO
(IZVĒLIES
Pašpietiekams. Periods AS periods,
Pašpietiekams. Reģistratūra AS Reģistratūra,
<измерения>,
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. Reģistrs,
<измерения>
Ņ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 apmaiņā RDB. Kļūda attiecas uz "palīg" tabulām, kas saistītas ar kopsummu vai analītikas aprēķināšanu. Piemēram:
Kļūda, izsaucot konteksta metodi (rakstīšana): unikālā indeksā mēģiniet 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 kopsummu izmantošanu, lejupielādējiet ziņojumu, ieslēdziet kopsummu izmantošanu un pārrēķiniet.
Jūs esat saskāries ar 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ājuma iespējas:
1. SQL Server pārvaldības studijā mēs fiziski iznīcinām neveiksmīgo indeksu (manā gadījumā tas bija indekss grāmatvedības reģistra kopsummu tabulā). 1C mēs izplatīsim bojātus dokumentus. Pārbaudes un labošanas režīmā atzīmējiet izvēles rūtiņas tabulu atkārtotai indeksēšanai + kopsummu pārrēķiniem. 1C bez kļūdām atjauno indeksu. Mēs veicam iepriekš neizdevušos dokumentus.
2.
1) Ar Management Studio 2005 palīdzību es ģenerēju izveides skriptu indeksa izveidei, kas bija kļūdains, un saglabāju to failā.
2) Manuāli nogalināja 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 es parādīju 15 dublētus ierakstus, lai gan pirms 2. darbības vaicājums neko neatgrieza.
4) Es izskatīju visus ierakstus un manuāli notīrīju dublikātus. Patiesībā es izmantoju arī "Pārskatu struktūras" apstrādi, lai saprastu, ar ko vispār nodarbojos. Izrādījās, ka tabulā _AccumRgTn19455 glabājas uzkrājumu reģistrs "Produktu izlaide (nodokļu uzskaite)". Es arī papētīju sql vaicājumus, identificēju 15 neunikālus dokumentus un pēc visu darbību veikšanas 1C pārbaudīju, vai šie dokumenti tiek apstrādāti normāli, bez kļūdām. Protams, nav vērts tīrīt galdus nejauši tāpat vien: ir svarīgi saprast, kas tiek tīrīts un par ko tas var pārvērsties.
5) Uzsākts vaicājums, lai izveidotu indeksu, kas tika saglabāts failā.
6) Pārslēdzu datubāzi uz viena lietotāja režīmu un palaidu dbcc checkdb - šoreiz kļūdu nebija.
7) Pārsūtīja bāzi atpakaļ uz viena lietotāja režīmu.
Tas arī viss... problēma ir pārvarēta. Nu pat 1C palaidu "Testēšanu un labošanu", arī tur viss gāja labi, pārstāja bļaustīties par neunikālu indeksu.
3. Ja neunikalitāte ir datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot bāzi ar nobīdes parametru 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ējat (izmantojot dt-failu) MS SQL Server datu bāzē, tad, veidojot datu bāzi, pirms ielādes norādiet datuma nobīdi - 2000.
Ja 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 faila varianta nav, mēģiniet ielādēt no DT uz DB2 klienta/servera variantu (kas ir mazāk izvēlīgs attiecībā uz unikalitāti) un pēc tam palaidiet Test and Fix un Configuration — Configuration Check — Configuration Logical Integrity Check + Bad Reference Finder.
1.4. Lai lokalizētu problēmu, varat noteikt tā objekta datus, kura ielāde neizdevās. Lai to izdarītu, utilītprogrammā Profiler ir jāiespējo izsekošana sāknēšanas laikā vai jāiespējo reģistrēšana DBMSSQL un EXCP procesa notikumu žurnālā.
2. Ja neunikalitātes problēma izpaužas lietotāju darba laikā:
2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.
2.1.2. Dažreiz pieprasījumu izpildes laikā rodas kļūda, piemēram:
Šī kļūda rodas tādēļ, ka uzkrāšanas reģistra modulī "Organizāciju darbinieku darba laiks" kārtībā "Pārrēķinu reģistrs" pieprasījumā nav dienesta vārda "ATŠĶIRĪGI".
Kods 1C v 8.x T.i. vajadzētu būt:
Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,
. . . . .
Jaunākajos ZUP un UPP izlaidumos kļūda nerodas, jo. tas saka "DAŽĀDI".
2.2. Pēc problemātiskā indeksa atrašanas no iepriekšējā punkta jāatrod neunikāls ieraksts.
2.2.1. "Fish" skripts neunikālu ierakstu definēš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:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef,9F_lTY1,9F_lTY1,9F_lTY1,9FlTY , _Fld1393_RR Ref _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Pirms tālāk norādītās darbības, lūdzu, dublējiet savu datubāzi.
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, ierakstu dublikātu (id, atslēga) vērtības.
Ar 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 šīs vērtības atšķiras, fiksējiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, definējiet _KeyField(keymax) maksimālo aizņemto vērtību:
SQL kods S_elect max(_KeyField)
no om _Document140_VT1385
wh ere_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 dublētiem ierakstiem.
Ja vienam (vai abiem) no dublētajiem ierakstiem ir acīmredzami nepareiza vērtība, tā ir jānoņem:
SQL koda dzēšana no _Document140_VT1385
kur _Document140_IDRRef = id1 un _LineNo1386 = lineno1
Ja dublikātu ierakstiem visās kolonnās ir vienādas vērtības, tad viena no tām ir jāatstāj:
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 dublēto ierakstu 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 definēšanas piemērs, izmantojot vaicājumu 1C:Enterprise:
Kods 1C v8.x IZVĒLIES rokasgrāmatu. Saite
NO direktorija. Katalogs AS Katalogs
GROUP BY
KAS DAUDZUMS(*) > 1
Informācija ņemta no vietnes
Jūs esat saskāries ar 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ājuma iespējas:
1. SQL Server pārvaldības studijā mēs fiziski iznīcinām neveiksmīgo indeksu (manā gadījumā tas bija indekss grāmatvedības reģistra kopsummu tabulā). 1C mēs izplatīsim bojātus dokumentus. Pārbaudes un labošanas režīmā atzīmējiet izvēles rūtiņas tabulu atkārtotai indeksēšanai + kopsummu pārrēķiniem. 1C bez kļūdām atjauno indeksu. Mēs veicam iepriekš neizdevušos dokumentus.
2.
1) Ar Management Studio 2005 palīdzību es ģenerēju izveides skriptu indeksa izveidei, kas bija kļūdains, un saglabāju to failā.
2) Manuāli nogalināja 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 iznīcināšanas es parādīju 15 dublētus ierakstus, lai gan pirms 2. darbības vaicājums neko neatgrieza.
4) Es izskatīju visus ierakstus un manuāli notīrīju dublikātus. Patiesībā es izmantoju arī "Pārskatu struktūras" apstrādi, lai saprastu, ar ko vispār nodarbojos. Izrādījās, ka tabulā _AccumRgTn19455 glabājas uzkrājumu reģistrs "Produktu izlaide (nodokļu uzskaite)". Es arī papētīju sql vaicājumus, identificēju 15 neunikālus dokumentus un pēc visu darbību veikšanas 1C pārbaudīju, vai šie dokumenti tiek apstrādāti normāli, bez kļūdām. Protams, nav vērts tīrīt galdus nejauši tāpat vien: ir svarīgi saprast, kas tiek tīrīts un par ko tas var pārvērsties.
5) Uzsākts vaicājums, lai izveidotu indeksu, kas tika saglabāts failā.
6) Pārslēdzu datubāzi uz viena lietotāja režīmu un palaidu dbcc checkdb - šoreiz kļūdu nebija.
7) Pārsūtīja bāzi atpakaļ uz viena lietotāja režīmu.
Tas arī viss... problēma ir pārvarēta. Nu pat 1C palaidu "Testēšanu un labošanu", arī tur viss gāja labi, pārstāja bļaustīties par neunikālu indeksu.
3. Ja neunikalitāte ir datumos ar nulles vērtībām, tad problēma tiek atrisināta, izveidojot bāzi ar nobīdes parametru 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ējat (izmantojot dt-failu) MS SQL Server datu bāzē, tad, veidojot datu bāzi, pirms ielādes norādiet datuma nobīdi - 2000.
Ja 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 faila varianta nav, mēģiniet ielādēt no DT uz DB2 klienta/servera variantu (kas ir mazāk izvēlīgs attiecībā uz unikalitāti) un pēc tam palaidiet Test and Fix un Configuration — Configuration Check — Configuration Logical Integrity Check + Bad Reference Finder.
1.4. Lai lokalizētu problēmu, varat noteikt tā objekta datus, kura ielāde neizdevās. Lai to izdarītu, utilītprogrammā Profiler ir jāiespējo izsekošana sāknēšanas laikā vai jāiespējo reģistrēšana DBMSSQL un EXCP procesa notikumu žurnālā.
2. Ja neunikalitātes problēma izpaužas lietotāju darba laikā:
2.1. Atrodiet problemātisko pieprasījumu, izmantojot 1.4. punktā norādīto metodi.
2.1.2. Dažreiz pieprasījumu izpildes laikā rodas kļūda, piemēram:
Šī kļūda rodas tādēļ, ka uzkrāšanas reģistra modulī "Organizāciju darbinieku darba laiks" kārtībā "Pārrēķinu reģistrs" pieprasījumā nav dienesta vārda "ATŠĶIRĪGI".
Kods 1C v 8.x T.i. vajadzētu būt:
Pieprasījums = jauns pieprasījums(
"IZVĒLIES DAŽĀDU
| Pamata. Individuāli,
. . . . .
Jaunākajos ZUP un UPP izlaidumos kļūda nerodas, jo. tas saka "DAŽĀDI".
2.2. Pēc problemātiskā indeksa atrašanas no iepriekšējā punkta jāatrod neunikāls ieraksts.
2.2.1. "Fish" skripts neunikālu ierakstu definēš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:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1392RRef,9F_lTY1,9F_lTY1,9F_lTY1,9FlTY , _Fld1393_RR Ref _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Pirms tālāk norādītās darbības, 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, ierakstu dublikātu (id, atslēga) vērtības.
Ar 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 šīs vērtības atšķiras, fiksējiet _KeyField vērtību, lai tā būtu unikāla. Lai to izdarītu, definējiet _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 dublētiem ierakstiem.
Ja vienam (vai abiem) no dublētajiem ierakstiem ir acīmredzami nepareiza vērtība, tā ir jānoņem:
SQL koda dzēšana no _Document140_VT1385
kur _Document140_IDRRef = id1 un _LineNo1386 = lineno1
Ja dublikātu ierakstiem visās kolonnās ir vienādas vērtības, tad viena no tām ir jāatstāj:
SQL kods S_elect atšķirīgs *
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
I_ievietojiet _Dokumentā140_VT1385
S_elect #tmp1
D_rop tabula #tmp1
Aprakstītā procedūra jāveic katram dublēto ierakstu 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 definēšanas piemērs, izmantojot vaicājumu 1C:Enterprise:
Kods 1C v8.x IZVĒLIES rokasgrāmatu. Saite
NO direktorija. Katalogs AS Katalogs
GROUP BY
KAS DAUDZUMS(*) > 1
