v7: Нетипичное использование компоненты УРБД в системе 1С:Предприятие 7.7 #633740

Идея взята отсюда Задача: Требуется настроить обмен между базами типа "Снежинка". Стандартный УРБД неудобен, т.к. нет возможности отбора при выгрузке в периферию. Проблема: на многих точках установлена однопользовательская версия программы, т.е. запускается база всегда насколько я понимаю в монопольном режиме и не будет возможности читать/изменять нужные файлы. Как можно обойти это ?

Идея взята отсюда Задача: Требуется настроить обмен между базами типа "Снежинка". Стандартный УРБД неудобен, т.к. нет возможности отбора при выгрузке в периферию. Проблема: на многих точках установлена однопользовательская версия программы, т.е. запускается база всегда насколько я понимаю в монопольном режиме и не будет возможности читать/изменять нужные файлы. Как можно обойти это ?

Идея взята отсюда Задача: Требуется настроить обмен между базами типа "Снежинка". Стандартный УРБД неудобен, т.к. нет возможности отбора при выгрузке в периферию. Проблема: на многих точках установлена однопользовательская версия программы, т.е. запускается база всегда насколько я понимаю в монопольном режиме и не будет возможности читать/изменять нужные файлы. Как можно обойти это ?

Поправьте тему плз в 7.7

1. "нет возможности отбора при выгрузке в периферию." Это не так. 2. "Как можно обойти это ?" не пускать базу монопольно. Или закрывать на время обмена.

Хм. А разве однопользовательская может работать в качестве центра распределенки? (в т.ч. и по условиям лицензии)

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

MOD

1. Каким образом можно отоборать выгрузку в периферийную базу по значению склада в шапке ? (перед выгрузкой пройтись по фалу 1SUPDTS.DBF ? Но вдруг кто из пользователей что-то поменял (всех выгонять на время обмена не вариант) выгрузится документ во все базы. 2. Обработка обмена будет своя и написана на языке 1С, т.е. не запускать базу в которой нужно произвести обмен не получится. Можно запустить базу не в монопольном режиме в однопользовательской платформе ?

Нужно по сабжу. МОД не подходит по определенным причинам.

А разве УРИБ на однопользовательскую встанет?

Причины в студию

я про систему регистрации и говорю... выгонять _всех_ из однопользовательской версии? :-)

Нужно своими средствами и без денег.

на краденой УРБД? :-)

А за работу деньги заплатят или для души работаем? Просто МОД стоит копейки.

Читайте внимательно: однопользовательские на периферии. Хотелось бы оставить стандартную систему регистрации + МОД в модули пишет свой код, да и нагроможден уж больно. Неизвестно как будет работать с большими объемами. Вобщем не лежит душа к нему.

Да почему ж она краденая ??? В центре лицензия неограниченная, на периферийных купленные однопользовательские. По идее базы и будут в режиме периферийных УРБД работать, но файлы отвечающие за обмен редактироваться своими средствами.

У меня регистрация от УРБД а обмен от МОД и весь МОДовский код из модулей убран (кроме доп.функций в глобальнике), поскольку эта куча кода нужна лишь для регистрации. Можно вообще инсталлятором МОДа базу не обрабатывать - только добавить общий реквизит в доки и в каждый справочник :( + еще по мелочи. Большие объемы - это сколько?

"промежуточные центры" "снежинки" по идее тоже должны быть центральными. Ну и читать модифицированным фокспрошным драйвером можно, а вот писать - проблемы (с индексами)...

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

работало таким образом 50 магазинов:-)))эх были времена приходилось извращаться не то что сейчас))

Я значит неверно истолковал слово "Снежинка". Одна база в центре и штук 20 периферийных.

это - обычная типовая звезда. обработка нужна только в ЦБ.

Так и засада в больших файлах обменов, сидят на "свистках" мегафоновских. +Если объем большой то и загрузка в базу может идти целый день - без шуток.

перед выгрузкой пройтись по фалу 1SUPDTS.DBF ?

"большие" - это сколько? и, собственно, что "нетипичного" при звезде?

типа того. Хотя работать с файловыми на запись я б не рекомендовал.

ТекущаяИБКод ИБСозданияОбъекта ЦентральнаяИБКод PS файл выгрузки не судьба править ? и отсылать... ЗЫЫ фигня это все , все в пределах - работает если обмениваться по 1-2 мега за раз ... ЗЫЫы похоже с урбд да и с модом мало работали ...

а еще смущает как и сам автообмен в УРБД, работает только в разделенном (не монопольном!) режиме 1С:Предприятие 7.7 а однопользовательская запускается в монопольном, Кстати МОД работает отлично

Всё бред. УРБД на перефирийку не встанет и никаких изменений регистрировать не будет.

Можно добавить в справочник "Склады" код ИБ и удалять в UPDTS документы с "чужим" для этой ПБ складом. Это если однозначное соответствие ПБ - склад. Не знаю, как в ДБФ, а на скуле -в 2 счета.

уже определились, что имеем дело с обычной "звездой"

в периферийках создаются болванки нужных документов, в ЦБ заполняются, миграция "место создания - центр" и никаких плясок с бубном

Лучше в одном месте поплясать, чем в сотне по всей стране :)

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

После перепроведения в центре за последнюю неделю в перифериную базу может загружаться сутки. Нетипичтое использование УРБД, механизм обмена свой - регистрация УРБД. Смущает то, что пока будешь пробегаться по файлу, юзеры еще наколотят документов и все-таки не по адресу что-то попадет. Про правку файла выгрузки еще не думал, если ссылку подкинете по структуре был бы признателен. Не получается обмениваться всегда по малу. С МОДом не работал, установл и удалил лет 5 назад. Это как ?

Возможно при создании документа в центре изменять признак места создания на другую базу ?

Это в ПБ при старте создаются пустышки будущей датой и поддерживается запас? А в ЦБ запрещено вводить новые доки определенного вида - пользуйтесь пустышками?

Тогда проще не регистрировать доки. А при записи/проведении вставлять запись в UPDTS для нужной базы по соответствию Склад-ПБ.

+ ИМХО самый бескровный вариант - в какой

+ таблице хранится создания объекта ?

Либо так.

1) На ПБ делаешь перемещение - ПУСТЫШКУ. 2) Выгружаешь в ЦБ 3) Заполняешь документ перемещение в ЦБ 4) Выгружаешь в ПБ. Что тебе еще надобно, старче?

Уууу. Один фик ты сначала запишешь. И при этом уже будет зарегено для всех баз. Да еще и запись будет заблокирована - слишком много но. Править надо только в UPDTS - иначе намудохаешься.

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

Выглядит "через ж.", хочется чтоб прозрачно для пользователей все было.

Зато работает "как часы" и штатными методами.

Навскидку - своими средствами (в обработке 1С) сложно сформировать такой файл ?

оно и так прозрачно для пользователей

кому-как. в общем, легко, но геморно. Плюс только формированием файла дело не ограничивается...

Несомненный плюс. Может и правда ну нахрен всю эту свистопляску.

Можно и обработкой откорректировать, можно и ручками.

Не, не пойдет обмен через УРДБ. Нужно конвертировать одни документы в другие - например перемещение в центральной должно быть поступлением в розницу в периферийной.

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

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

зашибись распределенка... :-))) ты еще номенклатуру одну в другую конвертируй...

А накуа? Основной склад - оптовый

Жесть, ладно у меня все справочники общие.

А движения лишние зачем ? Списание с основного будет.

КД2 решит твою проблему. Только повозиться придется с ее освоением. )

Я и собираюсь ее использовать. Проблема встала в регистрации объектов для обмена. Либо УРБД (надежно), либо свое делать.

Я каждому даю только ту номенклатуру, что нужна им. И только тех контрагентов с которыми они будут работать, из числа заведенных в базу, остальных они сами заведут и пришлют мне.

УРБД понадежнее будет, там механизм регистрации изменений очень мощный. А с КД2 постоянно у меня проблемы. то она перезаписывает то что не нужно перезаписывать, то дозаписывает. )

Это разбивается на 2 этапа, в ЦБ пользователь делает перемещение, затем уже автоматически, опять же в ЦБ, на основании перемещения заполняется болванка поступления в розницу для конкретной ПБ, которая и уходит в ПБ, перемещение остается в ЦБ, нехер ей в ПБ делать, только с ссылками может быть засада

Выглядит так ? Звонок в колхоз Ивановкий из центра: "Марья Ивановна, заведи-ка перемещение, товар тебе хотим отправить !"

Тогда уж в периферии создается поступление в розницу, а в центре заполняется и создается перемещение между складами, которое остается в центре.

перемещение у тебя делается в ЦБ, если я правильно понял

ну тебе на месте виднее

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

Да.

это уже потом будешь делать, сначала с обменом разберись

Еще вариант забить на УРБД и использовать журнал регистрации. Напривер ВК Journal.dll

Точно, никаких проблем с монопольным запуском. Прикрутить КД2 и в путь.

Буду надеяться что мне повезет больше)

Если у тебя пришел товар для всех. одной накладной, а тебе его надо раздать каждому по чуть чуть.

У меня центральный склад на который приходит весь товар. С него идут продажи и перемещения на другие склады/магазины.

"выглядит так" - при начале работы системы проверяется количество пустышек, лежащих в каком-нибудь 2020 году 1 января, и если их меньше 20, скажем, то генерируется недостающее до 20 количество. ---- а вообще, почитай форум. эта тема мусолися года с 2004... вариант с пустышками для твоей базенки - оптимальный.

У творения Саши Орефкова SQLite есть замечательный побочный эфект - умение работать с файлами базы, когда она запущена в монопольном режиме. Так что можно реализовать любые извраты фильтрации и изменения принадлежности объекта к БД.

Файл 1Cv77Chs.dat и вовсе *** ***, {"Acknowledgements", {"****"}}, {"Constants"}, {"References"}, {"Accounts"}, {"Documents"},

а с записью и индексами там проблемы решены? читать-то несложно....

+1 ^)

Похоже то что надо по сабжу, спасибо.

Всем спасибо, предложили много вариантов.

В 7-ке УРБД это отдельная компонента с отдельным ключом, который стоит денег и не маленьких. У вас оно тоже куплено?

Только чтение, без записи в БД

Лови скрин лицензии Коли топик в который раз лень прочесть.

А ЦБ у тебя скуль или дбф?

ДБФ

Вобщем подумали, порешали и остановились на варианте создания пустышек в периферийных ИБ. Поскольку времени мало для внедрения и чувствуется что для других вариантов потребуется много времени на тестирование. Если бы еще подсказали как в центральной базе изменить признак в какой базе был создан документ. Чтобы пересоздать периферийные базы по новой (сейчас они практически клоны центральной).

Если бы еще подсказали как в центральной базе изменить признак в какой базе был создан документ. - признак этот 3 символа в ИД объекта, подменять их я бы не стал, может случится так что ПБ создаст объект с уже существующим ИД, последствия понятны?

Ясно, спасибо. Тут либо менять вместе с признаком ID, т.е. делать по порядку для каждой ИБ. Либо создавать клоны документов в периферийных и удалять предыдущие в центре.

Это еще все ссылки надо на этот ИД вовремя отследить и заменить. Короче - ну его.

Если есть желание, то любой документ, созданный в любой базе, можно перенести в любую базу - ручками. Одно НО изменения в документе не будут передаваться.

запросто. у меня так и есть, но пришлось помучиться..

короче - была тема по большой файл, открытие периода и ПБ. . ситуация была такая, центральный офис и куча точек-магазинчиков. изначально схема УРБД была сделана так что - каждый магазинчик = отдельная фирма - все фирмы (в т.ч. и ЦБ) - одно юрлицо. - приход на оптовый ЦБ фирма-склад; зашибись - перемещение с оптовый ЦБ фирма-склад на розничный ПБ фирма-склад; . соответсвенно в каждую ПБ уходили все перемещения для всех точек. в ПБ получалсиь висящие остатки по ЦБ фирма-склад. . в итоге рано или поздно нас тупил капец - периоды открывались все дольше (по нескольку часов уже), файло регистров расло безмерно. . в итоге схему пока оставили как есть, а на ПБ тупо запускаем обработку, которая удаляет все доки где нет пары ПБ фирма-склад, а там где такая есть пара - для этого документа удаляем движения регистров по чужим парам Фирма-склад. . в итоге все стало почти "шоколадно" - размеры регистров упали от около 2Гбразмеров до сотни мегабайт 9а то моет и меньше, навскидку не помнюЮ на ПБ не залезть посмотрть), период открывается секунд 5-7

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

Только если ЦБ на скуле

а) почему? б) да, ЦБ на скуле.

1. Потому что до сих пор нет нормальной возможности редактировать dbf файлы напрямую, без риска "поломать" индексы Для Скуля такой проблемы нет, ибо нет индексов. Там хоть триггер повесь на изменение таблички и оно само будет автоматом чиститься (пишу по рассказам, а не по опыту)