T-SQL + 1С: нумерация записей табличных частей и наборов регистров по порядку

22.12.16

Разработка - Механизмы платформы 1С

Обработка данных больших баз 1С часто выполняется средствами SQL. Это может быть свёртка или какая-то другая задача. После выполнения команды DELETE может нарушиться последовательность нумерации записей табличной части или набора регистра. Это может привести к неприятным последствиям, если её не восстановить. В данной публикации приводится достаточно простое решение этой проблемы.

Предположим, что нам необходимо свернуть все движения по выбывшей из оборота номенклатуре. Мы выполнили удаление движений по регистрам накопления и обнаружили, что нумерация записей наборов нарушилась. Это может выглядеть примерно вот так (значения в ячейках имеют демонстрационный характер для упрощения восприятия):

_Period _RecorderTRef _RecorderRRef _LineNo _Fld123RRef
01.01.2010 12:00:00 0x12 0x01 1 0x11
01.01.2010 12:00:00 0x12 0x01 2 0x22
01.01.2010 12:00:00 0x12 0x01 4 0x44

 где

_Period - период регистра накопления;

_RecorderTRef - код типа документа, например, Документ.ПоступлениеТоваровУслуг;

_RecorderRRef - ссылка на документ (имеет тип binary(16), по факту является GUID'ом);

_LineNo - порядковый номер записи набора регистра;

_Fld123RRef - измерение, ссылка на элемент справочника "Номенклатура" (в нашем примере так).

В данной таблице не хватает записи с номером строки _LineNo равным 3. Эта строка была удалена в процессе свёртки. Если мы оставим это так как есть, то, например, при выполнении такого кода 1С (проверялось на платформе 8.3):

Набор = РегистрыНакопления.ТоварыНаСкладах.СоздатьНаборЗаписей();
Набор.Отбор.Регистратор.Установить(ДокументСсылка);
Набор.Прочитать();
Набор.Записать();

 Можно неожиданно получить вот такой результат:

_Period _RecorderTRef _RecorderRRef _LineNo _Fld123RRef
01.01.2010 12:00:00 0x12 0x01 1 0x11
01.01.2010 12:00:00 0x12 0x01 2 0x22
01.01.2010 12:00:00 0x12 0x01 3 0x44
01.01.2010 12:00:00 0x12 0x01 4 0x44

Последняя строка в наборе регистра задублировалась. Как это произошло? Моя гипотеза такова: набор записей был успешно прочитан в оперативную память, а затем, при его записи обратно в базу данных, 1С восстановила последовательность нумерации и та строка, которая имела значение поля _LineNo равным 4 стала равна 3. В таком виде набор записывается в базу данных, но строка со значением _LineNo равным 4 из базы данных не была удалена и к ней дописываются строки со значениями _LineNo равными 1, 2 и 3, которые они получили в оперативной памяти. Таким образом получается дублирование.

В таких случаях требуется восстановить последовательность нумерации строк. Как это сделать наиболее простым способом? Это можно сделать при помощи следующей команды SQL:

UPDATE T
SET
    T.[_LineNo] = T.[RowNumber] -- Обновляем значения
FROM
    (SELECT
        T.[_LineNo] AS [_LineNo],
        -- Нумерация по порядку средствами SQL - используем оконные функции
        ROW_NUMBER() OVER(PARTITION BY T.[_RecorderRRef] ORDER BY T.[_LineNo]) AS [RowNumber]
    FROM
        [ИмяТаблицыРегистра] AS T
        INNER JOIN
            (SELECT
                [_RecorderRRef]  AS [_RecorderRRef],
                COUNT([_LineNo]) AS [LineCount], -- Количество строк в разрезе регистратора
                MAX([_LineNo])   AS [LineMax]    -- Максимальное значение номера строки в разрезе регистратора
            FROM
                [ИмяТаблицыРегистра]
            WHERE
                [_Period] < @Period -- Здесь может быть любое нужное нам условие отбора записей набора регистра
            GROUP BY
                [_RecorderRRef]
            HAVING
                COUNT([_LineNo]) <> MAX([_LineNo]) -- Таким образом мы отбираем регистраторы, у которых нарушилась нумерация

            ) AS U
        ON T.[_RecorderRRef] = U.[_RecorderRRef]) AS T; -- Фильтруем записи регистра по найденным регистраторам

Вместо [ИмяТаблицыРегистра] нужно подставить нужное имя таблицы регистра накопления. А вместо [_Period] < @Period можно использовать любое другое условие отбора нужных нам записей регистра накопления. Обращаю внимание на выражение COUNT([_LineNo]) <> MAX([_LineNo]), которое позволяет определить какие наборы записей были фрагментированы с точки зрения нумерации строк набора по порядку.

Краткое описание алгоритма:

1. Находим те регистраторы, у которых количество строк в наборе не равно максимальному значению номера строки этого набора (обнаруживаем фрагментацию).

2. Отбираем все записи регистра по полученным регистраторам, используя INNER JOIN.

3. При помощи оконной функции SQL вычисляем правильные порядковые номера строк в разрезе регистраторов.

4. Обновляем отобранные записи правильными значениями порядковых номеров строк.

Этот алгоритм аналогичным способом можно использовать для восстановления нумерации табличных частей.

Обновление от 19.07.2016

Прочитал книгу "Microsoft SQL Server 2012. Высокопроизводительный код T-SQL. Оконные функции." Ицик Бен Ган. Познакомился с алгоритмом поиска островков. Данная задача как раз из этого класса. Переписал код. В результате получился ещё более быстрый и, в тоже самое время, лаконичный код. Производительность увеличена примерно в 4 раза по сравнению с первым вариантом. Секрет успеха: избавление от внутреннего соединения и сортировки данных после него. Как следствие сократилось количество чтений и время использования CPU. Работа ведётся исключительно с кластерным индексом регистра накопления, в который входят поля _Period, _RecorderTRef, _RecorderRRef и _LineNo.

UPDATE T

SET

T.[_LineNo] = T.[RowNumber]

FROM

(SELECT

[_LineNo],

ROW_NUMBER() OVER (

PARTITION BY [_Period], [_RecorderTRef], [_RecorderRRef]

ORDER BY [_LineNo]) AS [RowNumber]

FROM

[ИмяТаблицыРегистра]

WHERE

[_Period] <= @Period) AS T

WHERE

T.[_LineNo] <> T.[RowNumber];

SQL свертка оптимизация обработка данных оконные функции

См. также

Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Эта небольшая статья - некоторого рода шпаргалка по файловым потокам: как и зачем с ними работать, какие преимущества это дает.

23.06.2024    6148    bayselonarrend    19    

153

Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Пример использования «Сервисов интеграции» без подключения к Шине и без обменов.

13.03.2024    5333    dsdred    16    

79

Механизмы платформы 1С Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Все мы используем массивы в своем коде. Это один из первых объектов, который дают ученикам при прохождении обучения программированию. Но умеем ли мы ими пользоваться? В этой статье я хочу показать все методы массива, а также некоторые фишки в работе с массивами.

24.01.2024    14709    YA_418728146    26    

71

Перенос данных 1C Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023    10459    dsdred    44    

129

Механизмы платформы 1С Программист Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

06.10.2023    22808    SeiOkami    46    

133

Механизмы платформы 1С Системный администратор Платформа 1С v8.3 Бесплатно (free)

Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.

14.09.2023    17564    human_new    27    

80

WEB-интеграция Универсальные функции Механизмы платформы 1С Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.

28.08.2023    13612    YA_418728146    7    

165
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Danil.Potapov 517 10.01.17 11:13 Сейчас в теме
А что говорит служба поддержки 1с?
2. zhichkin 1519 10.01.17 11:17 Сейчас в теме
(1) Вы про пресловутое лицензионное соглашение для 1С:Предприятие 8 ?
Ну, как всегда, автор не рекомендует повторять это дома, так как все трюки выполнены профессионалами =)
3. Danil.Potapov 517 10.01.17 11:19 Сейчас в теме
(2) да не, мне на это все равно. Служба поддержки 1с подтвердила такую ошибку в платформе?
4. zhichkin 1519 10.01.17 11:23 Сейчас в теме
(3) Это не ошибка платформы. Я встречался с такими нетиповыми конфигурациями, где допускается иметь движения документа с разными значениями периода ... Вот как бывает =) Кроме этого, статья имеет практический смысл при работе с табличными частями средствами SQL Server. Я об этом упоминаю в конце статьи.
5. Danil.Potapov 517 10.01.17 11:27 Сейчас в теме
(4) подожди, в статье идет речь про то, что платформа допускает запись в регистр накопления записи пронумерованные не по порядку и если их перечитать и записать, то добавляет еще одну запись. Пока нашел в списке ошибок платформы 8.3 только ошибку нумерации набора записей регистра бухгалтерии (https://bugboard.v8.1c.ru/error/000023566.html). На каком релизе платформы была эта ошибка?
6. zhichkin 1519 10.01.17 11:33 Сейчас в теме
(5) Ах, Вы об этом ... Ну, да, есть такая шляпа. Просто если не шаманить на SQL, то подобную штуку не воспроизвести. По этому я в службу поддержки 1С не обращался. Релиз платформы на тот момент времени (июль 2016 года) я использовал последний. Думаю это было что-то типа 8.3.5. Да и суть статьи опять же была не в этом. Ошибку я обнаружил, можно сказать, по ходу дела, тестируя результаты свёртки.
7. Danil.Potapov 517 10.01.17 11:35 Сейчас в теме
(6) понял, не надо так пугать, думал что уже платформа разучилась нормально нумеровать записи.
8. METAL 299 02.03.18 14:45 Сейчас в теме
Не совсем по теме, но всё же позволю себе поинтересоваться, может знаете:
_RecorderTRef - какое значение какому типу документа соответствует, можно ли узнать как-то программно в 1С либо запросом к какой-то таблице в SQL?
Спасибо!
9. zhichkin 1519 02.03.18 15:59 Сейчас в теме
(8) Программно средствами языка 1С это можно узнать следующим образом:
Отбор = Новый Массив();
Отбор.Добавить(Метаданные.Справочники.Номенклатура);
ТаблицаМетаданных = ПолучитьСтруктуруХраненияБазыДанных(Отбор, Истина);
Инфо = ТаблицаМетаданных.Найти("Основная", "Назначение");
ИмяТаблицыSQL = Инфо.ИмяТаблицыХранения;

Переменная ИмяТаблицыSQL будет содержать что-то вида _Reference41. Число в конце наименования таблицы, в данном случае это 41, будет именно тем, что Вам нужно - кодом типа 1С, которое сохраняется в полях вида _[ИмяПоляТаблицы]TRef.
10. zhichkin 1519 02.03.18 16:03 Сейчас в теме
(8) Имейте в виду, что если восстановить базу из dt-файла, то все коды типов 1С при загрузке генерирует заново!
11. zhichkin 1519 02.03.18 16:10 Сейчас в теме
(8) На всякий случай: 41 не равно 0х41 =) Используйте в SQL коде преобразование int в binary(4).
CAST(41 AS binary(4))
13. zhichkin 1519 25.12.18 18:01 Сейчас в теме
(12) Спасибо! Было дело копался в этом. Тоже хотел написать SQL CLR хранимку, но в итоге не хватило времени и желания копаться в формате 1С. Теперь может быть вернусь к этой теме =)
14. МихаилМ 26.12.18 15:38 Сейчас в теме
(13) dbnames быстрее парсить через xml
Оставьте свое сообщение