После успешного обмена данные из очереди обмена не пропадают, хотя должны #692694

Здравствуйте! Есть база 1С Бухгалтерия 8.1, у нее несколько узлов РИБ. Проблема такая - изменяю элемент справочника, он попадает в очередь обмена ко всем узлам РИБ. Делаю обмен с одним узлом. Обмен успешный, без ошибок. Но при повторной выгрузке файла обмена для этого узла там снова выгружается этот элемент справочника! База данных Postgre SQL. С помощью технологического журнала докопался вот до чего - в таблице регистрации изменений для этого справочника не заполняется поле MessageNo, тогда как в похожей базе рядом, на этом же сервере, заполняется. Текст запроса "Update <table> Set MessageNo = 115" их технологического журнала отловил, выполнил отдельно - выполняется. А из 1С не выполняется, или может не коммитится. Подскажите пожалуйста, куда копать?

А обратный обмен сделался от узла к Центру?

Да, все данные легли нормально.

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

в 1с запросом к таблице изменений после выгрузки - реально нет номера сообщения у элемента?

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

Имхо, исходить из того, что база сбойная и скорее всего - в служебных данных. Переиндексация в SQL, ТиИ, создание новой базы и выгрузка/загрузка данных...

Реально нет. Поле MessageNo есть NULL Пробовал удалить только по этому справочнику - не помогло. Новые изменения регистрируются, но поле MessageNo не заполняется Кстати да, запускал недавно ТиИ на этой базе, до конца не дошло, база большая, прервал. Может из-за этого? Хотя вчера вот пробовал выгрузить в *.dt и загрузил обратно - не помогло

Синтаксис: укажи узел и номер сообщения. потом запросом к таблицам изменений погляди номера

кури профразработку (книжка такая толстая), там написано, что если НомерСообщения Null, то еще не выгружался. при выгрузке номер сообщения туда запишется

+ для вновь зарегенных по плану обмена в таблице изменений в этом поле Null

он утверждает что номера нет После выгрузки

,, - Да, все верно. Сразу после регистрации изменений поле NULL, после выгрузки должно заполняться номером очереди сообщений. А не заполняется...

Выполнил. MessageNo заполнился! интересно почему. Но вот загвоздка в том, что у меня узлы РИБ и изменения для них выгружаются одним методом "ПланыОбменаМенеджер.ЗаписатьИзменения", разобрать который я не вижу как...

попробуй программно удалить из этого плана обмена регистрацию этого "косячного" объекта и опять поставь на обмен

- если бы этот косячный объект был один...Все изменения в базе такие косячные.

обмены они такие))) накосячил кто-то в консоли запросов выполни что-то типа: ВЫБРАТЬ РАЗЛИЧНЫЕ     РегистрацияИзменений.НомерСообщения ИЗ     РегистрСведений.Штрихкоды.Изменения КАК РегистрацияИзменений посмотри номера сообщений)) грохни программно все сообщения с самого большого номера)) ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена,НомерСообщения); p.s. метод УдалитьРегистрациюИзменений удаляет из всех таблиц регистрации изменений все записи относящиеся к указанному узлу, у которых номер сообщения меньше или равен значению второго параметра.

Проблема решилась! Правда сама по себе, после перезагрузки сервера. Виноват видимо был Postgre, "оптимизированный" мной через файл postgresql.conf под мой размер ОЗУ. ОЗУ была почти вся забита Postgre, даже виндовые приложения не запускались. Хотя другие операции в 1С выполнялись нормально...Тут бы ругнуть разработчиков Postgre, но она: 1) бесплатна, поэтому никто ничего мне не должен и 2)отчасти сам виноват, залез в настройки. Так что посыпаю голову пеплом себе:) В-общем, спасибо всем вам за помощь! Проблему, как зачастую бывает, создал себе сам:)

Только не говори версию никому - пусть они тоже нарвутся на проблемы.