Уникален индекс 1c sql. Грешка: Опит за вмъкване на неуникална стойност в уникален индекс: microsoft sql сървър

01.12.2019

Прочетете също

Създайте стартиращо флаш устройство в Rufus

На какво трябва да обърнете внимание, когато купувате SSD?

Как да премахнете напълно безплатната антивирусна програма avast от вашия компютър

Как да свържете кабелен интернет на Windows 10

Попаднали сте на съобщение, съдържащо редовете:
Доставчик на Microsoft OLE DB за SQL Server: CREATE UNIQUE INDEX прекратено, защото е намерен дублиран ключ за ИД на индекс
или
Не мога да I_nsert дублиран ключов ред в обект
или
Направен е опит за вмъкване на неуникална стойност в уникален индекс.

Опции за решение:

1. В студиото за управление на SQL Server ние физически унищожаваме неуспешния индекс (в моя случай това беше индекс в таблицата с общи суми на счетоводния регистър). В 1C ще разпространяваме дефектни документи. В режим на тестване и корекция поставете отметки в квадратчетата за преиндексиране на таблици + преизчисляване на суми. 1C пресъздава индекса без грешка. Изпълняваме неуспешни преди това документи.

2. 1) В Управление Studio 2005 генерира скрипт за създаване за създаване на индекс, който имаше грешки, и го записа във файл.
2) Ръчно уби индекса от таблицата _AccumRgTn19455
3) Стартира заявка като
SQL код S_elect count(*), index_fields
ОТ AccumRgTn19455
ГРУПИРАНЕ ПО index_field
ИМАЩ count(*)>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. Ако е възможно да работите с базата данни във файловата версия, тогава извършете Тестване и коригиране, както и Конфигурация - Проверка на конфигурацията - Проверка на логическата цялост на конфигурацията + Търсене на неправилни връзки.

1.3. Ако няма вариант на файл, опитайте да заредите от DT към вариант клиент/сървър на DB2 (който е по-малко придирчив към уникалността) и след това изпълнете Тестване и поправка и Конфигуриране - Проверка на конфигурацията - Проверка на логическата цялост на конфигурацията + Търсене на лоши препратки.

1.4. За да локализирате проблема, можете да определите данните на обекта, чието зареждане е неуспешно. За да направите това, трябва да активирате проследяване по време на зареждане в помощната програма Profiler или да активирате регистриране в регистъра на събитията на DBMSSQL и EXCP процеса.

2. Ако проблемът с неуникалността се проявява по време на работата на потребителите:

2.1. Намерете проблемната заявка, като използвате метода от параграф 1.4.

2.1.2. Понякога възниква грешка по време на изпълнение на заявки, например:

Тази грешка възниква поради факта, че в модула на регистъра за натрупване „Работно време на служителите на организациите“ в процедурата „Преизчисления на регистъра“ в заявката няма служебна дума „РАЗЛИЧЕН“.
Код 1C v 8.x Т.е. би трябвало:
Заявка = Нова заявка(
„ИЗБЕРЕТЕ РАЗЛИЧНОТО
| Основен.Индивидуален,
. . . . .
В последните издадени версии на 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_RTRef, _Fld139 3_RR Ref _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Преди да следвате процедурата по-долу, направете архивиранеБаза данни.
Стартирайте в MS SQL Server Query Analyzer:
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_вмъквам в _Document140_VT1385
S_изберете #tmp1

D_rop таблица #tmp1

Описаната процедура трябва да се извърши за всяка двойка дублиращи се записи.

2.2.3. Втори пример:
SQL код S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
ОТ _Reference8_
ГРУПИРАНЕ ПО _IDRRef, _Описание
ИМАЩ (БРОЙ(*) > 1)

2.3.4 Пример за дефиниране на неуникални записи с помощта на заявка 1C:Enterprise:
Код 1C v 8.x ИЗБЕРЕТЕ Наръчник.Връзка
ОТ Указател Указател AS Указател
ГРУПИРАЙ ПО
ИМАЩ КОЛИЧЕСТВО(*) > 1

Опции за решение:

2. 1) С помощта на Management Studio 2005 генерирах скрипт за създаване на индекс, който имаше грешки, и го записах във файл.
2) Ръчно уби индекса от таблицата _AccumRgTn19455
3) Стартира заявка като
SQL код S_elect count(*), index_fields
ОТ AccumRgTn19455
ГРУПИРАНЕ ПО index_field
ИМАЩ count(*)>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.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_RTRef, _Fld139 3_RR Ref _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Моля, архивирайте вашата база данни, преди да следвате процедурата по-долу.
Стартирайте в MS SQL Server Query Analyzer:
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_вмъквам в _Document140_VT1385
S_изберете #tmp1

D_rop таблица #tmp1

Описаната процедура трябва да се извърши за всяка двойка дублиращи се записи.

2.2.3. Втори пример:
SQL код S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
ОТ _Reference8_
ГРУПИРАНЕ ПО _IDRRef, _Описание
ИМАЩ (БРОЙ(*) > 1)

Възниква грешка, ако някои обекти, атрибути, subconto имат NULL стойност в базата данни, но не могат да имат такава стойност. И тази грешка се появява само в SQL бази данни. Тези. ако такава база данни се разтовари във файлова, тогава тази грешка няма да бъде там. защото файловата база има собствени таблици (общо 4), а SQL има свои. И SQL базата данни реагира критично на такива стойности в своите таблици.

Този проблем не се решава от никакви тестове (нито външни, нито вътрешни) във варианти на база данни (SQL или файл) и дори процедурата _1sp_DBReindex в SQL мениджъра, която изглежда трябва да преструктурира таблици в SQL.

Нека анализираме решението на проблема, като използваме примера за прехода от Счетоводство 3.0 PROF към CORP. След прехода сметка 68.01 има нов подконто Регистрация В данъчната служба. И тогава, в базите данни на SQL, всички създадени в PROF версията на документите, които използват този акаунт, няма да бъдат пренасочени. Грешката, показана по-горе, ще се появи. защото този нов подконто за стари документи, в публикации, ще бъде написан с NULL стойност (въпреки че трябва да бъде празна стойност, добре, или по някакъв начин данъчните власти).

За да разрешите тази грешка, трябва да премахнете NULL стойностите там, където не трябва да бъдат. В този случай в документи, където се използва подконто РегистрацияВ данъчния орган. Можете да направите това, като напишете обработка, която ще замени NULL с празна стойност (готовата обработка може да бъде изтеглена от тази статия). Направете обработка, т.к. опит за ръчна промяна на стойността на този подконто в осчетоводяването на документ води до същата грешка.

Обработка за замяна на NULL "s във всички подконтакти Регистрация в данъчните власти може да бъде изтеглена от тази статия по-долу.

НО няма да работи да замените NULL в SQL базата данни, същата грешка ще бъде генерирана по време на обработката. Следователно трябва да направите следното:

1. Качете вече работещата, преведена на CORP версия, SQL база данни в dt'snik (в конфигуратора Администрация - Качване на база данни - изберете къде да качите базата данни под формата на *.dt файл)

2. Заредете dt'snik във файловата база (в ненужен или предварително подготвен, чист, файлова база, в конфигуратора Администриране - Зареждане на база данни - изберете предварително разтоварените dt's)

3. Извършете обработка във файловата база (няма да има грешка и всички NULL ще бъдат правилно заменени) (как да извършите обработка е описано по-долу)

5. Сега, напротив, разтоварете dt от файловата база и я заредете в SQL базата данни. Сега, когато публикувате обработени документи, няма да има грешки.

Обработката от тази статия намира всички документи за посочения период, в които подконтактът RegisterIn Tax Authority се появява в транзакциите (което се появява във версията на CORP), което има NULL стойност. И заменя тази стойност с празна стойност.

При обработката трябва да посочите периода, за който трябва да обработите документите (възможно е за целия период, в който се съхраняват записите в базата данни) и щракнете върху „Попълване таблична част". След това можете да поставите отметка в квадратчетата кои документи да бъдат обработени (можете да изберете всички) и да щракнете върху бутона „Извършване на обработка“.

Съответно ако някой има същата грешка, но НЕ след преминаване към CORP, а примерно след обмен, зареждане на някакви данни, извършване на някаква обработка и т.н. След това е необходимо да се идентифицира къде е присвоена стойността NULL в определен документ/директория и да се премахне тази NULL по подобен начин, но чрез собствена обработка, но в реда, както е описано по-горе. Не забравяйте, че NULL може да бъде, както при осчетоводяването на документи, вкл. не само счетоводство, но някъде във формата на документ / директория, в някои подробности, но в този случай вероятно дори няма да се отвори.

Освен това, ако сте имали тази грешка при публикуване на документ, след като сте прехвърлили файловата база на Bukh CORP в SQL (и базата данни първоначално е PROF), това означава, че тези документи, които са създадени в PRO версията, сега също са в RegistrationIn Tax Органът подконтира стойността NULL и SQL базата данни не приема това. И при зареждане на базата данни в SQL ще се появи такава грешка. Тук всъщност няма да има NULL стойности във файловата база, но SQL ще зареди точно такива стойности в своите таблици. Ето защо тук е необходимо да принудите SQL базата данни да създаде тези NULL "и след това да ги коригира във файловата база данни. Но няма да ви кажа как да направите това.

Опции за решение:

2. 1) С помощта на Management Studio 2005 генерирах скрипт за създаване на индекс, който имаше грешки, и го записах във файл.
2) Ръчно уби индекса от таблицата _AccumRgTn19455
3) Стартира заявка като
SQL код S_elect count(*), index_fields
FR OM AccumRgTn19455
ГРУПИРАНЕ ПО index_field
ИМАЩ count(*)>1
След като индексът беше убит, показах 15 дублиращи се записа, въпреки че преди стъпка 2 заявката не върна нищо.
4) Прегледах всички записи и ръчно изчистих дубликатите. Всъщност използвах и обработката на „Структурата на отчета“, за да разбера с какво имам работа като цяло. Оказа се, че таблицата _AccumRgTn19455 съхранява регистъра за натрупване "Продукция (данъчно счетоводство)". Разрових се и с sql заявки, идентифицирах 15 неуникални документа и след като изпълних всички действия, проверих в 1C дали тези документи се обработват нормално, без грешки. Разбира се, не си струва да почиствате маси на случаен принцип просто така: важно е да разберете какво се почиства и в какво може да се превърне.
5) Стартира заявка за създаване на индекс, който беше записан във файл.
6) Превключих базата данни в режим на един потребител и стартирах dbcc checkdb - този път нямаше грешки.
7) Прехвърли базата обратно в режим за един потребител.
Това е... проблемът е победен. Е, дори в 1C стартирах "Тестване и корекция", там също всичко мина добре, спря да се кълне в неуникален индекс.

1.3. Ако няма вариант на файл, опитайте да заредите от DT към вариант на DB2 клиент/сървър (който е по-малко придирчив към уникалността) и след това изпълнете Тестване и коригиране и Конфигурация - Проверка на конфигурация - Проверка на логическа цялост на конфигурация + Търсене на лоши препратки.

2. Ако проблемът с неуникалността се проявява по време на работата на потребителите:

2.1. Намерете проблемната заявка, като използвате метода от параграф 1.4.

2.1.2. Понякога възниква грешка по време на изпълнение на заявки, например:

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_RTRef, _Fld139 3_RR Ref _Fld1394,_Fld1395 _RTRef, _Fld22261_RRRef
Моля, архивирайте вашата база данни, преди да следвате процедурата по-долу.
Стартирайте в MS SQL Server Query Analyzer:
SQL код S_elect count(*), _Document140_IDRRef, _KeyField
от _Document140_VT1385
групиране по _Document140_IDRRef, _KeyField
с брой (*) > 1
Използвайте го, за да разберете стойностите на колоните _Document140_IDRRef, _KeyField, дублирани записи (id, ключ).

С молба:
SQL код S_elect *
от _Document140_VT1385
където _Document140_IDRRef = id1 и _KeyField = key1 или _Document140_IDRRef = id2 и _KeyField = key2 или ...
погледнете стойностите на други колони с дублирани записи.
Ако и двата записа имат значими стойности и тези стойности са различни, тогава фиксирайте стойността на _KeyField, за да бъде уникална. За да направите това, дефинирайте максималната заета стойност на _KeyField(keymax):
SQL код S_elect max(_KeyField)
от _Document140_VT1385
wh ere_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_VT1385
където _Document140_IDRRef = id1 и _KeyField = key1

I_вмъквам в _Document140_VT1385
S_изберете #tmp1

D_rop таблица #tmp1

Описаната процедура трябва да се извърши за всяка двойка дублиращи се записи.

2.2.3. Втори пример:
SQL код S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
ОТ _Reference8_
ГРУПИРАНЕ ПО _IDRRef, _Описание
ИМАЩ (БРОЙ(*) > 1)

Информацията е взета от сайта