Как отследить изменение порядка строк в табличной части? #328190

Задача такая. Во-первых, неплохо было бы при отслеживании изменения реквизитов табличной части понимать, что реально поменялся номер строки, а не все ее атрибуты. Во-вторых, есть задача. Заголовок>детализация первого уровня>детализация второго уровня. При этом в детализации первого уровня предметного ключа по сути нет: только номер(ну скажем номер этапа мероприятия) и наименование. Номер уникален, а наименование пофигу. Предполагал сделать две табличные части: в одной хранить детализацию первого уровня, во второй - второго. Связку второй ТЧ сделать с первой по номеру строки в первой ТЧ. При перемещении строки в первой ТЧ у нее меняется номер и соответственно этот номер также должен поменяться во второй ТЧ. Отсюда собственно и  сабж. Конечно понимаю, что можно реализовать подчиненными документами, но не хотелось бы городить.

в стандартных это делается через спец. поле ИДСтроки, которое заполняется в момент добавления новой строки

Тебя интересует изменения данных в ТЧ (без учета порядка строк) или вообще все изменения ТЧ (в т.ч. и порядок следования строк). Для чего это надо? Озвуч всю задачу.

Пожалуйста, дай ссылочку в каком документе так делается. Поискал в БП по "ИДСтроки" - ничего не нашел. Интересует именно как отследить, что строку переместили. Желание такое вытекает из двух задач: а) хранить историю изменений,в том числе и табличной части. при этом хочется различать ситуации кода меняли реквизиты у строки, и когда перемещали строку. б)необходимо связать две ТЧ в одном документе по принципу 1:N. Хочу сделать это по  номеру строки, но для этого надо отслеживать момент когда у строки меняется номер - пока не нашел для этого подходящего события.

интересный вопрос...

подниму веточку...

никому сабж не интересен?

на ИТСе было что то про это... Надо посмотреть, я такую штуку реалзизовывал  уже два раза. Но можно поинтересоваться, зачем хранить историю перемещения строк???

история меня лично не волнует. Но факт изменения порядка строк в момент записи документа хотелось бы отслеживать. Само по себе это просто. Интересует - как это сделать максимально быстро, чтоб не было тормозов даже при большой табличной части документа...

+8 просто думаю в будущем сделать регситрацию всех изменений, вводимых задним числом. Как делать - в принципе ясно. Но есть сомнения в скорости работы этой фигни с ТЧ...

Сижу тоже думаю над подобной проблемой. Никак не могу отловить перед записью объекта, какая строка была добавлена или удалена.

сравнение ссылки с объектом не помогает?

не поможет

Не помогает. Нет однозначной идентификации строки.

Уточни ЗАЧЕМ отслеживать изменение порядка строк???

ну например чтобы регистрировать существенные изменения в документе. Т.е. простое изменение порядка строк можно вовсе изменением не считать.

в самую точку центра Да сама история перемещения записи нам допустим инее нужна.. Тут очень важная деталь в том, что в ТЧ нет КЛЮЧА, кроме номера строки. Понятно, что ПередЗаписью можно сравнить данные в объекте и в БД, но как сравнивать строки ТЧ, какую с какой? Допустим было 10 строк и перенесли первую в конец. Что тогда вы запишите в историю? - что поменялось множество реквизитов во всех строках ТЧ, а хотелось бы чтобы в истории в таком случае осталось бы только, что в строке 1 номер поменялся на 10, в строке 2 на 1, в строке 3 на 2, в строке 10 на 9 и все. Или вообще не отражать эти изменения, но никак не первый вариант, который покажет что перепахали всю табличную часть. Опять же понятно что можно сэмулировать Ключ в ТЧ, добавив туда реквизит и заполняя его на создание строки GUIDом. Как я понимаю именно это предлагает Валерыч в , но типовых я этого не нашел (кстати, если кто занает где такой подход применяется в типовой, укажите документик пожалуйста). А самому идея не очень понравилась, потому и хотелось бы убедиться, что в типовых так поступают. Нашел подобный подход в FAQ на итланде Может с GUIDом и  буду делать, так и не нашел как оперативно отловить изменение порядка строк. Да и вообще, наверное, это была плохая идея связывать две ТЧ по номеру строки в одной из них – даже если отловить перемещение то изменять строки пачками во второй ТЧ – при большом количестве строк перемещение подтормаживать начнет, а сортировка и тем паче. А вот для вычисления истории вполне рабочий вариант: 1)при открытии записываем ссылки на все строки ТЧ в массив 2)перед записью идем по порядку по строкам ТЧ из ссылки (из БД), находим соответствующую строки через массив (индекс в массиве и номе строки в ТЧ в БД – одно и тоже) и сравниваем реквизиты. Думаю, быстрее варианта не придумаешь, если только еще запоминать куда нибудь все отредактированные строки по ходу их обработки пользователем, чтобы перед записью не сравнивать все строки а только выборочно.

Можно конечно заюзать всякие события ПередНачаломРедактирования, ПриОкончанииРедактирования. Таким образом ничего анализировать при записи не нужно. Вся инфа об изменениях уже есть на момент записи. Единственное, неприятно то, что это работа с модулем формы (отлавливает только интерактивную работу с формой), а вот программные изменения (то, что обычно в модуле объекта отслеживают) уже не прокатят...

Возможно для тебя применим следующий выриант: есть первоначальное состояние ТЧ документа и есть измененное состояние ТЧ в одной из них измени знаки значений количественных и суммовых реквизитов на противоположные и "сложи" обе ТЧ. Результатом будут только измененные строки. Для выяснения спорных вопрос и "кто виноват" этого вполне достаточно.

Может я чего то не уловил,но почему нельзя просто добавить колонку "старое значение номера строки". Перед записью сравнивать с номером строки и не совпадающие есть измененные.

Интересный вариант. "сложи" в смысле сгруппировать? Т.е. результатом будет полный набор строк ТЧ, но нас интересуют те строки, где числовые значения ненулевые. Ты это имел в виду?

Да. Если ТЗ то "Свернуть", а если запросом то "Сгруппировать" и отсеч нулевые строки.

ну да, логично. На 8.1 с временными таблицами должно нормально взлететь по идее...

На 8.0 с группировкой в ТЗ и поиском ненулевых значений не уверен, что тормозить не будет...

Самый простой вариант: 1.ПередЗаписью документа запросом вытаскиваешь ТЧ и выгружаешь в ТЗ; 2.Построчно добавляешь в выгруженную ТЗ измененную ТЧ (с измененными знаками); 3.Сворачиваешь полученную ТЗ; 4.Построчно пробегаешь полученную ТЗ без учета нулевых строк; Если тебя интересуют только интерактивные действия пользователей, то и делай подобную проверку только при интерактивной записи документа, т.е. перед записью из формы документа.

если только интерактивные действия отслеживать, то как раз лучше делать это в обработчиках событий ТЧ. Там анализировать только данные одной строки нужно и вообще не нагружаем запись документа.

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

Категорически утверждаю, что такая задача возникает исключительно при бестолковом проектировании системы. Не должен алгоритм зависеть от порядка строк.

+1

тут где то ветка была про цифровую подпись... может проще отслеживать - если сломалась - пусть сами ищут...

Сейчас речь уже не идет о порядке строк, а о способах отлова сделанных изменений в ТЧ.

какой алгоритм не должен зависеть от порядка строк?

+1 согласен был у меня такой опыт - разруливал только ключевыми колонками в обоих ТЧ. Иначе все плохо было.

что было плохо?

и какими методами потом работаешь с этими ключевыми колонками? И насколько это быстро отрабатывает?

невозможно однозначно ассоциировать строки из первой ТЧ со строками второй ТЧ.

способ с ключевыми колонками конечно надежен. Но ИМХО тормоза будут...

тормозов нет левый join по ключу и бери что хочешь.

это на 8.1 для начала перейти нужно...