Распределенная ИБ

[Renat11111]

ТИС 7.7


У одного очень хорошего человека возникла следующая проблема:

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

 

[kaa]

"все информационные базы" а зачем в периферии реализации из центра? при таком обмене изменения в центральной базе приоритетные. И возможно (но не уверен) отсутствие документа в центре является признаком что документ был удален.

 

[Renat11111]

"все информационные базы" а зачем в периферии реализации из центра? при таком обмене изменения в центральной базе приоритетные. И возможно (но не уверен) отсутствие документа в центре является признаком что документ был удален.

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

 

[puh14]

Возможно IdDoc совпали - вот их и перетерло? Проверить можно посмотрев Date_Time_IdDoc документов в 1sjourn до и после загрузки. Если они совсем пропадают - тогда хз, реально трет. Если остаются - значит перетирает.

 

[janibeg]

проблема решена?
у самого такое иногда бывает.
есть другие рецепты?

 

[SeverBap]

надо тестирование и исправление бд, а так же пересмотреть план обмена! (все действительно увязано в иникальные индетификаторы скорее всего уникум занит уже ошибками)

 

[Renat11111]

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

Возможно IdDoc совпали - вот их и перетерло? Проверить можно посмотрев Date_Time_IdDoc документов в 1sjourn до и после загрузки. Если они совсем пропадают - тогда хз, реально трет. Если остаются - значит перетирает.

можно поподробнее как это сделать?

 

[puh14]

До синхронизации копируешь файлик 1sjourn.dbf если файловый вариант базы или таблицу _1sjourn если скуль. В этой таблице есть поле Date_Time_IdDoc - это дата+время+уникальный идентификатор документа (он же есть и в поле IdDoc той-же таблицы). После синхронизации повторяешь процесс. Получаются две таблицы, из которых тебе надо выбрать те, которые есть в одной, но отсутствуют в другой по значению поля iddoc (Date_Time_IdDoc нужно чтобы понять документы какого периода ты рассматриваешь). Дальше можно просматривать глазками, а можно написать запрос. У тебя SQL сервер имеется?

З.Ы. посмотри файлик 1cv7.dd - там описание полей БД, это чтоб не ошибится с синтаксисом.

 

[Renat11111]

Получаются две таблицы, из которых тебе надо выбрать те, которые есть в одной, но отсутствуют в другой по значению поля iddoc (Date_Time_IdDoc нужно чтобы понять документы какого периода ты рассматриваешь). Дальше можно просматривать глазками, а можно написать запрос. У тебя SQL сервер имеется?


вот тут вот небольшая проблема. не знаю где писать запрос к этим двум таблицам. на SQL СЕРВЕРЕ что ли? у них не стоит но могу поставить если надо.

 

[puh14]

В принципе необязательно - просто в querry analiser результат быстрее определить (иначе придется писать подруб к дбф, короче лень). смотри - копируешь оба таблицы в скуль через импорт -экспорт, с именами например, t1(до загрузки), t2 (после). Открывашь enterprise manager, идешь на нужную тебе базу, ветка tables, тыкаешь на t1 правой клавишей мыши и выбираешь querry потом к t2 пишешь запрос


select * from t1 where t1.iddoc in (
select t1.iddoc
from t1
where not exists (select t2.iddoc from t2))




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

 

[Renat11111]

В принципе необязательно - просто в querry analiser результат быстрее определить (иначе придется писать подруб к дбф, короче лень). смотри - копируешь оба таблицы в скуль через импорт -экспорт, с именами например, t1(до загрузки), t2 (после). Открывашь enterprise manager, идешь на нужную тебе базу, ветка tables, тыкаешь на t1 правой клавишей мыши и выбираешь querry потом к t2 пишешь запрос


select * from t1 where t1.iddoc in (
select t1.iddoc
from t1
where not exists (select t2.iddoc from t2))




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

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


P.S

СКАЖУ честно у меня бы терпения не хватило так упорно и долго отвечать, спасибо.

 

[vitfil]

отсутствие документа в центре является признаком что документ был удален.

брехняяяяяяяяяяяяяяяяя (с)
1С регистрирует изменения, а не отсутствие. Причем, для документов регистрируется на уровне iddoc, а для справочников на уровне id. Посему и возникает проблема, когда для справочника стоит "уникальность кодов" и один элемент создается и в центре и на периферии и могут получаться одинаковые коды.

Возможно IdDoc совпали

еще раз брехняяяяяяяяяяя... (с)
при создании распределенной базы в поле iddoc добавляется код базы. и длина поля удлиняется с 9 до 13 символов.
и для вновь созданных объектов после иддок всегда добавляется код базы.
Этим можно пользоваться, если навернулась периферийка, для восстановления оной.

 

[puh14]

при создании распределенной базы в поле iddoc добавляется код базы. и длина поля удлиняется с 9 до 13 символов.
и для вновь созданных объектов после иддок всегда добавляется код базы.
Этим можно пользоваться, если навернулась периферийка, для восстановления оной.

Так каким-же образом обмен через УРБД может прикончить документы?

 

[Gman]

Хотелось бы поднять вопрос у меня похожая ситуация (файловый вариант баз), только документы распроводятся, 1с не регистрирует факта коллизий, после многих попыток побороть непорядок пришел к выводу что проблема в самом механизме обменов, хоть и говорят что механизм надежный, опытным путем установили что проблемы возникают после аварийных завершений 1с, т.е. слетают индексы, но опять же почему 1с нормально проводит документ, т.е. правильно позиционируется на нем, а обмен не правильно; в самом файле обмена нет информации об этих документах, тем неменее документы расроводятся. Хотелось бы услышать ваше мнение.

 

[vitfil]

в самом файле обмена нет информации об этих документах, тем неменее документы расроводятся. Хотелось бы услышать ваше мнение.

Откуда такая уверенность? Хотя, если слетают индексы, вполне возможна ситуация, описанная вами.

 

[Gman]

Откуда такая уверенность? Хотя, если слетают индексы, вполне возможна ситуация, описанная вами.

Смотрел файл обмена 1Cv77Chs.dat, а также 1supdts.dbf, таких документов там небыло, что-то не додумался сверить в 1SDWNLDS.DBF идентификаторы пакетов могла ли их последовательность быть нарушена... И еще если индексы у dbf все-таки слетают, то скорее всего у 1supdts.dbf, что если перед каждым обменом индексировать файл, но тогда к каким полям добавлять индексы и какие идетификаторы им давать?

 

[vitfil]

Gman
Или перейти на сиквел, или решить проблему с аварийными завершениями работы 1С

 

[vbs]

Просто из любопытства :
найдется ли кто-нибудь, кто избежал проблем с распределенной базой, работая хотя бы 2-3 года

 

[vitfil]

vbs
Таки вы знаете этого человека!
Размер ЦБ порядка 20 гиг. Больше 40 периферийных баз (вроде как 47 - уже сбился со счета). Проблем коллизий не возникало. Были проблемы с падениями периферийных баз (не связанные с 1С), но решались оперативно с восстановлением практически всех данных.

 

[Gman]

В принципе УРИБ надежный механизм, функционала не хватает: интерактивно раздавать приоритет конкретным объектам и мигрировать лишь определенные объекты из ЦБ