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

Решения:

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

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 стартирах „Тестване и корекция“, там също всичко вървеше добре, спрях да се оплаквам от неуникалния индекс.

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, _fld133_rtref, Rrref, _fld1394, _fld1395, _fld1396rref, _fld1397, _fld1398, _fld1399rref, _fld2260_type, _fld22260_rtref, _fld2260_ Fld22261 _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
където е _Document140_IDRRef = id1
Заменете стойността _KeyField в един от дублиращите се записи с правилната:
SQL кодът е актуализиран _Document140_VT1385
задайте _KeyField = keymax + 1

Тук _LineNo1386 = е допълнително условие, което ви позволява да изберете един от два повтарящи се записа.

Ако един (или и двата) от дублиращите се записи има очевидно неправилно значение, тогава той трябва да бъде премахнат:
Изтриване на SQL код от _Document140_VT1385
където са _Document140_IDRRef = id1 и _LineNo1386 = lineno1
Ако дублиращите се записи имат еднакви стойности във всички колони, тогава трябва да оставите една от тях:
SQL код S_elect distinct *
в #tmp1
от_Документ140_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)

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

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

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

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

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

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

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

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

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

2. Качете dt’shnik във файловата база данни (в ненужен или предварително подготвен, чист, файлова база данни, в конфигуратора Администриране – Зареждане на база данни – изберете предварително изтегления dt файл)

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

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

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

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

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

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

Тази статия ще опише какво да направите, ако при работа с 1C:Enterprise 8.1 срещнете съобщение, съдържащо редовете:

Не може да се вмъкне дублиран ключов ред в обект

Направен е опит за вмъкване на неуникална стойност в уникален индекс.

Какво е индекс?

Индексите са структура, която позволява бърз достъп до редове в таблица въз основа на стойностите на една или повече от нейните колони.
Индексът съдържа ключове, изградени от една или повече колони на таблица или изглед, и указатели, които картографират мястото, където се съхраняват посочените данни.
Индексите намаляват количеството данни, които трябва да бъдат прочетени, за да върнат набор от резултати.

Въпреки че индексът е свързан с конкретна колона (или колони) на таблица, той все още е отделен обект на база данни.

Индексите на таблиците в базата данни на 1C:Enterprise се създават имплицитно при създаване на конфигурационни обекти, както и при определени настройки на конфигурационни обекти.

Физическата същност на индексите в MS SQL Server 2005.

Физически данните се съхраняват на 8Kb страници. Веднага след създаването, докато таблицата няма индекси, таблицата изглежда като купчина данни. Записите нямат конкретен ред за съхранение.
Когато искате да получите достъп до данни, SQL Server ще произведе сканиране на маса(сканиране на таблица). SQL Server сканира цялата таблица, за да намери записите, които търси.
От тук стават ясни основните функции на индексите:
— увеличаване на скоростта на достъп до данни,
— поддръжка за уникалност на данните.

Въпреки предимствата си, индексите имат и редица недостатъци. Първият е индексите заемат допълнително дисково пространствои в RAM. Всеки път, когато създавате индекс, вие съхранявате ключовете в низходящ или възходящ ред, който може да има многостепенна структура. И колкото по-голям/по-дълъг е ключът, толкова по-голям размериндекс. Вторият недостатък е операциите се забавятвмъкване, актуализиране и изтриване на записи.
В средата на MS SQL Server 2005 са внедрени няколко вида индекси:

• неклъстърирани индекси;
• клъстерирани (или групирани) индекси;
• уникални индекси;
• индекси с включени колони
• индексирани изгледи
• пълен текст

Уникален индекс

Уникалността на стойностите в индексираната колона се гарантира от уникални индекси. Ако те присъстват, сървърът няма да ви позволи да вмъкнете нов или да промените съществуваща стойносттака че в резултат на тази операция в колоната се появяват две еднакви стойности.
Уникалният индекс е вид добавка и може да бъде приложен както за клъстерирани, така и за неклъстерирани индекси. Една таблица може да има един уникален клъстерен индекс и много уникални неклъстерирани индекси.
Уникалните индекси трябва да се дефинират само когато наистина е необходимо. За да осигурите целостта на данните в колона, можете да дефинирате ограничение за целостта на UNIQUE или PRIMARY KEY, вместо да прибягвате до уникални индекси. Използването им единствено за гарантиране на целостта на данните е загуба на пространство в базата данни. Освен това процесорното време се изразходва и за тяхната поддръжка.

1C:Enterprise 8.1, започвайки от версия 8.1, активно използва клъстерни уникални индекси. Това означава, че при конвертиране от 8.0 или мигриране от 8.1.7 може да получите неуникална грешка в индекса.

Ако неуникалността е в дати с нулеви стойности, тогава проблемът се решава чрез създаване на база данни с параметър за отместване, равен на 2000.

какво да правя

1. Ако проблемът е в зареждането на базата данни, тогава:

1.1. Ако зареждате (използвайки dt файл) в база данни на MS SQL Server, тогава, когато създавате базата данни преди зареждане, посочете отместването на датата - 2000.

Ако базата данни вече е създадена с отместване 0, създайте нова с 2000.

1.2. Ако е възможно да работите с базата данни във файловата версия, тогава извършете Тестване и Корекция, както и Конфигурация - Проверка на конфигурацията - Проверка на логическата цялост на конфигурацията + Търсене на неправилни връзки.

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

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“.

Списък на полетата на таблицата:

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RR Реф., _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld2226 1_RRRef

Преди да изпълните процедурата по-долу, моля, архивирайте вашата база данни.
Стартирайте в MS SQL Server Query Analyzer:

изберете брой(*), _Document140_IDRRef, _KeyField
от _Document140_VT1385
групиране по _Document140_IDRRef, _KeyField
с брой (*) > 1

Използвайте го, за да разберете стойностите на колоните _Document140_IDRRef, _KeyField, дублирани записи (id, ключ).

Използване на заявката:

изберете *
от _Document140_VT1385
или _Document140_IDRRef = id2 и _KeyField = key2 или...

погледнете стойностите на другите колони на дублиращите се записи.

Ако и двата записа имат значими стойности и стойностите са различни, тогава променете стойността _KeyField, за да бъде уникална. За да направите това, определете максималната заета стойност на _KeyField (keymax):

изберете max(_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, _Description
ОТ _Reference8_
ГРУПИРАНЕ ПО _IDRRef, _Описание
ИМАЩ (БРОЙ(*) > 1)

2.3.4 Пример за определяне на неуникални записи с помощта на заявка 1C:Enterprise:

или за счетоводство

ИЗБЕРЕТЕ
Подзаявка.Точка,
Subquery.Recorder,
<измерения>,
SUM(Подзаявка.Брой записи) AS Брой записи
ОТ
(ИЗБЕРЕТЕ
Самоподдържащ се период AS Период,
Самоподдържащ се. Регистратор AS Регистратор,
<измерения>,
1 AS Брой записи
ОТ
Счетоводен регистър Самоподдържащ се AS Подзапитване за AS

ГРУПИРАНЕ ПО
Подзаявка.Точка,
Subquery.Recorder,
<измерения>

ИМАЩ
SUM(Подзаявка.Брой записи) > 1

2.3.5 Направете subd индекса неуникален. Скриптирайте индекса с помощта на Management Studio.

2.3.6 Специален случай при обмен в RDB. Грешката възниква в „спомагателни“ таблици, свързани с изчисляването на суми или анализи. Например:

Грешка при извикване на контекстния метод (Write): Опит за вмъкване на неуникална стойност в уникален индекс:
Microsoft OLE DB доставчик за SQL Server: Не може да се вмъкне дублиран ключов ред в обект „dbo._AccntRegED10319“ с уникален индекс „_Accnt10319_ByPeriod_TRNRN“.
HRESULT=80040E2F, SQLSrvr: състояние на грешка=1, сериозност=E, естествено=2601, ред=1

В този случай, преди зареждане, изключете използването на общи суми, заредете съобщението, активирайте използването на общи суми и преизчислете.

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

Решения:

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

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 стартирах „Тестване и корекция“, там също всичко вървеше добре, спрях да се оплаквам от неуникалния индекс.

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, _fld133_rtref, Rrref, _fld1394, _fld1395, _fld1396rref, _fld1397, _fld1398, _fld1399rref, _fld2260_type, _fld22260_rtref, _fld2260_ Fld22261 _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 SELECT Directory.Link
ОТ указател.Указател AS Указател
ГРУПИРАНЕ ПО Директория.Връзка
ИМАЩ КОЛИЧЕСТВО(*) > 1