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

Как можно обойти это ?

+(197) И тишина, типичное бла-бла, с битьем копытом в грудь.

(200)

(195) А чего ты хочешь НОВОГО от 7.7+УРБД? Свое решение для условия (156) озвучишь?
Моему решению (192) уже более 7 лет и оно работает даже без программистов и интернета!

(201) в (192) нет ничего чтобы позволило оценить "решение"

(202) Вы считаете, что мне необходима ваша оценка моего решения? :-)

(203) ахах, ну конечно нет, вы ведь здесь просто пальцы раскинули, что здесь оценивать?

(203) а это никакое не "решение" - просто установленная и настроенная распределенка. И не более того.
Так, уровня начинающего внедренца, или младшего сотрудника-стажера франча...

(201) "нового" может быть много. ИНструмент УРБД достаточно гибкий, если уметь им пользоваться.

(206) Инструмент гибкий в пределах своих ограничений и достаточно старый, чтобы пытаться открыть в нем для меня что-то новое.
(204) (205) Ну, как? ЧСВ выросло после таких оценок? :-)

(207) кроме вас тут никто свое ЧСВ не пытается поднять, выдыхайте

(207) Ограничений при грамотном использовании умелыми руками  - мало.

Господа, чтобы прекратить все кривотолки - замечу: Д'Артаньян здесь один я...

(210) нетипичное лечение головной боли http://youtu.be/s73GjbSw5xY или как руководитель предприятия наказывает программиста за нетипичное использование компоненты УРБД :-)

(211) это из собственного опыта управления проектами? не пойду я к вам! ;-) рекомендую данный ролик пустит бэкграундом на выступлении ИнофтартЭвент... ;-)

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

(213) а почему бы и нет? если клиент не способен найти других исполнителей - то такая цена вполне себе обоснована...

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

(214) так я разве в укор, молоток наоборот, жизнь по принципу "без лоха и жизнь плоха" вполне себе имеет право на сущетсвование

№все крупные сотсояния нажиты нечестным путем.."...?

А что бы сказал народ если бы можно было создавать документ с заданным внутренним ID? Например в централке можно было бы создать документ перемещения в магазин с внутренним идентификатором соответствующим этому магазину. И УРБД молчаливо уносит его в эту периферийку..

(218) индексы?

(219) внешняя компонента

(218) Это пожалуй решило бы часть проблем.

(220) я не против, но как при этом поддерживать целостность базы на уровне индексов? и надо ли это делать с индексами?

(221) при этом надо взвести "флажок" изменения этого перемещения для УРБД - иначе не унесет..?

(223) Флажок сам взведется при создании документа. Другое дело в какой момент ему удастся подсунуть "правильный" идентификатор, а то флажок останется на уровне одной базы - центра.

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

(225) проблем не будет если провести некую подготовку при создании новой базы. Для новой, пустой базы принудительно создается документ с ID равным, ну например 1000000. Все последующие документы в базе автоматом пойдут инкрементом от этого ID. Таким образом у нас есть некоторое количество зарезервированных ID которые гарантированно не будут созданы штатными механизмами 1с-ки. Остается завести счетчик (константу например) и создавать документы по нему, добавляя к ID нужный суффикс периферийки.

(221) ID подсовывается 1С-ке при создании документа. Так что УРБД уносит штатно.

(227) к (223)

(226) Что-то мне подсказывает, что после попадания из центра документа с ID 100000000 в периферийную базу, там уже будут создаваться документы исходя из этого.
Поправьте, если кто знаком ближе с таким нюансом.

(229) Расскажите как вы ИД будете подсовывать?

(230) Просто теория в (218)

(230) впихнем невпиху/\емое!

(232) Невпехнут. В по крайней мере в дбф 1с использует первичный ключ в виде строки, причем с ведущими пробелами. У меня был легкий шок, братья нур сделали все чтобы убить производительность.

Вернее тот самый ИД36 для документоа

(229) совершенно верно, именно это и нужно. Чтобы вся база работала с ID начиная с 1000000. А я буду себе создавать документы с ID до 1000000.

(231) эта просто теория уже лет 5 как работает

(213) не понял, завидуете, сударь, или сплетничаете, сударыня? :-)

(218) Создавая документ с идом, принадлежащим периферийке, ты либо задвоишь иды в периферийке (попадешь на используемый), либо, "отступив" гарантированно далеко, сделаешь дырку в идах периферийки (после обмена нумерация идов будет с максимального), и достаточно быстро исчерпаешь иды.
(да, в 226 - частное решение)
(226) можно новые иды "считать обратно", кстати. реализуемо, и не очень сложно.
вполне себе вариант. но мне он не нравится. Для сиквельных баз подойдет, в файловых будут проблемы с индексами.

(238) ну насчет быстрого исчерпания я не согласен. У меня же отложенные ID используются только документами перемещения из/в магазин. Прикинул, и отступил с очень приличным запасом, предварительно посмотрев какой вообще максимальный ID выдержит 1с.

Что только люди не придумают, лишь бы МОД не юзать. Специально же для этих случаев придуман.

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

(240) в первых версиях он доставлял немало геморроя.
да и зачем, собственно, если все можно легко разруливать руками...

(241) ну да. примерно так. Дырки не страшны, а при исчерпании отложенного диапазона всегда можно отступить еще раз.

(242) Так мне имхается - товарищ уже заикался о преобразовании типов документов и прочем. Как бы в результате за несколько лет напишет кривой аналог МОДа :)

(244) преобразование типов - имхо, идиотизм...
его задачи вполне штатно решаются штатными методами через лишний - "транзитный" -склад.

(245) Что такой ласковый-то? Ничего плохого, если перемещение с центрального склада на точку передастся как приходная накладная или что-то в этом роде. Иначе придется мириться с незакрытыми регистрами или дописывать, чтобы в ПБ перемещения только приходовали товар.
ой - сейчас меня с оном смешают. блин работы куча а я тут нарываюсь

(246) ничего хорошего. ибо документ должен отражать факт жизни.
и (что касается разных движений) должны быть одинаковы во всех базах.

(247) Ни в одной библии это не написано. Дело привычки. Открою Вам страшную тайну - когда я выдаю клиенту счет-фактуру выданную - у него она становится счет-фактурой полученной. И ни у кого крышу не сносит :)

(248) "у него" и "у тебя" - разные контексты.
а единая РБД - это единый контекст.
один факт в одной базе может порождать более одного документа - но тем не менее, эти документы тогда должны быть связаны.
ТС делает _перемещение_ и хочет отражать это куплей-продажей. Идиотизм. равно как идиотизм отражать куплю-продажу перемещением.

(249) Размышляя в рамках точки - для них это приход. Чтобы это было перемещением - на точке должна быть полная копия базы. Перемещение со склада, на котором и так висят миллиардные минуса тоже нелогично. Вот какого лешего на точке годами висит склад с минусами?

(250) размышляьть нао не в рамках точки, а в рамках всей РБД.
кроме того, нет такой операции - "просто приход". Есть либо поступление товаров от поставщика, либо перемещение между складами.

(251) Я, конечно, сейчас мозги клюю, но кладовщик или продавец в рамках РБД размышлять не должен. Он за товар расписался, что ему пришло. Двойная запись его не волнует. Ладно - завяжем, меня занесло.

(252) В рамках РБД должен размышлять тот, кто систему проектирует и внедряет.
за это ему и платят больше, нежели кладовщику или продавцу...

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

(254) это вопрос философский.
вероятность устойчивость работы системы с РБД есть произведение вероятностей устойчивой работы сервера ЦБ, устойчивой работы канала связи и устойчивой работы прокси на периферии... Т.е. всяко ниже "распределенки". Ну и в "централизованной системе" есть все данные, даже которые не нужно видеть.
в случае РБД базы работают в достаточной мере независимо, выше защищенность, ниже требования к каналам связи - но возникают вопросы потери обменов, коллизий и т.п.
все решается для каждой конкретной ситуации.

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

(250): ну регламентный(по-месячный) документ без миграции - с соответсвующим авто-заполнением и реестровой печ.формой с перемещениями за отчетный период (и иными "плюшками") - и для МОЛ не будет лишним. а движениями будет нулить остатки, "уехавшие" за счет полученных из других ИБ движений. ммм?..

(257) Если часы остановить - 2 раза в день они покажут точное время

(258): т.е. по сути сказать нечего - я правильно понял?..

(259) Так суть не была обозначена. Если суть в том, чтобы раз в месяц обнулять остатки, чтобы не пухли регистры - почему бы и нет. А в течение месяца белиберда по остаткам в отчетах и формах подбора так и будет. Хотя на это спокойно можно забить и сказать - так положено. А что положено на это дело программистом - не говорить :)

(260): суть обозначена - и заключается в решении указанной в (250) проблемы с накоплением отрицательных остатков на складах-источниках перемещений из-за приехавших "прицепом" к перемещениям других движений. хотя зачем я это объясняю - непонятно, как, впрочем, непонятна и причина того, что ті заявляешь, что "сути нет", и тут же єту суть формулируешь.
в течение месяца проблемы тоже особой нет - благодаря четкому разделению складов ПБ на "свои" и "чужие". подкручивается на раз-два.

(236) Не поделитесь методами создания произвольного ID документа ?
(249)(251) Категоричность признак глупости и я бы не стал однозначно утверждать как нужно оперировать данными в рамках УРБД. В констексте поставленной мне задаче движения в ПБ должны попадать только их, а уж как документ назовется "Купи/продай, Оприходование, Мана небесная" глубоко пофиг.

(262): тогда лепи ещё ПБ "товары в пути"...

(263) Если понадобится, почему бы и нет.

(262) 1.а какие проблемы сгенерировать документ с нужным id'ом?
2. Признак глупости - название, не отражающее сути. Или имеющее разночтение с общепринятыми определениями.
зы. Назови у себя в базе приходный документ "списанием", ПКО - "Расходом", инвентаризацию - "платежным поручением"... пофик же? :-) пусть запоминают...
ззы.
"#define TRUE FALSE  //счастливой отладки, суки..."©

(265) 1. На вопрос вопросом ...
2. Имя документу дал не мудрствуя лукаво "Приход по перемещению" с подсказочкой снизу, о ! Теперь остается набрать даунов на работу, чтоб было кому не понять что отражает этот документ.

(266) 1. Так в чем вопрос? Имена таблиц известны, структура базы известна, форматы идентификаторов известны...
2. считай меня дауном, но перемещение - оно одно. по определению.
зы. у вас есть внктри компании словарь террминов, глоссарий, корпоративный справочник? база знаний?

(267) не, лезть в таблицы чтобы создавать с нужным ID не айс. Это отдельно для SQL, отдельно для DBF, проблемы всякие полезут.

(268) а другого способа нет.
ну, разве что кроме "создать штатно, а потом заменить ид на свой" :-)
если есть другой способ - скажи :-)

(269) ну я бы не был столь категоричен. Есть такая функция в кишках системы, называется GetDefDBSign. Вот к ней и можно приклеиться и подменить вновь сформированный ID на свой.

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

(270) Возможно. не пробовал хучить самостоятельно.
Но такой способ ничем не лучше прямого доступа к базе.

(272) ну почему же, как мне кажется - лучше и универсальней. Засчет того, что с базой работает сама 1С-ка и мы ей не мешаем.

(273) И ваять отдельную компоненту?

(274) ну да

(275) возникает ТКВ...

(267) Ага, осталось заказчику сказать, что млин из-за неопределенных религиозных соображений идейной ценностью общепринято не разбивать документы. Придется таскать всю базу по всем точкам и пусть они там смотрят всю инфу (можно и попортить заодно), и ипутся с обменом на мегафоновских свистках.
(275) Совершенно случайно не видели подобной компоненты в широком доступе ?)

(277) базу совершенно не нужно таскать по всем точкам. И более необходимой информации отправлять в ПБ тоже не нужно.

(278) Честно говоря я притомился из пустого в порожнее лить, на мой взгляд большинство возможных варианты обсудили в этой ветке.

(278)(279) Все еще трете?   ;-))

(280) просто похоже, что ТС - франч...

(281) Троллинг откровенный пошел ?

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

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

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

Хоть как-то ж.пу прикрыть :)

+(285) еще помогает расчет затрат на реализацию "так делать нельзя" и на исправление ситуации

(285) Да прикрыть-то проблем нет. правило "больше бумаги - чище жопа" - никто не отменял. обидно бывает... сейчас вон перетаскиваем в снеговика всё, на некоторые вещи достаю служебки - ржем всем отделом.

(236) А на коммерческой основе возможно поюзать вашу теорию ?

(288) если центральная база - сиквельная, то  генери ид вручную, и пиши в таблички.

(289) Удачи вам в этом безнадежном деле.

(290) почему ж безнадежном? Сейчас так документы из снеговика грузятся :-)

Подниму ветку, т.к. хочу подвести небольшой итог:
Система с пустышками взлетела и радует малыми пакетами обмена данных и скоростью загрузки в ПБ.
Создавал базу таким образом:
1. Сделал центральную со всеми справочниками.
2. Перенес в нее документы, которые бегают по всем ПБ.
3. Создал распределенные, загрузил в них только те, которые якобы должны были там создастся.
4. Обменялся, провел все в центре, опять обменялся и профит.

Серьезно времени потерял из-за того, что таким образом взялся создавать всю базу с начала года, а это порядка 100тыс. документов на 25 базах. Убил время, контора в тетрадках пишет.
Пришлось свернуть базу на 1 октября и за одну ночь успел все перенести.
Если еще придется делать подобную работу, однозначно буду смотреть в сторону подмены ID в таблицах, а не копирования доков.
Еще раз обращаюсь к monitor, есть варианты приобрести компоненту ?

Надсмотрщик, спасибо за идею, готов проставиться !

(292) а мог бы сделать все гораздо быстрее, и не останавливая работу....
зы. 100 тыс документов - не так и много.

(293) Наверно мог бы, если б опыта было больше в этой теме.

(292) Можешь ему "проставиться" - OFF: Одинэсник сильно заболел. Нужны деньги на лечение если так "жаждешь"

Ветку все не читал.
А ни кто не предагал переходить на 1с82?

(295) Готово !
(296) Дорого было бы писать заново, а типовая вряд ли устроила заказчика. +Лицензий вагон покупать.

(297) Обращайся. Если что.