Подскажите, пожалуйста, возможно ли отловить событие при удалении элемента из табличной части документа? То есть, когда в форме документа в табличной части произошло удаление - то выполнить заданный код.

смотри события табличного поля, там есть ПередУдалением и ПослеУдаления

(1) Спасибо, с событиями разобрался. Но осталась еще одна непонятка. Если удаляется какая-то строка из табличной части документам мне надо удалить соответствующую строку в справочнике. Это удаление из справочника лучше делать в событии ПередУдалением или ПослеУдаления?

Если использовать ПередУдалением, то не может ли встретиться отказ удаления строки табличной части и в итоге - запись справочника удалится, а строка табличной части останется.

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

Хреновая идея со связкой элементов справочника со строками документа, очень хреновая...

(3) Хорошо. А тогда какой другой вариант для следующей задачи. Нужно хранить географию подключения - фактически справочник с двумя реквизитами - "Улица" и "Дом". Добавление, удаление и изменение этих записей надо как-то регистрировать. Отсюда и пошли идея - иметь справочник, в котором запрещено добавление, редактирование и удаление через форму. И есть документ, через который все эти действия производятся.

Регистр сведений посмотри

(4) я бы сделал регистр сведений, который двигается документом. Движения при каждом проведении перезаписываются. Вот и будет тебе география подключений. Удалил строку в документе, перепровел - запись в регистре исчезла

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

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

Скажите, этот шаблон про использование РС - полный бред?

Выражение "нужно хранить географию подключений" предполагает, видимо, не просто хранение, но и регулярную работу с этой информацией. Не по табличной части документа же тебе запрос строить? Документ в связке с РС, в частности, помогают разделить функцию ввода данных и записи их в базу. + в РС все индексируется по понятным правилам

(9) Спасибо, учту:) PS но запрос и не строился бы по табличной части дока, он бы строился по данным справочника.

(10) я про тот вариант, когда без РС и без справочника, имеем только док. Со справочником тоже можно, но в этом нет необходимости + гемморой с удалением элементов

Тогда еще вопрос в тему регистров. Если я сделаю в качестве двух ресурсов - улицу (строка) и дом (число), но не укажу измрение - это имеет какой-либо негативный эффект?

Просто если указать в качестве измерения улицу, то, насколько я понимаю, не получится добавить два дома на одной и той же улице - так как будут две записи с одним значением измерения.

PS Учитывая еще то, что РС будет непереодическим.

Можно сделать измерением и улицу, и дом, никому от этого плохо не станет.

А фактически тогда в чем разница - делать их измерениями, или делать их ресурсами. В любом случае я ведь ничего не выигрываю и не теряю...

Ну как, если движения в РС у нас делаются регистратором, то если в разных документах попадутся одинаковые адреса, то РС либо не позволит их записать - если и дом, и улица - измерения, либо позволит - если это ресурсы

(8) Не полный.

Но на заметку: хочешь сделать связь? Тогда ПередЗаписью документа у тебя в ТЧ своя таблица, а на диске -- другая. Сравнивай их, выделяй разницу -- удаляй элементы справочника (а вот тут я бы справочник на РС заменил)

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

Читаю (13), потом (15) - не пойму все-таки как лучше сделать. Но все-таки наверное, лучше ресурсами.

(2) клюшечная психология - все на справочниках.
(7) тебе уже клюшки напрямую по лбу бьют, а ты все свое )

(14) измерения уникальны, ресурсы - нет.

(15) если движения в РС делаются регистратором, то если в разных документах попадутся одинаковые адреса, то РС ПОЗВОЛИТ их записать - если и дом, и улица - измерения
регистратор то разный

редактируй напрямую справочник, а не тч

Всем спасибо, думаю, что разобрался в вопросе:)

(18) иногда справочники обоснованы - когда надо много хранить - выгоднее в итоге

(23) А можно поподробнее. Приведите, пожалуйста, пример такого случая, когда действительно выгодно использовать справочник.

PS В моем случае число записей будет порядка 10к - это считается много?

(24) несколько миллионов записей под историю изменений объектов

10к = это немного

(25) вот опять же у меня всплывает в голове шаблон - "история изменений = регистр". но как я понимаю - тут дело именно в производительности. лучше реализовать функционал истории изменений на справочнике.

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

Где я ошибаюсь?

(27) как я уже сказал в справочнике хранение более компактно
не тратится место на индексы