Проблемы обмена

Пользуемся конфигурацией Управление торговлей", редакция 10.2 (10.2.11.3), на платформе 1С:Предприятие 8.0 (8.0.16.2). Организовали распределёнку. Настроили автоматический обмен между главной и периферийной базой.
Постоянно возникают проблемы при обмене, часть изменений теряется куда-то. Такое чувство, что эти изменения очищаются в какой-то момент.. Помогает только перезапись объекта, при этом изменения вновь регистрируются и при обмене попадают куда надо.. В чём может быть косяк?

Скорее всего у Вас теряются изменения в периферийной базе после переноса в неё изменений конфигурации из главной базы. Это наблюдалось мной и на последней версии платформы 8.1.10.50. Разумеется, такого быть не должно и это ошибка платформы.

И кстати, опишите подробно: как именно у Вас производится обмен (интерактивно или с помощью написанной процедуры, дайте посмотреть код если он есть).

Данные теряются, к сожалению, не только при переносе изменений конфигурации. :(

Обмен настроен так: есть батничек, который запускает периодически 1с и передает ей параметр запуска. Процедура ПриНачалеРаботыСистемы() обрабатывает этот параметр:

Если ПараметрЗапуска<> "" тогда
        Попытка 
            ВыполнитьКомандыЗапуска(ПараметрЗапуска);
        Исключение
            Сообщить(ОписаниеОшибки());
        Конецпопытки;    
        ЗавершитьРаботуСистемы(Ложь);
    КонецЕсли;

Процедура ВыполнитьКомандыЗапуска(параметр) Экспорт
    ЭтотУзел = ПланыОбмена.Филиалы.ЭтотУзел().ПолучитьОбъект();
    Поток = Новый ЧтениеXML;
    Поток.УстановитьСтроку(Параметр);
    Поток.Прочитать();  // command шапка 
    КаталогОбмена =  ПрочитатьЗначение(Поток);
    Пока Поток.Прочитать() Цикл    
        Если Поток.ТипУзла=ТипУзлаXML.НачалоЭлемента И Поток.Имя="Node" Тогда
            Поток.Прочитать();
            УзелПриемникКод=Поток.Значение;
            Поток.Прочитать();// закрыли node
            УзелПриемник = ПланыОбмена.Филиалы.НайтиПоКоду(СОКРЛП(УзелПриемникКод));    
            Если НЕ УзелПриемник.Пустая() Тогда
                ЭтотУзел.ПрочитатьИзменения(КаталогОбмена,УзелПриемник); 
                ЭтотУзел.ЗаписатьИзменения(КаталогОбмена,УзелПриемник);
            КонецЕсли;    
        ИначеЕсли Поток.ТипУзла=ТипУзлаXML.КонецЭлемента И Поток.Имя="Nodes"  Тогда
            Прервать;                
        КонецЕсли;
    КонецЦикла;
    Поток.Прочитать();  // command закрыли
КонецПроцедуры    

Ну и процедуры модуля плана обмена, осуществляющие чтение и запись:

Процедура ЗаписатьИзменения(КаталогОбмена,УзелПриемник) Экспорт
    Попытка
        ПолноеИмя = ПолучитьИмяФайлаОбмена(ПланыОбмена.Филиалы.ЭтотУзел().Код,УзелПриемник.Код,КаталогОбмена); 
        ЗаписьXML = Новый ЗаписьXML;
        ЗаписьXML.ОткрытьФайл(ПолноеИмя);
        ЗаписьXML.ЗаписатьОбъявлениеXML();
        
        ЗаписьСообщения = ПланыОбмена.СоздатьЗаписьСообщения();
        ЗаписьСообщения.НачатьЗапись(ЗаписьXML,УзелПриемник);
        ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения,1000);
        ЗаписьСообщения.ЗакончитьЗапись();
        ЗаписьXML.Закрыть();
    Исключение
    КонецПопытки;
КонецПроцедуры    

Процедура ПрочитатьИзменения(КаталогОбмена,УзелПриемник) Экспорт
    Попытка
        ПолноеИмя = ПолучитьИмяФайлаОбмена(УзелПриемник.Код,ПланыОбмена.Филиалы.ЭтотУзел().Код,КаталогОбмена); 
        ЧтениеXML = Новый ЧтениеXML;
        ЧтениеXML.ОткрытьФайл(ПолноеИмя);
        ЧтениеСообщения = ПланыОбмена.СоздатьЧтениеСообщения();
        ЧтениеСообщения.НачатьЧтение(ЧтениеXML);
        ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения,1000);
        ЧтениеСообщения.ЗакончитьЧтение();
        ЧтениеXMl.Закрыть();
    Исключение
    Конецпопытки;
КонецПроцедуры    

Еще для полной ясности функция, которая получает имя файла обмена:

Функция ПолучитьИмяФайлаОбмена(КодУзелИсточник,КодУзелПриемник,КаталогОбмена) 
    Возврат КаталогОбмена+"Message_"+СокрЛП(КодУзелИсточник)+"_"+СокрЛП(КодУзелПриемник)+".xml";
КонецФункции

Обмен с филиалом происходит через общий сетевой ресурс.

Сообщение отредактировал lanka: 13 февраля 2008 - 13:43

Во-первых я бы в двух местах Вашего кода заменил параметр 1000 на 0 вот здесь:

...
ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения, 1000);
...

...
ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения, 1000);
...

Что такое 1000. Это сколько элементов обрабатывать за одну транзакцию. Если мы поставим 1000, тогда для первых 1000 элементов - одна транзакция, для вторых 1000 - другая и так далее. Если на каком-то из этих элементов возникает ошибка - неизвестно будет - какая транзакция успела завершится, а какая не успела - вот Вам и источник потери данных. Какие-то данные успели записаться, а какие-то не успели.

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

Был такой вариант. Поставила 1000 элеменов в одной транзакции, как советует большая умная книжка "Профессиональная разработка в системе 1с: Предприятие 8". Там говорится о преимуществах и недостатках выгрузки и загрузки в одну транзакцию и предлагается искать компромисс между параллельностью работы пользователей и согласованностью выгружаемых данных.
Просто обмен у нас происходит каждый час, а база и так подвисает из-за интенсивной работы пользователей.
У меня вопрос такой возникает: а если одна из нескольких транзакций завершилась неудачей, сообщение в итоге считается прочитанным?

В том то и дело, что ДА, считается прочитанным!

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

Ещё обратите внимание на требования к аппаратным ресурсам.

Давайте проанализируем: как и на чём у Вас установлена основная и подчинённая база? Какой вариант работы обеих (файловый или через СУБД)? Сколько пользователей одновременно работают с каждой?

Главная база работает в клиент-серверном варианте. Одновременно около 40 пользователей. Периферийная база в файловом варианте, около 5 пользователей.

Сообщение отредактировал lanka: 15 февраля 2008 - 06:32

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

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

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

Рано радовалась, так и теряются данные

Данные теряются из-за неправильного чтения изменений.
Это проблема работы пользователей.

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

Поэтому ставьте обмен как можно чаще...

К сожалению, если бы все решалось пользователями - было бы прекрасно, но ошибки обмена проявляются не только из-за работы пользователей. Данные теряются и когда все корректно.

BabySG (20.2.2008, 0:41) писал:

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

Была замечена следующая ситуация: в центральной базе номер отправленного сообщения оказался меньше номера принятого сообщения в филиальной базе. Как такое может быть? Еще бывает сообщение записывается не полностью, скорее всего из-за блокировок, т.е. оно выкладывается оборванным... Может ли случиться такая ситуация, что при выгрузке сообщение записалось не полностью, номер отправленного сообщения не изменился и это оборванное сообщение удалось прочитать в периферийной базе?

lanka,
оборванное сообщение читается, как ни странно (хотя стандарт XML предполагает закрытие всех тэгов)
Поэтому, например, может быть ситуация, когда места под сохранения файла не хватило (неполная выгрузка) - но файл появился (например, размером 1 мегабайт, когда должен быть 2 мегабайта) - но сообщение будет читаться за полное!

Спасибо за разъяснение! Как посоветуете быть? Как определить в момент выгрузки, что сообщение записалось не полностью? Или как это определить в момент загрузки?

Проверить можно просто запустив проверку закрытия тэгов.
В сети можно найти бесплатные парсеры для этого, ну, или написать самой.

Что-то порылась в инете - ничего не нашла... Неужели ни у кого нет такой проблемы..
Сама не знаю, как написать такую проверку :(

Ну, у меня была такая проблема :) Решил просто квотированием места на винте под это дело :)
А обработку сейчас некогда просто написать... Попробуйте погуглить на тему проверки тэгов. А еще лучше, - найти форум по XML и попросить дать анализатор....

У меня несколько другая проблема, но тем не менее так же связана с особенностью XML структурой файла обмена. Обмен с перефирийной базой шел всегда нормально (изменения конфигурации и данные передовались без ошибок). Но тут я получил вот такое сообщение: Ошибка при записи изменений при обмене: Ошибка при вызове метода контекста (ЗаписатьИзменения): Текст XML содержит недопустимые символ в позиции 672 и встал в тупик. Тестирование и исправление ничего не дали (ошибок нет). А как найти эту позицию в файле размером в сотни мегабайт - не представляю себе. Подскажите методику как найти и исправить подобную ошибку.

Видимо, в БД есть какой-то символ, не поддающийся выгрузке. Слышал про такую проблему, есть какой-то патч, который это устраняет.

Я свою проблему решил откатом обменов до полностью удачного. (была ошибка в записи даты).
Решение подобных проблем освещено на форуме:
www.itland.ru/forum//index.php?showtopic=12881

Есть распределенная база УТ 10.2 - 15 периферийных баз и одна центральная. В Центральной базе наблюдается неуникальность номеров с некоторых узлов - притом что документы с одинаковыми номерами разные(не задвоенные). В чем дело?
По моим подсчетам только в 4 узлах неизвестно какие префиксы стоят... Даже если бы в этих четырех узлах стояли бы одинаковые префиксы то все равно небыло бы такой ситуации(доходит до 4х доков с одинаковым номером). а так доки с один номерами встречаются с разными префиксами.

Есть распределенная база УТ 10.2 - 15 периферийных баз и одна центральная. В Центральной базе наблюдается неуникальность номеров с некоторых узлов - притом что документы с одинаковыми номерами разные(не задвоенные). В чем дело?
По моим подсчетам только в 4 узлах неизвестно какие префиксы стоят... Даже если бы в этих четырех узлах стояли бы одинаковые префиксы то все равно небыло бы такой ситуации(доходит до 4х доков с одинаковым номером). а так доки с один номерами встречаются с разными префиксами.

1С:Предприятие 8.1 (8.1.9.54)
"Управление торговлей", редакция 10.3 (10.3.1.17)
Организована распределенная база - 1 периферийная и 1 центральная, все обменивается
Было у кого нить такое что документ изменили, а после обмена в журнале не меняется, заходишь в него там все изменено. Тоже самое проведене, удаление... в журнале не видно....

1cv8.1 УПП для Украины 1.1

настраиваю РБД с ограничением выгрузки контрагентов в филиалы по основному менеджеру
выгрузка сработала, а при загрузке в базу филлиала выдает ошибку
Вид договора "С покупателем" может устанавливаться только когда у контрагента указано что он является покупателем.

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

подскажите, пожалуйста, в чем может быть проблема?

Update:
выяснил в чем проблема, выборку делаю по основному менеджеру, при этом из справочника Договора контрагентов все грузится без ограничений.
Поэтому при загрузке данных в филиал база получает договор без контрагента.
Подскажите как можно организовать выборку договоров с контролем отправки связанного с ним контрагента

Сообщение отредактировал Diversant: 31 августа 2009 - 16:37

Есть такая проблема. При выгрузки большого объема данных по правилам через УниверсальныйОбменДанными бывает такое, что какие-то данные теряются, т.е. они попросту не выгружаются в файл. Причем это происходи постоянно на одном и том же месте.
Например может не выгрузиться вид операции документа, или номенклатура из табличной части. А если попробовать выгрузить этот кривой документ отдельно, то все нормально. Не знаете в чем может быть проблема?

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

Подробнее о проблеме и ее решении написано в теме
http://www.forum.mis...c.php?id=469959

здравствуйте! мое имя Александр подскажите пожалуйста как настроить обмен данными между УНФ 1.2 и БП 2.0.16