3.0 60.59 սխալ՝ ոչ եզակի արժեք տեղադրելիս: Փորձ է արվել եզակի ինդեքսում ոչ եզակի արժեք մտցնել: Ինչ է ինդեքսը

Դուք ստացել եք հաղորդագրություն, որը պարունակում է տողեր.
Microsoft OLE DB մատակարար SQL Server-ի համար. CREATE UNIQUE INDEX դադարեցվել է, քանի որ ինդեքսի ID-ի համար կրկնօրինակ բանալի է գտնվել
կամ
Հնարավոր չէ I_insert կրկնօրինակ հիմնական տող օբյեկտում
կամ
Փորձ է արվել եզակի ինդեքսում ոչ եզակի արժեք մտցնել:

Լուծումներ:

1. SQL Server-ի կառավարման ստուդիայում մենք ֆիզիկապես ոչնչացնում ենք անսարք ինդեքսը (իմ դեպքում դա ինդեքս էր հաշվապահական ռեգիստրի գումարների աղյուսակում): 1C-ում մենք կտարածենք անսարք փաստաթղթերը։ Փորձարկման և ուղղման ռեժիմում ստուգեք աղյուսակի վերաինդեքսավորման + գումարների վերահաշվարկի վանդակները: 1C-ը վերստեղծում է ինդեքսը առանց սխալի: Մենք իրականացնում ենք նախկինում ձախողված փաստաթղթեր.

2. 1) Օգտագործելով Management Studio 2005-ը, ես ստեղծեցի ստեղծել սկրիպտ՝ ինդեքս ստեղծելու համար, որը սխալ էր, և այն պահեցի ֆայլում:
2) Ձեռքով սպանել է jamb ինդեքսը _AccumRgTn19455 աղյուսակից
3) Գործարկել է նման հարցում
SQL կոդը S_elect count(*), index_fields
FR OM AccumRgTn19455
ԽՈՒՄԲ ԸՍՏ ինդեքսի_դաշտի
ՈՒՆԵՑՈՂ հաշվում(*)>1
Ինդեքսը սպանվելուց հետո ես ցուցադրեցի 15 կրկնօրինակ գրառում, չնայած 2-րդ քայլից առաջ հարցումը ոչինչ չէր վերադարձնում:
4) Ես անցա բոլոր գրառումները և ձեռքով մաքրեցի կրկնօրինակները: Իրականում ես նաև օգտագործել եմ «Հաշվետվության կառուցվածքը» մշակումը, որպեսզի հասկանամ, թե ինչի հետ գործ ունեմ: Պարզվեց, որ _AccumRgTn19455 աղյուսակում պահվում է «Արտադրանքի արտադրանք (հարկային հաշվառում)» կուտակային ռեգիստրը: Ես նաև ջնջեցի sql հարցումները, հայտնաբերեցի 15 ոչ եզակի փաստաթուղթ, և բոլոր գործողություններն ավարտվելուց հետո 1C-ում ստուգեցի, որ այդ փաստաթղթերը նորմալ մշակվել են, առանց սխալների: Իհարկե, պետք չէ միայն պատահականորեն մաքրել սեղանները. կարևոր է հասկանալ, թե ինչ է մաքրվում և ինչպես կարող է ստացվել:
5) Գործարկել է ինդեքս ստեղծելու հարցում, որը պահվել է ֆայլում:
6) Տվյալների բազան փոխեց մեկ օգտագործողի ռեժիմի և գործարկեց dbcc checkdb - այս անգամ ոչ մի սխալ չի առաջացել:
7) Հիմքը վերադարձրեց մեկ օգտագործողի ռեժիմին:
Վերջ... խնդիրը հաղթահարված է։ Դե, դեռ 1C-ում ես գործարկեցի «Թեստավորում և ուղղում», այնտեղ նույնպես ամեն ինչ լավ էր, ես դադարեցի բողոքել ոչ եզակի ցուցանիշից:

3. Եթե ոչ եզակիությունը զրոյական արժեք ունեցող ամսաթվերի մեջ է, ապա խնդիրը լուծվում է 2000-ին հավասար օֆսեթ պարամետրով տվյալների բազա ստեղծելով։

1. Եթե խնդիրը տվյալների բազայի բեռնումն է, ապա.
1.1. Եթե դուք բեռնում եք (օգտագործելով dt-ֆայլ) MS SQL Server-ի տվյալների բազայում, ապա տվյալների բազան ստեղծելիս, նախքան բեռնումը, նշեք ամսաթվի օֆսեթը՝ 2000 թ.
Եթե տվյալների բազան արդեն ստեղծվել է օֆսեթ 0-ով, ապա ստեղծեք նորը 2000-ով:

1.2. Եթե հնարավոր է աշխատել տվյալների բազայի հետ ֆայլի տարբերակով, ապա կատարեք Testing and Correction, ինչպես նաև Configuration - Checking the configuration - Checking տրամաբանական ամբողջականությունը կազմաձևում + Որոնել սխալ հղումներ:

1.3. Եթե ֆայլի տարբերակ չկա, փորձեք DT-ից բեռնել հաճախորդ-սերվերի տարբերակ DB2-ով (որն ավելի քիչ պահանջկոտ է եզակիության համար), այնուհետև կատարեք Test and Correction, ինչպես նաև Configuration - Verify Configuration - Ստուգեք Կազմաձևի տրամաբանական ամբողջականությունը: + Փնտրեք անվավեր հղումներ:

1.4. Խնդիրը տեղայնացնելու համար կարող եք որոշել այն օբյեկտի տվյալները, որի բեռնումը ձախողվեց: Դա անելու համար դուք պետք է ակտիվացնեք հետագծումը Profiler կոմունալում բեռնման ժամանակ կամ ձայնագրումը DBMSSQL և EXCP գործընթացի իրադարձությունների մատյանում:

2. Եթե ոչ եզակիության խնդիրն առաջանում է օգտատերերի աշխատանքի ընթացքում.

2.1. Գտեք խնդրահարույց հարցումը՝ օգտագործելով 1.4 կետի մեթոդը:

2.1.2. Երբեմն հարցումները կատարելիս սխալ է տեղի ունենում, օրինակ՝

Այս սխալն առաջանում է այն պատճառով, որ կուտակային ռեգիստրի մոդուլում «Գրանցման վերահաշվարկներ» ընթացակարգի «Կազմակերպությունների աշխատողների աշխատաժամանակը», «ՏԱՐԲԵՐ» սպասարկման բառը ներառված չէ հարցումում:
Կոդ 1C v 8.x I.e. պետք է լինի:
Հարցում = Նոր հարցում (
«ԸՆՏՐԵԼ ՏԱՐԲԵՐ
| Հիմնական.Անհատական,
. . . . .
ZUP-ի և UPP-ի վերջին թողարկումներում սխալը տեղի չի ունենում, քանի որ գրված է «ՏԱՐԲԵՐ».

2.2. Նախորդ պարբերությունից խնդրահարույց ինդեքսը գտնելուց հետո անհրաժեշտ է գտնել ոչ եզակի գրառում:
2.2.1. «Fish» սցենար՝ SQL-ի միջոցով ոչ եզակի գրառումները նույնականացնելու համար.
SQL կոդը S_elect COUNT(*) հաշվիչ,<перечисление всех полей соответствующего индекса>fr om<имя таблицы>
ԽՈՒՄԲ ԸՍՏ<перечисление всех полей соответствующего индекса>
ՈՒՆԵՆՔ հաշվիչ > 1

2.2.2 Օրինակ. Սխալի մեջ նշված ինդեքսը կոչվում է «_Document140_VT1385_IntKeyIndNG»:
Աղյուսակի դաշտերի ցանկ.
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1389, _Fld1390 Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRref, _Fld22261_TYPE2, _1RFLD2Ref, _Fld22261_TYPE2, _1RFLD2Ref, _Fld22261_TYPE2, _1RFLD2Ref
Նախքան ստորև նշված ընթացակարգը կատարելը, խնդրում ենք կրկնօրինակեք ձեր տվյալների բազան:
Գործարկել MS SQL Server հարցումների վերլուծիչում.
SQL կոդը S_elect count(*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
խումբ ըստ _Document140_IDRRef, _KeyField
ունենալով հաշվարկ (*) > 1
Օգտագործեք այն՝ պարզելու _Document140_IDRRef, _KeyField, կրկնօրինակ գրառումների (id, բանալի) սյունակների արժեքները:

Օգտագործելով հարցումը.
SQL կոդը S_elect *
fr om _Document140_VT1385
որտեղ _Document140_IDRRef = id1 և _KeyField = key1 կամ _Document140_IDRRef = id2 և _KeyField = բանալի2 կամ ...
դիտեք կրկնօրինակ գրառումների մյուս սյունակների արժեքները:
Եթե երկու մուտքերն էլ ունեն իմաստալից արժեքներ, և արժեքները տարբեր են, ապա փոխեք _KeyField արժեքը՝ որպես եզակի: Դա անելու համար որոշեք _KeyField-ի առավելագույն զբաղված արժեքը (keymax):
SQL կոդը S_elect max(_KeyField)
fr om _Document140_VT1385
wh ere _Document140_IDRRef = id1
Փոխարինեք _KeyField արժեքը կրկնօրինակ գրառումներից մեկում ճիշտով.
SQL կոդը թարմացվել է _Document140_VT1385
սահմանել _KeyField = keymax + 1

Այստեղ _LineNo1386 = լրացուցիչ պայման է, որը թույլ է տալիս ընտրել երկու կրկնվող գրառումներից մեկը:

Եթե կրկնվող գրառումներից մեկը (կամ երկուսը) ակնհայտորեն սխալ նշանակություն ունի, ապա այն պետք է հեռացվի.
SQL կոդը ջնջել _Document140_VT1385-ից
wh ere _Document140_IDRRef = id1 և _LineNo1386 = lineno1
Եթե կրկնօրինակ գրառումները բոլոր սյունակներում ունեն նույն արժեքները, ապա դուք պետք է թողնեք դրանցից մեկը.
SQL կոդը S_elect distinct *
մեջ #tmp1
_Document140_VT1385-ից

Ջնջել _Document140_VT1385-ից
h ere _Document140_IDRRef = id1 և _KeyField = key1

I_insert մեջ _Document140_VT1385
S_ընտրեք #tmp1

D_rop սեղան #tmp1

Նկարագրված ընթացակարգը պետք է կատարվի յուրաքանչյուր զույգ կրկնօրինակ գրառումների համար:

2.2.3. Երկրորդ օրինակ.
SQL կոդը S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Նկարագրություն
FROM _Հղում8_
ԽՈՒՄԲ ԸՍՏ _IDRRef, _Նկարագրություն
ՈՒՆԵՑՈՂ (COUNT(*) > 1)

2.3.4 Ոչ եզակի գրառումների որոշման օրինակ՝ օգտագործելով 1C:Enterprise հարցումը.
Կոդ 1C v 8.x SELECT Directory.Link
FROM Directory.Directory AS Directory
GROUP BY Directory.Link
ՈՒՆԵՑՈՂ ՔԱՆԱԿ (*) > 1

Տեղեկատվությունը վերցված է կայքից

Լուծումներ:

2. 1) Օգտագործելով Management Studio 2005-ը, ես ստեղծեցի ստեղծել սկրիպտ՝ ինդեքս ստեղծելու համար, որը սխալ էր, և այն պահեցի ֆայլում:
2) Ձեռքով սպանել է jamb ինդեքսը _AccumRgTn19455 աղյուսակից
3) Գործարկել է նման հարցում
SQL կոդը S_elect count(*), index_fields
AccumRgTn19455-ից
ԽՈՒՄԲ ԸՍՏ ինդեքսի_դաշտի
ՈՒՆԵՑՈՂ հաշվում(*)>1
Ինդեքսը սպանվելուց հետո ես ցուցադրեցի 15 կրկնօրինակ գրառում, չնայած 2-րդ քայլից առաջ հարցումը ոչինչ չէր վերադարձնում:
4) Ես անցա բոլոր գրառումները և ձեռքով մաքրեցի կրկնօրինակները: Իրականում ես նաև օգտագործել եմ «Հաշվետվության կառուցվածքը» մշակումը, որպեսզի հասկանամ, թե ինչի հետ գործ ունեմ: Պարզվեց, որ _AccumRgTn19455 աղյուսակում պահվում է «Արտադրանքի արտադրանք (հարկային հաշվառում)» կուտակային ռեգիստրը: Ես նաև ջնջեցի sql հարցումները, հայտնաբերեցի 15 ոչ եզակի փաստաթուղթ, և բոլոր գործողություններն ավարտվելուց հետո 1C-ում ստուգեցի, որ այդ փաստաթղթերը նորմալ մշակվել են, առանց սխալների: Իհարկե, դուք չպետք է պարզապես պատահականորեն մաքրեք սեղանները. կարևոր է հասկանալ, թե ինչ է մաքրվում և ինչպես կարող է ստացվել:
5) Գործարկել է ինդեքս ստեղծելու հարցում, որը պահվել է ֆայլում:
6) Տվյալների բազան փոխեց մեկ օգտագործողի ռեժիմի և գործարկեց dbcc checkdb - այս անգամ ոչ մի սխալ չի առաջացել:
7) Հիմքը վերադարձրեց մեկ օգտագործողի ռեժիմին:
Վերջ... խնդիրը հաղթահարված է։ Դե, դեռ 1C-ում ես գործարկեցի «Թեստավորում և ուղղում», այնտեղ նույնպես ամեն ինչ լավ էր, ես դադարեցի բողոքել ոչ եզակի ցուցանիշից:

2. Եթե ոչ եզակիության խնդիրն առաջանում է օգտատերերի աշխատանքի ընթացքում.

2.1. Գտեք խնդրահարույց հարցումը՝ օգտագործելով 1.4 կետի մեթոդը:

2.1.2. Երբեմն հարցումները կատարելիս սխալ է տեղի ունենում, օրինակ՝

Այս սխալը տեղի է ունենում այն պատճառով, որ կուտակային ռեգիստրի մոդուլում «Գրանցման վերահաշվարկներ» ընթացակարգի «Կազմակերպությունների աշխատողների աշխատաժամանակը», «ՏԱՐԲԵՐ» սպասարկման բառը ներառված չէ հարցումում:
Կոդ 1C v 8.x I.e. պետք է լինի:
Հարցում = Նոր հարցում (
«ԸՆՏՐԵԼ ՏԱՐԲԵՐ
| Հիմնական.Անհատական,
. . . . .
ZUP-ի և UPP-ի վերջին թողարկումներում սխալը տեղի չի ունենում, քանի որ գրված է «ՏԱՐԲԵՐ».

2.2. Նախորդ պարբերությունից խնդրահարույց ինդեքսը գտնելուց հետո անհրաժեշտ է գտնել ոչ եզակի գրառում:
2.2.1. «Fish» սկրիպտ՝ SQL-ի միջոցով ոչ եզակի գրառումների նույնականացման համար.
SQL կոդը S_elect COUNT(*) հաշվիչ,<перечисление всех полей соответствующего индекса>-ից<имя таблицы>
ԽՈՒՄԲԸ ԸՍՏ<перечисление всех полей соответствующего индекса>
ՈՒՆԵՆՔ հաշվիչ > 1

2.2.2 Օրինակ. Սխալի մեջ նշված ինդեքսը կոչվում է «_Document140_VT1385_IntKeyIndNG»:
Աղյուսակի դաշտերի ցանկ.
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1389, _Fld1390 Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRref, _Fld22261_TYPE2, _1RFLD2Ref, _Fld22261_TYPE2, _1RFLD2Ref, _Fld22261_TYPE2, _1RFLD2Ref
Նախքան ստորև նշված ընթացակարգը կատարելը, խնդրում ենք կրկնօրինակեք ձեր տվյալների բազան:
Գործարկել MS SQL Server հարցումների վերլուծիչում.
SQL կոդը S_elect count(*), _Document140_IDRRef, _KeyField
_Document140_VT1385-ից
խումբ ըստ _Document140_IDRRef, _KeyField
ունենալով հաշվարկ (*) > 1
Օգտագործեք այն՝ պարզելու _Document140_IDRRef, _KeyField, կրկնօրինակ գրառումների (id, բանալի) սյունակների արժեքները:

Օգտագործելով հարցումը.
SQL կոդը S_elect *
_Document140_VT1385-ից
կամ _Document140_IDRRef = id2 և _KeyField = key2 կամ ...
դիտեք կրկնօրինակ գրառումների մյուս սյունակների արժեքները:
Եթե երկու մուտքերն էլ ունեն իմաստալից արժեքներ, և արժեքները տարբեր են, ապա փոխեք _KeyField արժեքը՝ որպես եզակի: Դա անելու համար որոշեք _KeyField-ի առավելագույն զբաղեցրած արժեքը (keymax):
SQL կոդը S_elect max(_KeyField)
_Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1
Կրկնվող գրառումներից մեկում _KeyField արժեքը փոխարինեք ճիշտով.
SQL կոդի թարմացում _Document140_VT1385
սահմանել _KeyField = keymax + 1
Այստեղ _LineNo1386 = լրացուցիչ պայման է, որը թույլ է տալիս ընտրել երկու կրկնվող գրառումներից մեկը:

Եթե կրկնվող գրառումներից մեկը (կամ երկուսն էլ) ակնհայտորեն սխալ նշանակություն ունի, ապա այն պետք է հեռացվի.
SQL կոդը ջնջել _Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1 և _LineNo1386 = lineno1
Եթե կրկնօրինակ գրառումները բոլոր սյունակներում ունեն նույն արժեքները, ապա դուք պետք է թողնեք դրանցից մեկը.
SQL կոդը S_elect distinct *
մեջ #tmp1
_Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1 և _KeyField = key1

Ջնջել _Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1 և _KeyField = key1

I_insert մեջ _Document140_VT1385
S_ընտրեք #tmp1

D_rop սեղան #tmp1

Նկարագրված ընթացակարգը պետք է կատարվի յուրաքանչյուր զույգ կրկնօրինակ գրառումների համար:

2.2.3. Երկրորդ օրինակ.
SQL կոդը S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Նկարագրություն
FROM _Հղում8_
ԽՈՒՄԲԸ ԸՍՏ _IDRRef, _Նկարագրություն
ՈՒՆԵՑՈՂ (COUNT(*) > 1)

Այս հոդվածը նկարագրում է, թե ինչ անել, եթե 1C:Enterprise 8.1-ի հետ աշխատելիս հանդիպեք տողեր պարունակող հաղորդագրության.

Հնարավոր չէ տեղադրել կրկնօրինակ հիմնական տող օբյեկտում

Փորձ է արվել եզակի ինդեքսի մեջ տեղադրել ոչ եզակի արժեք:

Ի՞նչ է ինդեքսը:

Ինդեքսները կառույց են, որը թույլ է տալիս արագ մուտք գործել աղյուսակի տողեր՝ հիմնված դրա սյունակներից մեկի կամ մի քանիսի արժեքների վրա:
Ցուցանիշը պարունակում է ստեղներ, որոնք կառուցված են աղյուսակի կամ տեսարանի մեկ կամ մի քանի սյուներից, և ցուցիչներ, որոնք քարտեզագրվում են նշված տվյալների պահպանման վայրի վրա:
Ինդեքսները նվազեցնում են տվյալների քանակությունը, որոնք պետք է ընթերցվեն արդյունքների հավաքածու վերադարձնելու համար:

Չնայած ինդեքսը կապված է աղյուսակի որոշակի սյունակի (կամ սյուների) հետ, այն դեռևս տվյալների բազայի առանձին օբյեկտ է:

1C:Enterprise տվյալների բազայի աղյուսակների ինդեքսները ստեղծվում են անուղղակիորեն կոնֆիգուրացիայի օբյեկտներ ստեղծելիս, ինչպես նաև կազմաձևման օբյեկտների որոշակի կարգավորումների ժամանակ:

Ինդեքսների ֆիզիկական էությունը MS SQL Server 2005-ում:

Ֆիզիկապես տվյալները պահվում են 8 Կբ էջերի վրա. Ստեղծվելուց անմիջապես հետո, մինչդեռ աղյուսակը չունի ինդեքսներ, աղյուսակը նման է տվյալների կույտի: Գրառումները հատուկ պահպանման կարգ չունեն:
Երբ դուք ցանկանում եք մուտք գործել տվյալներ, SQL Server-ը կարտադրի սեղանի սկանավորում(սեղանի սկանավորում): SQL Server-ը սկանավորում է ամբողջ աղյուսակը՝ փնտրած գրառումները գտնելու համար:
Այստեղից պարզ են դառնում ինդեքսների հիմնական գործառույթները.
- տվյալների հասանելիության արագության բարձրացում,
— տվյալների եզակիության աջակցություն:

Չնայած իրենց առավելություններին, ինդեքսներն ունեն նաև մի շարք թերություններ. Առաջինը ինդեքսներն են վերցնել լրացուցիչ սկավառակի տարածությունև RAM-ում: Ամեն անգամ, երբ ինդեքս եք ստեղծում, բանալիները պահում եք նվազման կամ աճման կարգով, որը կարող է ունենալ բազմաստիճան կառուցվածք։ Եվ որքան մեծ/երկար է բանալին, այնքան մեծ է ինդեքսի չափը: Երկրորդ թերությունն այն է գործողությունները դանդաղում ենգրառումների տեղադրում, թարմացում և ջնջում:
MS SQL Server 2005 միջավայրում ներդրվում են մի քանի տեսակի ինդեքսներ.

ոչ կլաստերային ինդեքսներ;
կլաստերային (կամ կլաստերային) ինդեքսներ;
եզակի ինդեքսներ;
ինդեքսներ ներառված սյունակներով
ինդեքսավորված դիտումներ
ամբողջական տեքստը

Եզակի ցուցանիշ

Ինդեքսավորված սյունակում արժեքների եզակիությունը երաշխավորված է եզակի ինդեքսներով: Եթե դրանք առկա են, սերվերը թույլ չի տա ձեզ տեղադրել նոր արժեք կամ փոխել գոյություն ունեցող արժեքն այնպես, որ այս գործողության արդյունքում սյունակում հայտնվեն երկու նույնական արժեքներ:
Եզակի ինդեքսը մի տեսակ հավելում է և կարող է իրականացվել ինչպես կլաստերային, այնպես էլ ոչ կլաստերային ինդեքսների համար: Մեկ աղյուսակը կարող է ունենալ մեկ եզակի կլաստերային ինդեքս և բազմաթիվ եզակի ոչ կլաստերային ինդեքսներ:
Եզակի ինդեքսները պետք է սահմանվեն միայն իսկապես անհրաժեշտության դեպքում: Սյունակի վրա տվյալների ամբողջականությունն ապահովելու համար դուք կարող եք սահմանել եզակի ինդեքսների փոխարեն եզակի ինդեքսների դիմելու փոխարեն սահմանել ՈՒՆԻԿ կամ ՀԻՄՆԱԿԱՆ ԲԱՆԱԼԻ ամբողջականության սահմանափակում: Նրանց օգտագործումը բացառապես տվյալների ամբողջականությունն ապահովելու համար տվյալների բազայի տարածքի վատնում է: Բացի այդ, պրոցեսորի ժամանակը ծախսվում է նաև դրանց պահպանման վրա։

1C:Enterprise 8.1-ը, սկսած 8.1 տարբերակից, ակտիվորեն օգտագործում է կլաստերային եզակի ինդեքսներ: Սա նշանակում է, որ 8.0-ից փոխակերպելիս կամ 8.1.7-ից տեղափոխելիս դուք կարող եք ստանալ ոչ եզակի ինդեքսային սխալ:

Եթե ոչ եզակիությունը զրոյական արժեք ունեցող ամսաթվերի մեջ է, ապա խնդիրը լուծվում է 2000-ին հավասար օֆսեթ պարամետրով տվյալների բազա ստեղծելով։

Ինչ անել?

1. Եթե խնդիրը տվյալների բազայի բեռնումն է, ապա.

1.1. Եթե դուք բեռնում եք (օգտագործելով dt ֆայլ) MS SQL Server-ի տվյալների բազայում, ապա տվյալների բազան ստեղծելիս, նախքան բեռնումը, նշեք ամսաթվի օֆսեթը՝ 2000 թ.

Եթե տվյալների բազան արդեն ստեղծվել է օֆսեթ 0-ով, ապա ստեղծեք նորը 2000-ով:

1.4. Խնդիրը տեղայնացնելու համար կարող եք որոշել այն օբյեկտի տվյալները, որի բեռնումը ձախողվեց: Դա անելու համար դուք պետք է ակտիվացնեք հետագծումը Profiler կոմունալում բեռնման ժամանակ կամ ձայնագրումը DBMSSQL և EXCP տեխնոլոգիական իրադարձությունների մատյանում:

1.5. Եթե հանգույցը (փոխանակման պլանները) հասանելի է, ապա կատարեք փոխանակումը: Կարող եք նաև լրացուցիչ լրացնել 2.3.5 պարբերությունը փոխանակելուց առաջ

2. Եթե ոչ եզակիության խնդիրն առաջանում է օգտատերերի աշխատանքի ընթացքում.

2.1. Գտեք խնդրահարույց հարցումը՝ օգտագործելով 1.4 կետի մեթոդը:

2.1.2. Երբեմն հարցումները կատարելիս սխալ է տեղի ունենում, օրինակ՝

Նրանք. պետք է լինի:

Հարցում = Նոր հարցում (
«ԸՆՏՐԵԼ ՏԱՐԲԵՐ
| Հիմնական.Անհատական,

ZUP-ի և UPP-ի վերջին թողարկումներում սխալը տեղի չի ունենում, քանի որ այն ասում է «ՏԱՐԲԵՐ»:

2.2. Նախորդ պարբերությունից խնդրահարույց ինդեքսը գտնելուց հետո անհրաժեշտ է գտնել ոչ եզակի գրառում:

2.2.1. «Fish» սցենար՝ SQL-ի միջոցով ոչ եզակի գրառումները նույնականացնելու համար.
SELECT COUNT(*) հաշվիչ,<перечисление всех полей соответствующего индекса>-ից<имя таблицы>
ԽՈՒՄԲԸ ԸՍՏ<перечисление всех полей соответствующего индекса>
ՈՒՆԵՆՔ հաշվիչ > 1

2.2.2 Օրինակ. Սխալի մեջ նշված ինդեքսը կոչվում է «_Document140_VT1385_IntKeyIndNG»:

Աղյուսակի դաշտերի ցանկ.

Փաստաթուղթ140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1393_TYPE, _Fld139F, _Fld139Fld, _Fld1393_

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE2, _1_2Ref, _Fld22261_TYPE2, _1_2Ref, _Fld22261_TYPE2, _1_2Ref

Նախքան ստորև նշված ընթացակարգը կատարելը, խնդրում ենք կրկնօրինակեք ձեր տվյալների բազան:
Գործարկել MS SQL Server հարցումների վերլուծիչում.

ընտրել count(*), _Document140_IDRRef, _KeyField
_Document140_VT1385-ից
խումբ ըստ _Document140_IDRRef, _KeyField
ունենալով հաշվարկ (*) > 1

Օգտագործեք այն՝ պարզելու _Document140_IDRRef, _KeyField, կրկնօրինակ գրառումների (id, բանալի) սյունակների արժեքները:

Օգտագործելով հարցումը.

ընտրել *
_Document140_VT1385-ից
կամ _Document140_IDRRef = id2 և _KeyField = key2 կամ ...

դիտեք կրկնօրինակ գրառումների մյուս սյունակների արժեքները:

Եթե երկու մուտքերն էլ ունեն իմաստալից արժեքներ, և արժեքները տարբեր են, ապա փոխեք _KeyField արժեքը՝ որպես եզակի: Դա անելու համար որոշեք _KeyField-ի առավելագույն զբաղված արժեքը (keymax):

ընտրել առավելագույնը (_KeyField)
_Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1

Կրկնվող գրառումներից մեկում _KeyField արժեքը փոխարինեք ճիշտով.

update_Document140_VT1385
սահմանել _KeyField = keymax + 1

Այստեղ _LineNo1386 = լրացուցիչ պայման է, որը թույլ է տալիս ընտրել երկու կրկնվող գրառումներից մեկը:

Եթե կրկնվող գրառումներից մեկը (կամ երկուսն էլ) ակնհայտորեն սխալ նշանակություն ունի, ապա այն պետք է հեռացվի.

որտեղ _Document140_IDRRef = id1 և _LineNo1386 = lineno1

Եթե կրկնօրինակ գրառումները բոլոր սյունակներում ունեն նույն արժեքները, ապա դուք պետք է թողնեք դրանցից մեկը.

ընտրել տարբեր *
մեջ #tmp1
_Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1 և _KeyField = key1

ջնջել _Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1 և _KeyField = key1

տեղադրեք _Document140_VT1385-ի մեջ
ընտրեք #tmp1

թողնել սեղան #tmp1

Նկարագրված ընթացակարգը պետք է կատարվի յուրաքանչյուր զույգ կրկնօրինակ գրառումների համար:

2.2.3. Երկրորդ օրինակ.

SELECT COUNT(*) AS Expr2, _IDRRef AS Expr1, _Նկարագրություն
FROM _Հղում8_
ԽՈՒՄԲԸ ԸՍՏ _IDRRef, _Նկարագրություն
ՈՒՆԵՑՈՂ (COUNT(*) > 1)

2.3.4 Ոչ եզակի գրառումների որոշման օրինակ՝ օգտագործելով 1C:Enterprise հարցումը.

կամ հաշվապահական հաշվառման համար

ԸՆՏՐԵԼ
Ենթհարցման ժամանակաշրջան,
Subquery.Recorder,
<измерения>,
SUM(Subquery.Number of Records) AS Գրառումների քանակը
ԻՑ
(ԸՆՏՐԵԼ
Ինքնապահովման ժամանակաշրջան AS ժամանակաշրջան,
Ինքնասպասարկում: Գրանցող ՀԾ Գրանցող,
<измерения>,
1 AS Գրառումների քանակը
ԻՑ
Հաշվապահական հաշվառման գրանցում

ԽՈՒՄԲ ԸՍՏ
Ենթհարցման ժամանակաշրջան,
Subquery.Recorder,
<измерения>

ՈՒՆԵՑՈՂ
SUM (Ենթահղում. Գրառումների քանակը) > 1

2.3.5 Subd ինդեքսը դարձնել ոչ եզակի: Գրանցեք ինդեքսը կառավարման ստուդիայի միջոցով:

2.3.6 Հատուկ դեպք RDB-ում փոխանակելիս: Սխալը տեղի է ունենում «օժանդակ» աղյուսակներում, որոնք կապված են ընդհանուրների կամ վերլուծությունների հաշվարկի հետ: Օրինակ:

Համատեքստի մեթոդը կանչելիս սխալ (Write). Փորձում է ոչ եզակի արժեք ներդնել եզակի ինդեքսի մեջ.
Microsoft OLE DB մատակարար SQL Server-ի համար. հնարավոր չէ տեղադրել «dbo._AccntRegED10319» օբյեկտի կրկնօրինակ հիմնական տող՝ «_Accnt10319_ByPeriod_TRNRN» եզակի ինդեքսով:
HRESULT=80040E2F, SQLSrvr. Սխալի վիճակ=1, Խստություն=E, բնիկ=2601, տող=1

Այս դեպքում, նախքան բեռնումը, անջատեք ընդհանուրների օգտագործումը, բեռնեք հաղորդագրությունը, միացրեք ընդհանուրների օգտագործումը և վերահաշվարկեք:

Լուծումներ:

2. 1) Օգտագործելով Management Studio 2005-ը, ես ստեղծեցի ստեղծել սկրիպտ՝ ինդեքս ստեղծելու համար, որը սխալ էր, և այն պահեցի ֆայլում:
2) Ձեռքով սպանել է jamb ինդեքսը _AccumRgTn19455 աղյուսակից
3) Գործարկել է նման հարցում
SQL կոդը S_elect count(*), index_fields
AccumRgTn19455-ից
ԽՈՒՄԲ ԸՍՏ ինդեքսի_դաշտի
ՈՒՆԵՑՈՂ հաշվում(*)>1
Ինդեքսը սպանվելուց հետո ես ցուցադրեցի 15 կրկնօրինակ գրառում, չնայած 2-րդ քայլից առաջ հարցումը ոչինչ չէր վերադարձնում:
4) Ես անցա բոլոր գրառումները և ձեռքով մաքրեցի կրկնօրինակները: Իրականում ես նաև օգտագործել եմ «Հաշվետվության կառուցվածքը» մշակումը, որպեսզի հասկանամ, թե ինչի հետ գործ ունեմ: Պարզվեց, որ _AccumRgTn19455 աղյուսակում պահվում է «Արտադրանքի արտադրանք (հարկային հաշվառում)» կուտակային ռեգիստրը: Ես նաև ջնջեցի sql հարցումները, հայտնաբերեցի 15 ոչ եզակի փաստաթուղթ, և բոլոր գործողություններն ավարտվելուց հետո 1C-ում ստուգեցի, որ այդ փաստաթղթերը նորմալ մշակվել են, առանց սխալների: Իհարկե, դուք չպետք է պարզապես պատահականորեն մաքրեք սեղանները. կարևոր է հասկանալ, թե ինչ է մաքրվում և ինչպես կարող է ստացվել:
5) Գործարկել է ինդեքս ստեղծելու հարցում, որը պահվել է ֆայլում:
6) Տվյալների բազան փոխեց մեկ օգտագործողի ռեժիմի և գործարկեց dbcc checkdb - այս անգամ ոչ մի սխալ չի առաջացել:
7) Հիմքը վերադարձրեց մեկ օգտագործողի ռեժիմին:
Վերջ... խնդիրը հաղթահարված է։ Դե, դեռ 1C-ում ես գործարկեցի «Թեստավորում և ուղղում», այնտեղ նույնպես ամեն ինչ լավ էր, ես դադարեցի բողոքել ոչ եզակի ցուցանիշից:

2. Եթե ոչ եզակիության խնդիրն առաջանում է օգտատերերի աշխատանքի ընթացքում.

2.1. Գտեք խնդրահարույց հարցումը՝ օգտագործելով 1.4 կետի մեթոդը:

2.1.2. Երբեմն հարցումները կատարելիս սխալ է տեղի ունենում, օրինակ՝

2.2.2 Օրինակ. Սխալի մեջ նշված ինդեքսը կոչվում է «_Document140_VT1385_IntKeyIndNG»:
Աղյուսակի դաշտերի ցանկ.
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_TYPE, _Fld1389, _Fld1390 Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRref, _Fld22261_TYPE2, _1RFLD2Ref, _Fld22261_TYPE2, _1RFLD2Ref, _Fld22261_TYPE2, _1RFLD2Ref
Նախքան ստորև նշված ընթացակարգը կատարելը, խնդրում ենք կրկնօրինակեք ձեր տվյալների բազան:
Գործարկել MS SQL Server հարցումների վերլուծիչում.
SQL կոդը S_elect count(*), _Document140_IDRRef, _KeyField
_Document140_VT1385-ից
խումբ ըստ _Document140_IDRRef, _KeyField
ունենալով հաշվարկ (*) > 1
Օգտագործեք այն՝ պարզելու _Document140_IDRRef, _KeyField, կրկնօրինակ գրառումների (id, բանալի) սյունակների արժեքները:

Ջնջել _Document140_VT1385-ից
որտեղ _Document140_IDRRef = id1 և _KeyField = key1

I_insert մեջ _Document140_VT1385
S_ընտրեք #tmp1

D_rop սեղան #tmp1

Նկարագրված ընթացակարգը պետք է կատարվի յուրաքանչյուր զույգ կրկնօրինակ գրառումների համար:

Սխալ է առաջանում, եթե տվյալների բազայի որոշ օբյեկտներ, մանրամասներ, ենթահամակարգեր ունեն NULL արժեք, բայց դրանք չեն կարող ունենալ այդպիսի արժեք։ Եվ այս սխալը հայտնվում է միայն SQL տվյալների բազաներում։ Նրանք. Եթե դուք վերբեռնում եք նման տվյալների բազա ֆայլի վրա, ապա այս սխալն այլևս այնտեղ չի լինի: Որովհետեւ Ֆայլերի տվյալների բազան ունի իր սեփական աղյուսակները (ընդհանուր 4), իսկ SQL-ն ունի իր աղյուսակները։ Եվ SQL տվյալների բազան քննադատորեն արձագանքում է իր աղյուսակների նման արժեքներին:

Այս խնդիրը չի կարող լուծվել տվյալների բազայի որևէ տարբերակում (SQL կամ ֆայլ) որևէ փորձարկումով (ոչ արտաքին, ոչ ներքին) և նույնիսկ SQL մենեջերում _1sp_DBReindex ընթացակարգով, որը կարծես թե պետք է վերակառուցի աղյուսակները SQL-ում:

Եկեք նայենք խնդրի լուծմանը՝ օգտագործելով Accounting 3.0 PROF-ից CORP-ին անցնելու օրինակը: Անցումից հետո 68.01 հաշիվն ունի նոր ենթահաշիվ՝ գրանցում հարկային մարմնում։ Եվ հետո, SQL տվյալների բազաներում, PRO տարբերակում ստեղծված բոլոր փաստաթղթերը, որոնք օգտագործում են այս հաշիվը, չեն փոխանցվի: Կհայտնվի վերը նշված սխալը: Որովհետեւ Հին փաստաթղթերի այս նոր ենթահաշիվը, գրառումներում, գրվելու է NULL արժեքով (չնայած այնտեղ պետք է լինի դատարկ արժեք, կամ ինչ-որ կերպ հարկային մարմինը):

Այս սխալը շտկելու համար անհրաժեշտ է հեռացնել NULL արժեքները, որտեղ դրանք չպետք է լինեն: Այս դեպքում այն փաստաթղթերում, որտեղ օգտագործվում է ենթահաշիվը Հարկային մարմնում գրանցումը: Դա կարելի է անել՝ գրելով մշակում, որը NULL-ը կփոխարինի դատարկ արժեքով (պատրաստի մշակումը կարելի է ներբեռնել այս հոդվածից): Դա արեք վերամշակմամբ, քանի որ Փաստաթղթերի հրապարակումների մեջ այս ենթահաշվի արժեքը ձեռքով փոխելու փորձը հանգեցնում է նույն սխալի:

Հարկային մարմնի հետ գրանցման բոլոր ենթահոդվածներում NULL-ների փոխարինման գործընթացը կարելի է ներբեռնել ստորև նշված հոդվածից:

ԲԱՅՑ այն չի աշխատի SQL տվյալների բազայում փոխարինել NULL-ը, նույն սխալը կառաջանա: Այսպիսով, դուք պետք է անեք սա.

1. Վերբեռնեք SQL տվյալների բազայի արդեն աշխատող տարբերակը, որը թարգմանվել է CORP, dt ֆայլի մեջ (կոնֆիգուրատորի Administration-ում – Upload database – ընտրեք, թե որտեղ պետք է վերբեռնել տվյալների բազան որպես *.dt ֆայլ)

2. Ներբեռնեք dt ֆայլը ֆայլերի տվյալների բազայում (ավելորդ կամ նախապես պատրաստված, մաքուր ֆայլերի տվյալների բազայում, կոնֆիգուրատորի ադմինիստրացիա - Բեռնել տվյալների բազան - ընտրեք նախկինում բեռնված dt ֆայլը)

3. Կատարեք վերամշակում ֆայլերի տվյալների բազայում (այնտեղ սխալներ չեն լինի, և բոլոր NULL-ները ճիշտ կփոխարինվեն) (վերամշակումը կատարելը նկարագրված է ստորև)

5. Այժմ, ընդհակառակը, բեռնաթափեք dt ֆայլը ֆայլերի տվյալների բազայից և բեռնեք այն SQL տվյալների բազայում: Այժմ մշակված փաստաթղթերը տեղադրելու ժամանակ սխալներ չեն առաջանա։

Այս հոդվածի մշակումը գտնում է բոլոր փաստաթղթերը նշված ժամանակահատվածի համար, որոնցում հրապարակումները ներառում են ենթապայմանագրի գրանցում հարկային մարմնի հետ (որը հայտնվում է CORP տարբերակում), որն ունի NULL արժեքը: Եվ այս արժեքը փոխարինում է դատարկ արժեքով:

Մշակման ընթացքում դուք պետք է նշեք այն ժամանակահատվածը, որի համար ցանկանում եք մշակել փաստաթղթերը (կարող եք այն ամբողջ ժամանակահատվածի համար, որի ընթացքում գրառումները պահվում են տվյալների բազայում) և սեղմեք «Լրացրեք աղյուսակային բաժինը»: Այնուհետև կարող եք նշել վանդակները՝ նշելու, թե որ փաստաթղթերը պետք է մշակվեն (կարող եք ընտրել բոլորը) և սեղմել «Գործընթաց» կոճակը:

Համապատասխանաբար, եթե ինչ-որ մեկն ունի նույն սխալը, բայց ՈՉ CORP-ին անցնելուց հետո, այլ օրինակ՝ փոխանակելուց, որոշ տվյալներ բեռնելուց, որոշ մշակումներ կատարելուց և այլն: Այնուհետև դուք պետք է պարզեք, թե որտեղ է նշանակվել NULL արժեքը կոնկրետ փաստաթղթում/տեղեկագրքում և հեռացնել այս NULL-ը նույն ձևով, բայց ձեր սեփական մշակմամբ, բայց վերը նկարագրված հերթականությամբ: Հիշեք, որ NULL-ը կարող է լինել, ինչպես փաստաթղթերի տեղադրման դեպքում, ներառյալ. ոչ միայն հաշվապահական, այլ նաև ինչ-որ տեղ փաստաթղթի/տեղեկագրքի ձևի վրա, որոշ մանրամասներով, բայց այս դեպքում այն հավանաբար չի էլ բացվի:

Բացի այդ, եթե այս սխալը ձեզ հայտնվեց փաստաթուղթ տեղադրելիս, Bukh KORP ֆայլի տվյալների բազան SQL-ին փոխանցելուց հետո (իսկ տվյալների բազան ի սկզբանե PROF էր), դա նշանակում է, որ այն փաստաթղթերը, որոնք ստեղծվել են PROF տարբերակում, այժմ նույնպես գտնվում են ենթահաշիվների գրանցումը հարկային մարմնում NULL արժեքը և SQL տվյալների բազան դա չի ընդունում: Իսկ տվյալների բազան SQL-ում բեռնելիս կհայտնվի հետևյալ սխալը. Այստեղ, փաստորեն, ֆայլերի տվյալների բազայում NULL արժեքներ չեն լինի, բայց SQL-ն իր աղյուսակներում կբեռնի հենց այդպիսի արժեքներ: Հետևաբար, այստեղ մենք պետք է ստիպենք SQL տվյալների բազան ստեղծել այս NULL-ները և այնուհետև ուղղել դրանք ֆայլերի տվյալների բազայում, բայց ես չեմ կարող ձեզ ասել, թե ինչպես դա անել:

Ի՞նչ է ինդեքսը:

Ինդեքսների ֆիզիկական էությունը MS SQL Server 2005-ում:

Եզակի ցուցանիշ

Ինչ անել?

Կարդացեք նաև