Пользуемся конфигурацией Управление торговлей", редакция 10.2 (10.2.11.3), на платформе 1С:Предприятие 8.0 (8.0.16.2). Организовали распределёнку. Настроили автоматический обмен между главной и периферийной базой.
Постоянно возникают проблемы при обмене, часть изменений теряется куда-то. Такое чувство, что эти изменения очищаются в какой-то момент.. Помогает только перезапись объекта, при этом изменения вновь регистрируются и при обмене попадают куда надо.. В чём может быть косяк?
AlexanderAA
13.2.2008, 11:12
Скорее всего у Вас теряются изменения в периферийной базе после переноса в неё изменений конфигурации из главной базы. Это наблюдалось мной и на последней версии платформы 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";
КонецФункции
Обмен с филиалом происходит через общий сетевой ресурс.
AlexanderAA
13.2.2008, 16:18
Во-первых я бы в двух местах Вашего кода заменил параметр 1000 на 0 вот здесь:
...
ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения, 1000);
...
...
ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения, 1000);
...
Что такое 1000. Это сколько элементов обрабатывать за одну транзакцию. Если мы поставим 1000, тогда для первых 1000 элементов - одна транзакция, для вторых 1000 - другая и так далее. Если на каком-то из этих элементов возникает ошибка - неизвестно будет - какая транзакция успела завершится, а какая не успела - вот Вам и источник потери данных. Какие-то данные успели записаться, а какие-то не успели.
Если мы поставим 0 - тогда абсолютно все элементы будут обрабатываться в рамках только одной транзакции. Если произойдёт ошибка - произойдёт откат всей этой транзакции, как будто ничего не происходило. Таким образом, мы сохраним целостность данных.
Был такой вариант. Поставила 1000 элеменов в одной транзакции, как советует большая умная книжка "Профессиональная разработка в системе 1с: Предприятие 8". Там говорится о преимуществах и недостатках выгрузки и загрузки в одну транзакцию и предлагается искать компромисс между параллельностью работы пользователей и согласованностью выгружаемых данных.
Просто обмен у нас происходит каждый час, а база и так подвисает из-за интенсивной работы пользователей.
У меня вопрос такой возникает: а если одна из нескольких транзакций завершилась неудачей, сообщение в итоге считается прочитанным?
AlexanderAA
14.2.2008, 10:31
В том то и дело, что ДА, считается прочитанным!
Я бы слепо не верил рекомендациям, а протестировал бы на деле с параметром 0. Может не всё так будет и страшно, зато сохранится целостность, что важнее. Ведь сейчас у Вас проблемы с целостностью, что гораздо хуже, чем возможные проблемы с параллельностью, которые ещё нужно выявить, чтобы понять насколько это неприемлемо, по сравнению с потерей данных.
Ещё обратите внимание на требования к аппаратным ресурсам.
Давайте проанализируем: как и на чём у Вас установлена основная и подчинённая база? Какой вариант работы обеих (файловый или через СУБД)? Сколько пользователей одновременно работают с каждой?
Главная база работает в клиент-серверном варианте. Одновременно около 40 пользователей. Периферийная база в файловом варианте, около 5 пользователей.
AlexanderAA
14.2.2008, 16:31
Нужна более подробная информация: конфигурация сервера, используемая база данных и т.п.
Я бы еще спросил какое количество документов идет за этот час между обменами и вообще - что происходит с базой? Изменяются ли документы за пред период, имеется ли возможность фильтровать данные или нужны полные данные, пробовали ли уменьшить период обмена до 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х доков с одинаковым номером). а так доки с один номерами встречаются с разными префиксами.
Golovorez
8.11.2008, 16:16
1С:Предприятие 8.1 (8.1.9.54)
"Управление торговлей", редакция 10.3 (10.3.1.17)
Организована распределенная база - 1 периферийная и 1 центральная, все обменивается
Было у кого нить такое что документ изменили, а после обмена в журнале не меняется, заходишь в него там все изменено. Тоже самое проведене, удаление... в журнале не видно....
Diversant
28.8.2009, 16:10
1cv8.1 УПП для Украины 1.1
настраиваю РБД с ограничением выгрузки контрагентов в филиалы по основному менеджеру
выгрузка сработала, а при загрузке в базу филлиала выдает ошибку
Вид договора "С покупателем" может устанавливаться только когда у контрагента указано что он является покупателем.
пробовал и нового создавать и копировать существующего...
возникло подозрение что реквизиты не в том порядке загружаются: сначала реквизиты договора, потом реквизит "покупатель".
подскажите, пожалуйста, в чем может быть проблема?
Update:
выяснил в чем проблема, выборку делаю по основному менеджеру, при этом из справочника Договора контрагентов все грузится без ограничений.
Поэтому при загрузке данных в филиал база получает договор без контрагента.
Подскажите как можно организовать выборку договоров с контролем отправки связанного с ним контрагента
La_Goosh
14.10.2009, 15:42
Есть такая проблема. При выгрузки большого объема данных по правилам через УниверсальныйОбменДанными бывает такое, что какие-то данные теряются, т.е. они попросту не выгружаются в файл. Причем это происходи постоянно на одном и том же месте.
Например может не выгрузиться вид операции документа, или номенклатура из табличной части. А если попробовать выгрузить этот кривой документ отдельно, то все нормально. Не знаете в чем может быть проблема?
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста,
нажмите сюда.