Блокировка таблицы изменений. Как? #684971

Приветствую! Что-то никак мне не решить задачку: Есть план обмена в котором регаются изменения по регистру сведений. Периодически, запросом по таблице изменений выгружаю данные насторону. Пока выгружаю, новая партия данных поступает в рег и к выполнению команды ПланыОбмена.УдалитьРегистрациюИзменений(Узел) - удаляются и те изменения, что я выгрузил и те, что во время выгрузки появились новые. У меня SQL, блокировки по записям. Делал: - бесполезняк, данные добавляются, таблица изменений наполняется Делал 2: НачатьТранзакцию; Запрос... Выбрать МАКСИМУМ(ЗначенияНаВыгрузкуИзменения.НомерСообщения) ДЛЯ ИЗМЕНЕНИЯ - но толку тоже никакого - данные _добавляются_ - таблица изменений наполняется Как же заблочить всю таблицу Изменений или весь РегистрСведений, шоб аж добавить ничего нельзя было до конца транзакции?

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

Что в вашем понимании "классически"?

ВыбратьИзменения и т.д., проставляется номер сообщения, удаление регистрации происходит по номеру сообщения а не всё что там есть, короче стандартно

Номер сообщения всегда 0. Удаляя по номеру сообщения 0 - удаляются также все записи. И те что добавились за время выгрузки - тоже. А как заставить план обмена генерить номера сообщений не НОЛЬ - не ясно, кстати, ещё актуальный вопрос.

узел то не один хоть?

будет XML со всеми данными зарегистрированными и с проставленными номерами

Икс... Узелов два... две... двое)) Но причём здесь хмл? Без него (не создав его) нельзя корректно пользоваться планом? С какой стороны курить-то это?

ну курить надо хотя бы проф разработку, главу по планам обмена, раз вобще не в зуб ногой)

Ну, это не ответ)) А по сути вопроса? План обмена есть, изменения заполняются. А выбрать изменения на текущий момент, так чтоб их отрегить от плана - никак что ли?

1) ПланыОбмена.ВыбратьИзменения с нумерацией сообщений или 2) Фоновый (2й) узел обмена - начало обмена -> запросом выбрать изменения из 1го, перенести во 2й, удалить из 1го -> обменяться со 2м узлом (с удалением регистрации при успешном обмене оттуда)

при этом удалять регистрацию пообъектно можно

выкинуть ПланыОбмена.УдалитьРегистрациюИзменений(Узел) удалять регистрацию по каждому объекту.

1) - изменения выбираются, и пока я этот список отправляю, в таблице изменений появляются ещё изменения, которые тоже с номером НОЛЬ! Под конец, удаление по номеру НОЛЬ - очищает _всю_ таблицу изменений. 2) Здесь не понял, чем это отличается от 1 - пока перегружаю, так там всего понадобавляется... Пообъектно регистрацию не удалить, т.к. пока я выгружаю один этот объект и перехожу к строке - удалить из изменений этот объект = пользователь снова может записать изменение этого объекта! И, получается, выгрузил я старую запись, а регистрацию удалил и по обновлённому. Вот где собака порылась!

ну это уже вероятность 0,0005%. Наэто можно спокойно забить.

Для этого и сделан механизм НУМЕРАЦИИ сообщений, чтоб были согласованные данные, я не понимаю о чем тут речь господа, всё написано давно и давно реализовано во всех типовых и так далее

Данная вероятность в день отрабатывает на 30%. Забить != правильно. А надобно именно правильно и максимально прозрачно. Что с этим механизмом? Изменения регистрируются платформой, а увеличить с определённого момента номер сообщения-то как платформу заставить? Отсюда и речи, что ответа нет, а вопрос есть! И в типовых механизмах ежедневно приходится по одному-двум объектам повторно регать изменения - вот и думаю, не косяк ли там тот же закрался(?)

>>И в типовых механизмах ежедневно приходится по одному-двум объектам повторно регать изменения что за ересь то? >>Изменения регистрируются платформой, а увеличить с определённого момента номер сообщения-то как платформу заставить? Синтаксис: Описание: Формирует выборку измененные данные для передачи их в тот или иной узел плана обмена. При этом в процессе выборки изменений в записи регистрации изменений проставляется номер сообщения обмена данными, в котором должны передаваться изменения. Номер сообщения в записи регистрации проставляется для того, чтобы при подтверждении приема сообщения, в котором передавались изменения соответствующие записи регистрации изменений были удалены и в дальнейшем изменения больше не передавались.

+ номер проставится только у тех, которые на данный момент будут в Выборке. Если в процессе кто-то запишет тот же элемент - номер сообщения у него сбросится, и при удалениии регистрации при получении ответа - он не удалится, и будет послан с обменом ещё раз. Так же если заключить всё в транзакцию - скорей всего юзер и не сможет записать элемент во время выполнения выгрузки

Тише, Mаксус, тише! Я про-ве-ря-ю... ))

+100 Работает! Странно, но работает. Буду копать здесь. Спасибо!!

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

Не в этом смысле "Странно". Я пишу: Выб= ПланыОбмена.ВыбратьИзменения(Узел, 1); И у меня в таблицах все записи стали с номером 2... А: - нормально работает, номера НОЛЬ сменились на 2 и все двойки остались. В общем, прикол с 1 - не понял, ну да ладно))

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

вариант 2 - выбираешь изменения (например объекты #1-#5) - регистрируешь во 2й план обмена (объекты #1-#5) - удаляешь из 1го (объекты #1-#5) - делаешь что угодно со 2м после п1 (известен состав объектов к переносу в фон)  - в 1й план обмена может добавляться что угодно работает но за номерацией следить самостоятельно

Вот, кстати, да - теперь понятно применение второго варианта, Спасибо! Однако... ВыбратьИзменения(<Узел>, <НомерСообщения>, <ФильтрВыборки>) <ФильтрВыборки> - это как раз то, чем и можно размер порции ограничить. Отобрал всё из узла в сообщение №2, получил первые Н объектов пакета и отобрал их в сообщение №3, третье и отправил. И так до тех пор, пока объектов для обмена не будет меньше Н, что уйдут за один приём. Вроде, должно взлетать)

Проблема в удалении регистрации, удаляя регистрацию сообщения номер 3, удалиться регистрация всех младших сообщений.

Отпишитесь, пожалуйста, потом про правильный вариант.

Проверил на таблицах sql сервера как регистрируются данные при отправке. Вам подойдет следующий код. Взято из книги Гончарова. Ключевой момент - после записи выходного файла выполняется ПланыОбмена.УдалитьРегистрациюИзменений(ВыбУзел, НомерСообщения);  . Удалятся изменения только для тех элементов, которые содержали номера сообщений не превосходящие номер сообщения, сгенерированный во время метода ВыбратьИзменения, и не будут удалены те, которые за время выгрузки приобрели NULL в качестве номера сообщения (т . е. за время выгрузки были еще раз изменены). Процедура КнопкаВыполнитьНажатие(Кнопка)