Добрый день, такой вот вопрос есть база торговля она распределенная в подчинении больше 30 узлов, все эти 30 узлов в течении дня обмениваются с одном подчиненным узлом из которого потом в конце дня идет выгрузка в центральную базу. Обмен идет через FTP. По скольку интернет не везде хороший, происходят сбои. Часто возникают ошибки СУБД, теряются данные, появляются ссылки "объект не найден" и прочие прелести. Как лучше оптимизировать такой обмен? Разбить на подгруппы? И лучше было б если пользователи работали в одной базе, но подключались по удаленке?

(0) Конечно РДП или тонкий клиент. Нафига этот гемор с РИБом.

(1) а про тонкий клиент можно подробней?

(1) а если не будет интернета где-нибудь?

(0) у тебя плохой интернет, куда тебе RDP?

(2) v8: В чем смысл тонкого клиента 8.2

попробуй уйти от ФТП, сделай обмен через я.диск или прочую лабуду.

Торговлю на RDP??? Я понимаю еще там строительная организация, где онлайн не требуется..
(0) Оставляй на РИБ. Если есть большое желание все таки на RDP, то отличный инет с дублированием от разных провайдеров. Хотя и это не спасет от магистрального сбоя.

плохой интернет и битые ссылки никак не связаны

(7) бек-офис норм на рдп.

вместо фтп есть btsync и syncthing

(8) Связанны. Если обмен идёт не в пределах одной транзакции - связанны. Если сеанс обмена прервался, то до следующего удачного сеанса обмена в базе могут быть чудеса: проведённые документы без части движений, движения без регистраторов... я уж не говорю про "объект не найден" - это почти норма для РИБ :)

(11) в 7ке такого небыло..

(11) Не связаны. Файл сначала целиком загружается (или не загружается) с интернета. А потом уже идёт загрузка в базу

Ну... прогресс, однако: Инструментов - больше, настройки - тоньше... а юзверы - глупее => всё чудесатее и чудесатее :))

(13) Согласен, в (0) не связаны. Но могут возникнуть, например, в (6) - если напрямую использовать ресурс для обмена.

(12) На это состав пакетов обмена влияет. Если пакет сформирован условно хорошо - вероятность потерянных ссылок меньше, конечно. в 77 от безрыбья приходилось вылизывать пакеты до идеала.

(16) вы о чем.. в 7.7. нет проблем с УРБД чтобы что-то не дошло.

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

(16) Вылизывать пакеты? Что ты там делал? Данные зарегистрировались и выгрузились. Это же не правила обмена

(17) грубо говоря, там тоже было: пометил - дошло, не пометил - не дойдет

(19) ага. а если регистрацию данных никто не смотрел ни разу, кто тебе докажет, что он все "правильно" зарегистрировал?

ИМХО. РИБ как раз для случаев когда связь между точками плохая. Какой носитель использовать - не важно. Некоторое время мы вообще обмены возили на машине, на флешке. Утром в одну сторону, вечером в другую.  ФТП хорошая штука и при правильном обслуживании базы потерь объектов быть не может (удаление объектов только в центральной базе). Если у вас интернет совсем не стабильный, увеличьте частоту обменов. Какой ни будь гарантированно пройдет.
RDP хорош когда связь хорошая.
(8) Поддержу! Если специально не лести в функционал РИБ (вручную снимать регистрацию изменения объектов), то при любом интернете хоть раз, но гарантированная доставка будет и битых ссылок не будет.
(21) Зачем ее смотреть? Механизм работает сам автоматически.

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

Т.е. в идеале поднимать VPN и далее по обстоятельствам: либо в терминале, либо в толстом клиенте - в зависимости от толщины выделенных каналов. Но стабильность соединения должна быть 100%-ой, даже если каналы будут тонкие.

Если 100% идеальных каналов связи нет, то РИБ будет единственно возможным решением.

(20) ты может мод попутал с УРБД 7ки. У меня такогонебыло. что не дошло что-о и тем более разрыва каких-то данных из за транзакции.
Да УРБД для этого жестко блокировала базу и никто ничего не делает во время обмена.

(24) Да, соглашусь - МОД, конечно.

(12)Тогда и водка была крепче и девчонки симпатичнее...

Конечно, когда идет обмен на точке база заблокирована, они не могут ничего сделать пока идет обмен. Но проблемы происходят разные, объект не найден это самое без обидное, очень часто слетают документы которые допустим отредактировали в центральной базе, после обмена слетают к первоначальному виду, часто ошибки СУБД возникаю, ну и файлы небольшого размера, грузятся долго довольно.
Вот я и думаю а если допустим сделать две подчиненые базы и 15 точек в одну базу обменивать и ещё 15 в другую, а потом их сливать в центральную?

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

Куда с плохими энторнетами в RDP лезть? РИБ, конечно.

(29) плохой интернет, на некоторых точках не на всех. Если что такие точки можно на РИбе оставить, но их хотя б меньше в обмене будет.

(30) Ну можно и гибрид. Только смотри, если торговое оборудование подключаешь, могут быть заморочки.

(30) РИБ выгоднее тем, что меньше нагрузка на базу. В периферийной базе работают 1-2 пользователя. Фактически в монопольном режиме и данным мало, только свои данные.

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

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

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

(33) Это в центре, а я про узлы на местах в сети.
Кстати, прежде чем начнешь пользователей в общие базы по сети загонять, в переходно-тестовом режиме просто собери по несколько баз в одном месте и пусть пользователи поработают с ними через RDP или как там у вас будет сделано. А дальше по обстоятельствам решите: запускать их в общие или оставлять что-то распределенными

(35) понял, спасибо.

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