Вам зустрілося повідомлення, що містить рядки:
Microsoft OLE DB Provider for SQL Server: CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID
або
Can not I_nsert duplicate key row in object
або
Спроба вставки неунікального значення в унікальний індекс.
Варіанти вирішення:
1. У SQL Server managment studio фізично знищуємо зіпсований індекс (в моєму випадку це був індекс по таблиці підсумків регістра бухгалтерії). В 1С распроводім збійні документи. У режимі тестування і виправлення ставимо галки реіндексація таблиць + перерахунок підсумків. 1С відтворює індекс вже без помилки. Проводимо раніше сбоівшіе документи.
2.
1) За допомогою Management Studio 2005 згенерувала create-скрипт на створення індексу, який глючил, і зберегла в файлик.
2) Вручну вбила косячний індекс з таблиці _AccumRgTn19455
3) Запустила запит виду
Код SQL S_elect count (*), поля_індекса
FROM AccumRgTn19455
GROUP BY поля_індекса
HAVING count (*)\u003e 1
Після того, як індекс був убитий, у мене відобразилося 15 дублюються записів, хоча до виконання п.2 запит нічого не повертав.
4) Просмотрела всі записи і вручну почистила дублікати. Насправді, я ще користувалася обробкою "Структура звіту", щоб зрозуміти, з чим взагалі маю справу. Виявилося, що в таблиці _AccumRgTn19455 зберігається регістр накопичення "Випуск продукції (податковий облік)". Я ще поколупатися sql-запитів, виявила 15 неунікальний документів і після закінчення всіх дійств перевірила в 1С, що ці документи проводяться нормально, без помилок. Просто так чистити таблиці навмання, звичайно, не варто: важливо розуміти, що чиститься і чим це може обернутися.
5) Запустила запит на створення індексу, який був збережений у файлі.
6) Переклала базу в одного користувача режим і запустила dbcc checkdb - на цей раз жодної помилки не видалося.
7) Переклала базу назад в одного користувача режим.
Все ... проблема переможена. Ну ще в 1С запустила "Тестування і виправлення", там теж все пройшло нормально, перестало лаятися на неунікальний індекс.
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.х Тобто повинно бути:
Запит \u003d Новий запит (
"ВИБРАТИ РІЗНІ
| Основние.ФізЛіцо,
. . . . .
В останніх випущених релізах ЗУП і УПП помилка не виникає, тому що там стоїть "РІЗНІ".
2.2. Після знаходження проблемного індексу з попереднього пункту, необхідно знайти неунікальні запис.
2.2.1. «Риба» скрипта для визначення неунікальний записів за допомогою SQL:
Код SQL S_elect COUNT (*) Counter,<перечисление всех полей соответствующего индекса> from<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
HAVING Counter\u003e 1
2.2.2 Приклад. Індекс в помилку називається "_Document140_VT1385_IntKeyIndNG".
Перелік полів таблиці:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Перед виконанням наведеної нижче процедури зробіть резервну копію бази даних.
Виконайте в MS SQL Server Query Analizer:
Код SQL S_elect count (*), _Document140_IDRRef, _KeyField
from _Document140_VT1385
group by _Document140_IDRRef, _KeyField
having count (*)\u003e 1
З його допомогою дізнайтеся значення колонок _Document140_IDRRef, _KeyField, що дублюються записів (id, key).
За допомогою запиту:
Код SQL S_elect *
from _Document140_VT1385
or _Document140_IDRRef \u003d id2 and _KeyField \u003d key2 or ...
подивіться на значення інших колонок дублюються записів.
Якщо обидва записи мають осмислені значення і ці значення різні, то виправте значення _KeyField на унікальне. Для цього визначте максимальне зайняте значення _KeyField (keymax):
Код SQL S_elect max (_KeyField)
from _Document140_VT1385
where _Document140_IDRRef \u003d id1
Замініть значення _KeyField в одній з повторюваних записів на правильне:
Код SQL update _Document140_VT1385
set _KeyField \u003d keymax + 1
Тут _LineNo1386 \u003d - додаткову умову, Яке дозволяє вибрати одну з двох повторюваних записів.
Якщо одна (або обидві) з повторюваних записів має очевидно неправильне значення, то її потрібно видалити:
Код SQL delete from _Document140_VT1385
where _Document140_IDRRef \u003d id1 and _LineNo1386 \u003d lineno1
Якщо повторювані записи мають однакові значення у всіх колонках, то з них потрібно залишити одну:
Код SQL S_elect distinct *
into # tmp1
from _Document140_VT1385
where _Document140_IDRRef \u003d id1 and _KeyField \u003d key1
Delete from _Document140_VT1385
where _Document140_IDRRef \u003d id1 and _KeyField \u003d key1
I_nsert into _Document140_VT1385
S_elect # tmp1
D_rop table # tmp1
Описану процедуру необхідно виконати для кожної пари повторюваних записів.
2.2.3. Другий приклад:
Код SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Reference8_
GROUP BY _IDRRef, _Description
HAVING (COUNT (*)\u003e 1)
2.3.4 Приклад визначення неунікальний записів за допомогою запиту 1С: Підприємство:
Код 1C v 8.х ВИБРАТИ Справочнік.Ссилка
З Справочнік.Справочнік ЯК Довідник
Згруповані за Справочнік.Ссилка
МАЮТЬ КІЛЬКІСТЬ (*)\u003e 1
Помилка виникає, якщо в базі є у якихось об'єктів, реквізитів, субконто - значення NULL, а у них такого значення бути не може. І з'являється така помилка тільки в SQL базах. Тобто якщо таку базу вивантажити в файлову, то там вже цієї помилки не буде. Оскільки у файлової бази свої таблиці (всього 4 шт.), а у SQL свої. І SQL база критично реагує на такі значення в своїх таблицях.
Ця проблема не вирішується ніякими тестуваннями (ні зовнішнім, ні внутрішнім) ні в яких випадках баз (SQL або файлова) і навіть Процедурою _1sp_DBReindex в менеджері SQL, яка ніби як повинна проводити реструктуризацію таблиць в SQL.
Розберемо вирішення проблеми на прикладі переходу з Бухгалтерії 3.0 ПРОФ на КОРП. Після переходу у рахунку 68.01 з'являється нове субконто РегістраціяВНалоговомОргане. І тоді, в базах на SQL, все створення в ПРОФ версії документи які використовують цей рахунок, що не будуть перепроводити. Виходитиме вище показана помилка. Оскільки це нове субконто у старих документів, в проводках, запишеться зі значенням NULL (хоча повинно бути Пусте значення, ну або як-небудь податковий орган).
Щоб усунути цю помилку, потрібно прибрати значення NULL там, де їх не повинно бути. В даному випадку в документах, де використовується субконто РегістраціяВНалоговомОргане. Зробити це можна, написавши обробку, яка замінить NULL на Пусте значення (готову обробку можна завантажити з цієї статті). Робити обробкою, тому що спроба змінити значення цього субконто в проводках документа вручну, призводить до все тієї ж помилку.
Обробку для заміни NULL "ов у всіх субконто РегістраціяВНалоговомОргане можна скачати з цієї статті, внизу.
АЛЕ так замінити NULL в SQL базі не вийде, під час виконання обробки буде видана та ж сама помилка. Тому необхідно зробити так:
1. вивантажити вже робочу, перекладену на КОРП версію, SQL базу в dt'шнік (в конфігураторі Адміністрування - вивантажити базу - виберіть куди вивантажити базу у вигляді файлу * .dt)
2. Завантажити dt'шнік в файлову базу (в непотрібної або заздалегідь підготовленої, чистою, файлової базі, в конфігураторі Адміністрування - Завантажити базу - вибрати вивантажений раніше dt'шнік)
3. Виконати обробку в файлової базі (там помилки не буде і все NULL'и коректно замінюватися) (як виконати обробку описано нижче)
5. Тепер навпаки вивантажити dt'шнік з файлової бази і завантажити його в SQL базу. Тепер при проведенні оброблених документів помилки виходити не буде.
Обробка з цієї статті знаходить всі документи, за вказаний період, у яких в проводках фігурує субконтно РегістраціяВНалоговомОргане (яке з'являється в КОРП версії), у якого значення NULL. І замінює це значення на Пусте значення.
В обробці необхідно вказати період, за який необхідно обробити документи (можна за весь період в якому ведеться облік в базі) і натиснути «Заповнити табличну частину». Після чого можна галками помітити якісь документи обробити (можна вибрати все) та натиснути кнопку «Виконати обробку».
Відповідно якщо у кого-то така ж помилка, але НЕ після переходу на КОРП, а на приклад після обміну, завантаження якихось даних, виконання якихось обробок і т.д. То необхідно виявити, де присвоїлось значення NULL в конкретному документі / довіднику і подібним способом прибрати цей NULL але вже своєї обробкою, але в тому порядку, як описано вище. Пам'ятайте, що NULL може бути, як в проводках документа, в т.ч. не тільки бухгалтерських, так і де-небудь на формі документа / довідника, в якому-небудь реквізиті, але в такому випадку він напевно навіть не відкриється.
Також якщо це помилка з'явилася у вас під час проведення документа, після того як ви перевели файлову базу Бух КОРП на SQL (а база колись спочатку була ПРОФ), то значить у тих документів що були створені в ПРОФ версії, зараз також в субконто РегістраціяВНалоговомОргане значення NULL і SQL база таке не сприймає. І при завантаженні бази в SQL буде виходити така помилка. Тут насправді в файлової базі значень NULL по факту не буде, але SQL в свої таблиці завантажить саме такі значення. Тому тут треба змусити базу SQL створити ці NULL "и і потім в файлової базі їх виправити. Але як це зробити, вже не підкажу.
Вам зустрілося повідомлення, що містить рядки:
Microsoft OLE DB Provider for SQL Server: CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID
або
Can not I_nsert duplicate key row in object
або
Спроба вставки неунікального значення в унікальний індекс.
Варіанти вирішення:
1. У SQL Server managment studio фізично знищуємо зіпсований індекс (в моєму випадку це був індекс по таблиці підсумків регістра бухгалтерії). В 1С распроводім збійні документи. У режимі тестування і виправлення ставимо галки реіндексація таблиць + перерахунок підсумків. 1С відтворює індекс вже без помилки. Проводимо раніше сбоівшіе документи.
2.
1) За допомогою Management Studio 2005 згенерувала create-скрипт на створення індексу, який глючил, і зберегла в файлик.
2) Вручну вбила косячний індекс з таблиці _AccumRgTn19455
3) Запустила запит виду
Код SQL S_elect count (*), поля_індекса
FR OM AccumRgTn19455
GROUP BY поля_індекса
HAVING count (*)\u003e 1
Після того, як індекс був убитий, у мене відобразилося 15 дублюються записів, хоча до виконання п.2 запит нічого не повертав.
4) Просмотрела всі записи і вручну почистила дублікати. Насправді, я ще користувалася обробкою "Структура звіту", щоб зрозуміти, з чим взагалі маю справу. Виявилося, що в таблиці _AccumRgTn19455 зберігається регістр накопичення "Випуск продукції (податковий облік)". Я ще поколупатися sql-запитів, виявила 15 неунікальний документів і після закінчення всіх дійств перевірила в 1С, що ці документи проводяться нормально, без помилок. Просто так чистити таблиці навмання, звичайно, не варто: важливо розуміти, що чиститься і чим це може обернутися.
5) Запустила запит на створення індексу, який був збережений у файлі.
6) Переклала базу в одного користувача режим і запустила dbcc checkdb - на цей раз жодної помилки не видалося.
7) Переклала базу назад в одного користувача режим.
Все ... проблема переможена. Ну ще в 1С запустила "Тестування і виправлення", там теж все пройшло нормально, перестало лаятися на неунікальний індекс.
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.х Тобто повинно бути:
Запит \u003d Новий запит (
"ВИБРАТИ РІЗНІ
| Основние.ФізЛіцо,
. . . . .
В останніх випущених релізах ЗУП і УПП помилка не виникає, тому що там стоїть "РІЗНІ".
2.2. Після знаходження проблемного індексу з попереднього пункту, необхідно знайти неунікальні запис.
2.2.1. «Риба» скрипта для визначення неунікальний записів за допомогою SQL:
Код SQL S_elect COUNT (*) Counter,<перечисление всех полей соответствующего индекса> fr om<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
HAVING Counter\u003e 1
2.2.2 Приклад. Індекс в помилку називається "_Document140_VT1385_IntKeyIndNG".
Перелік полів таблиці:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Перед виконанням наведеної нижче процедури зробіть резервну копію бази даних.
Виконайте в MS SQL Server Query Analizer:
Код SQL S_elect count (*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
group by _Document140_IDRRef, _KeyField
having count (*)\u003e 1
З його допомогою дізнайтеся значення колонок _Document140_IDRRef, _KeyField, що дублюються записів (id, key).
За допомогою запиту:
Код SQL S_elect *
fr om _Document140_VT1385
where _Document140_IDRRef \u003d id1 and _KeyField \u003d key1 or _Document140_IDRRef \u003d id2 and _KeyField \u003d key2 or ...
подивіться на значення інших колонок дублюються записів.
Якщо обидва записи мають осмислені значення і ці значення різні, то виправте значення _KeyField на унікальне. Для цього визначте максимальне зайняте значення _KeyField (keymax):
Код SQL S_elect max (_KeyField)
fr om _Document140_VT1385
wh ere _Document140_IDRRef \u003d id1
Замініть значення _KeyField в одній з повторюваних записів на правильне:
Код SQL upd ate _Document140_VT1385
set _KeyField \u003d keymax + 1
Тут _LineNo1386 \u003d - додаткова умова, що дозволяє вибрати одну з двох повторюваних записів.
Якщо одна (або обидві) з повторюваних записів має очевидно неправильне значення, то її потрібно видалити:
Код SQL delete from _Document140_VT1385
wh ere _Document140_IDRRef \u003d id1 and _LineNo1386 \u003d lineno1
Якщо повторювані записи мають однакові значення у всіх колонках, то з них потрібно залишити одну:
Код SQL S_elect distinct *
into # tmp1
from _Document140_VT1385
Delete from _Document140_VT1385
wh ere _Document140_IDRRef \u003d id1 and _KeyField \u003d key1
I_nsert into _Document140_VT1385
S_elect # tmp1
D_rop table # tmp1
Описану процедуру необхідно виконати для кожної пари повторюваних записів.
2.2.3. Другий приклад:
Код SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Reference8_
GROUP BY _IDRRef, _Description
HAVING (COUNT (*)\u003e 1)
2.3.4 Приклад визначення неунікальний записів за допомогою запиту 1С: Підприємство:
Код 1C v 8.х ВИБРАТИ Справочнік.Ссилка
З Справочнік.Справочнік ЯК Довідник
Згруповані за Справочнік.Ссилка
МАЮТЬ КІЛЬКІСТЬ (*)\u003e 1
Інформація взята з сайту
У цій статті буде описано, що робити, якщо при роботі з 1С: Підприємство 8.1 Вам зустрілося повідомлення, що містить рядки:
Can not insert duplicate key row in object
Спроба вставки неунікального значення в унікальний індекс.
Що таке індекс?
Індекси являють собою структуру, що дозволяє виконувати прискорений доступ до рядків таблиці на основі значень одного або більше її стовпців.
Індекс містить ключі, побудовані з одного або декількох стовпців таблиці або подання, і покажчики, які зіставляються з місцем зберігання заданих даних.
Індекси скорочують обсяг даних, які необхідно вважати, щоб повернути результуючий набір.
Хоча індекс і пов'язаний з конкретним стовпцем (або стовпцями) таблиці, все ж він є самостійним об'єктом бази даних.
Індекси таблиць в базі даних 1С: Підприємство створюються неявним чином при створенні об'єктів конфігурації, а також при тих чи інших налаштуваннях об'єктів конфігурації.
Фізична сутність індексів в MS SQL Server 2005.
Фізично дані зберігаються на 8Кб сторінках. Відразу після створення, поки таблиця не має індексів, таблиця виглядає як купа (heap) даних. Записи не мають певного порядку зберігання.
Коли ви хочете отримати доступ до даних, SQL Server буде виробляти сканування таблиці (Table scan). SQL Server сканує всю таблицю, що б знайти шукані запису.
Звідси стають зрозумілими базові функції індексів:
- збільшення швидкості доступу до даних,
- підтримка унікальності даних.
Незважаючи на переваги, індекси так само мають і ряд недоліків. Перший з них - індекси займають додаткове місце на диску і в оперативної пам'яті. Кожен раз коли ви створюєте індекс, ви зберігаєте ключі в порядку зменшення чи збільшення, які можуть мати багаторівневу структуру. І чим більше / довший ключ, тим більше розмір індексу. Другий недолік - сповільнюються операції вставки, оновлення та видалення записів.
У середовищі MS SQL Server 2005 реалізовано декілька типів індексів:
- некластерние індекси;
- кластерні (або Групові) індекси;
- унікальні індекси;
- індекси з включеними стовпцями
- індексовані уявлення
- повнотекстовий
унікальний індекс
Унікальність значень в індексованих стовпці гарантують унікальні індекси. При їх наявності сервер не дозволить вставити нове або змінити існуюче значення таким чином, щоб в результаті цієї операції в стовпці з'явилися два однакових значення.
Унікальний індекс є своєрідною надбудовою і може бути реалізований як для кластерного, так і для некластерного індексу. В одній таблиці може існувати один унікальний кластерний і безліч унікальних некластерних індексів.
Унікальні індекси слід визначати тільки тоді, коли це дійсно необхідно. Для забезпечення цілісності даних в стовпці можна визначити обмеження цілісності UNIQUE або PRIMARY KEY, а не вдаватися до унікальних індексам. Їх використання тільки для забезпечення цілісності даних є невиправданою тратою простору в базі даних. Крім того, на їх підтримку витрачається і процесорний час.
1С: Підприємство 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. Іноді помилка виникає під час виконання запитів, наприклад:
Дана помилка виникає через те що в модулі регістра накопичення «Робочий час працівників організацій» в процедурі «ЗарегістріроватьПерерасчети» в запиті не варто службове слово «РІЗНІ».
Тобто повинно бути:
Запит \u003d Новий запит (
«ВИБРАТИ РІЗНІ
| Основние.ФізЛіцо,
В останніх випущених релізах ЗУП і УПП помилка не виникає, тому що там стоїть «РІЗНІ».
2.2. Після знаходження проблемного індексу з попереднього пункту, необхідно знайти неунікальні запис.
2.2.1. «Риба» скрипта для визначення неунікальний записів за допомогою SQL:
SELECT COUNT (*) Counter,<перечисление всех полей соответствующего индекса> from<имя таблицы>
GROUP BY<перечисление всех полей соответствующего индекса>
HAVING Counter\u003e 1
2.2.2 Приклад. Індекс в помилку називається «_Document140_VT1385_IntKeyIndNG».
Перелік полів таблиці:
Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394,
Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Перед виконанням наведеної нижче процедури зробіть резервну копію бази даних.
Виконайте в MS SQL Server Query Analizer:
select count (*), _Document140_IDRRef, _KeyField
from _Document140_VT1385
group by _Document140_IDRRef, _KeyField
having count (*)\u003e 1
З його допомогою дізнайтеся значення колонок _Document140_IDRRef, _KeyField, що дублюються записів (id, key).
За допомогою запиту:
select *
from _Document140_VT1385
or _Document140_IDRRef \u003d id2 and _KeyField \u003d key2 or ...
подивіться на значення інших колонок дублюються записів.
Якщо обидва записи мають осмислені значення і ці значення різні, то виправте значення _KeyField на унікальне. Для цього визначте максимальне зайняте значення _KeyField (keymax):
select max (_KeyField)
from _Document140_VT1385
where _Document140_IDRRef \u003d id1
Замініть значення _KeyField в одній з повторюваних записів на правильне:
update _Document140_VT1385
set _KeyField \u003d keymax + 1
Тут _LineNo1386 \u003d - додаткова умова, що дозволяє вибрати одну з двох повторюваних записів.
Якщо одна (або обидві) з повторюваних записів має очевидно неправильне значення, то її потрібно видалити:
where _Document140_IDRRef \u003d id1 and _LineNo1386 \u003d lineno1
Якщо повторювані записи мають однакові значення у всіх колонках, то з них потрібно залишити одну:
select distinct *
into # tmp1
from _Document140_VT1385
where _Document140_IDRRef \u003d id1 and _KeyField \u003d key1
delete from _Document140_VT1385
where _Document140_IDRRef \u003d id1 and _KeyField \u003d key1
insert into _Document140_VT1385
select # tmp1
drop table # tmp1
Описану процедуру необхідно виконати для кожної пари повторюваних записів.
2.2.3. Другий приклад:
SELECT COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
FROM _Reference8_
GROUP BY _IDRRef, _Description
HAVING (COUNT (*)\u003e 1)
2.3.4 Приклад визначення неунікальний записів за допомогою запиту 1С: Підприємство:
або для бухгалтерії
ВИБРАТИ
Подзапрос.Період,
Подзапрос.Регістратор,
<измерения>,
СУМА (Подзапрос.КолічествоЗапісей) ЯК КолічествоЗапісей
З
(ВИБРАТИ
Хозрасчетний.Період ЯК Період,
Хозрасчетний.Регістратор ЯК Реєстратор,
<измерения>,
1 ЯК КолічествоЗапісей
З
РегістрБухгалтеріі.Хозрасчетний ЯК Госпрозрахунковий) ЯК підзапитів
згруповані за
Подзапрос.Період,
Подзапрос.Регістратор,
<измерения>
МАЮТЬ
СУМА (Подзапрос.КолічествоЗапісей)\u003e 1
2.3.5 Зробити індекс СУБД не рідкість. Заксріптовать індекс за допомогою Management Studio.
2.3.6 Окремий випадок при обміні в РБД. Помилка доводиться на «допоміжні» таблиці, пов'язані з розрахунком підсумків або аналітики. наприклад:
Помилка при виклику методу контексту (Записати): Спроба вставки неунікального значення в унікальний індекс:
Microsoft OLE DB Provider for SQL Server: Can not insert duplicate key row in object 'dbo._AccntRegED10319' with unique index '_Accnt10319_ByPeriod_TRNRN'.
HRESULT \u003d 80040E2F, SQLSrvr: Error state \u003d 1, Severity \u003d E, native \u003d 2601, line \u003d 1
У цьому випадки перед завантаженням вимкнути використання підсумків, завантажити повідомлення, включити використання підсумків і перерахувати.
