|
После успешного обмена данные из очереди обмена не пропадают, хотя должны | ☑ | ||
---|---|---|---|---|
0
Dwarrior
23.12.13
✎
07:54
|
Здравствуйте! Есть база 1С Бухгалтерия 8.1, у нее несколько узлов РИБ. Проблема такая - изменяю элемент справочника, он попадает в очередь обмена ко всем узлам РИБ. Делаю обмен с одним узлом. Обмен успешный, без ошибок. Но при повторной выгрузке файла обмена для этого узла там снова выгружается этот элемент справочника!
База данных Postgre SQL. С помощью технологического журнала докопался вот до чего - в таблице регистрации изменений для этого справочника не заполняется поле MessageNo, тогда как в похожей базе рядом, на этом же сервере, заполняется. Текст запроса "Update <table> Set MessageNo = 115" их технологического журнала отловил, выполнил отдельно - выполняется. А из 1С не выполняется, или может не коммитится. Подскажите пожалуйста, куда копать? |
|||
1
ALFkz
23.12.13
✎
08:26
|
А обратный обмен сделался от узла к Центру?
|
|||
2
Dwarrior
23.12.13
✎
08:38
|
(1) Да, все данные легли нормально.
|
|||
3
Dwarrior
23.12.13
✎
09:41
|
Причем, как я писал, есть идентичная база по конфигурации на этом же сервере. Просто она старая, данных меньше. Там поле MessageNo при выгрузке файла обмена заполняется нормально. Конфиги одинаковые, на одном сервере рядом лежат...непонятно
|
|||
4
Maxus43
23.12.13
✎
09:55
|
в 1с запросом к таблице изменений после выгрузки - реально нет номера сообщения у элемента?
|
|||
5
PLUT
23.12.13
✎
09:57
|
(0) удали всю регистрацию для этого объекта (можно программно, можно интерактивно)
поставь заново этот объект на обмен |
|||
6
Serg_1960
23.12.13
✎
10:09
|
(0) Имхо, исходить из того, что база сбойная и скорее всего - в служебных данных. Переиндексация в SQL, ТиИ, создание новой базы и выгрузка/загрузка данных...
|
|||
7
Dwarrior
23.12.13
✎
10:24
|
(4) Реально нет. Поле MessageNo есть NULL
(5) Пробовал удалить только по этому справочнику - не помогло. Новые изменения регистрируются, но поле MessageNo не заполняется (6) Кстати да, запускал недавно ТиИ на этой базе, до конца не дошло, база большая, прервал. Может из-за этого? Хотя вчера вот пробовал выгрузить в *.dt и загрузил обратно - не помогло |
|||
8
Maxus43
23.12.13
✎
10:29
|
обработкой сделай
ПланыОбменаМенеджер (ExchangePlansManager) ВыбратьИзменения (SelectChanges) Синтаксис: ВыбратьИзменения(<Узел>, <НомерСообщения>, <ФильтрВыборки>) укажи узел и номер сообщения. потом запросом к таблицам изменений погляди номера |
|||
9
PLUT
23.12.13
✎
10:42
|
(7) кури профразработку (книжка такая толстая), там написано, что если НомерСообщения Null, то еще не выгружался. при выгрузке номер сообщения туда запишется
|
|||
10
PLUT
23.12.13
✎
10:43
|
+(9) для вновь зарегенных по плану обмена в таблице изменений в этом поле Null
|
|||
11
Maxus43
23.12.13
✎
10:46
|
(9) он утверждает что номера нет После выгрузки
|
|||
12
Dwarrior
23.12.13
✎
12:12
|
(9),(10),(11) - Да, все верно. Сразу после регистрации изменений поле NULL, после выгрузки должно заполняться номером очереди сообщений. А не заполняется...
|
|||
13
Dwarrior
23.12.13
✎
12:18
|
(8) Выполнил. MessageNo заполнился! интересно почему. Но вот загвоздка в том, что у меня узлы РИБ и изменения для них выгружаются одним методом "ПланыОбменаМенеджер.ЗаписатьИзменения()", разобрать который я не вижу как...
|
|||
14
PLUT
23.12.13
✎
12:18
|
(12) попробуй программно удалить из этого плана обмена регистрацию этого "косячного" объекта
и опять поставь на обмен |
|||
15
Dwarrior
23.12.13
✎
13:12
|
(14) - если бы этот косячный объект был один...Все изменения в базе такие косячные.
|
|||
16
PLUT
23.12.13
✎
16:03
|
(15) обмены они такие)))
накосячил кто-то в консоли запросов выполни что-то типа: ВЫБРАТЬ РАЗЛИЧНЫЕ РегистрацияИзменений.НомерСообщения ИЗ РегистрСведений.Штрихкоды.Изменения КАК РегистрацияИзменений ГДЕ РегистрацияИзменений.Узел = &Узел посмотри номера сообщений)) грохни программно все сообщения с самого большого номера)) ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена,НомерСообщения); p.s. метод УдалитьРегистрациюИзменений удаляет из всех таблиц регистрации изменений все записи относящиеся к указанному узлу, у которых номер сообщения меньше или равен значению второго параметра. |
|||
17
Dwarrior
26.12.13
✎
09:18
|
Проблема решилась!
Правда сама по себе, после перезагрузки сервера. Виноват видимо был Postgre, "оптимизированный" мной через файл postgresql.conf под мой размер ОЗУ. ОЗУ была почти вся забита Postgre, даже виндовые приложения не запускались. Хотя другие операции в 1С выполнялись нормально...Тут бы ругнуть разработчиков Postgre, но она: 1) бесплатна, поэтому никто ничего мне не должен и 2)отчасти сам виноват, залез в настройки. Так что посыпаю голову пеплом себе:) В-общем, спасибо всем вам за помощь! Проблему, как зачастую бывает, создал себе сам:) |
|||
18
Serg_1960
26.12.13
✎
09:57
|
(17) Только не говори версию никому - пусть они тоже нарвутся на проблемы.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |