К сожалению на форуме так и не нашёл алгоритма для организации backup/restore c удалённого клиента для Firebird. Предполагается что к серверу клиенты имеют доступ только по TCP. (никакой шары и пр.)

Необходимо реализовать корректный механизм backup/restore с клиента.
Для работы с FireBird используются компоненты FIBPlus.
Т.к. делать restore в рабочую базу КАТЕГОРИЧЕСКИ не рекомендуется, то после backup выполняется restore во временный fdb-шник с другим именем. Потом основную базу можно dropнуть, но временный fdb, как я понимаю, переименовать средствами firebirda нельзя (или всё таки можно?).
Т.к. доступа к папке с файлами БД у клиента нет, то и его средствами переименовать временный fdb-шник не получится.

В общем, родился простенький алгоритм для решения этой проблемы.
1. Создаётся дополнительный fdb (dbname.fdb), в котором хранится имя основного fdb.
2. Для соединения с основным fdb, клиент сначала коннектится к dbname.fdb, получает имя основного fdb, после чего к нему и коннектится.
3. Алгоритм backup/restore выглядит следующим образом :
3.1 Делаем backup и restorим его в dd_mm_yy.fdb (т.е. новый fdb имя которого получаем по определённому алгоритму)
3.2 Переписываем в dbname.fdb имя основной fdb на dd_mm_yy.fdb.
3.3 Делаем drop старого fdb.

Вопрос в том, не изобретаю ли я велосипед?

Привет, MEV!
Вы пишешь 24 апреля 2006:

M> Вопрос в том, не изобретаю ли я велосипед?

Изобретаешь.
Зачем тебе ресторить базу туда же, да ещё и удалённо?..
Это штатная ситуация?

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Привет, MEV!
AC>Вы пишешь 24 апреля 2006:

M>> Вопрос в том, не изобретаю ли я велосипед?

AC>Изобретаешь.
AC>Зачем тебе ресторить базу туда же, да ещё и удалённо?..
AC>Это штатная ситуация?

AC>--
AC>With best regards, Alex Cherednichenko.

B/R базы переодически запускать неоходимо, т.к. данные часто обновляются в немаленьких объёмах добовляются/удаляются и т.д.
Надо удалённо, потому как во многих фирмах, особенно мелких конторах, нет своего сис.админа или появляется он очень редко.
И не факт, что у юзера будет физическая возможность добратся до сервака.

Здравствуйте, MEV, Вы писали:

MEV>B/R базы переодически запускать неоходимо, т.к. данные часто обновляются в немаленьких объёмах добовляются/удаляются и т.д.

Каким образом одно связано с другим? Конкретно — частота изменения данных с необходимостью периодического restore?

MEV>К сожалению на форуме так и не нашёл алгоритма для организации backup/restore c удалённого клиента для Firebird. Предполагается что к серверу клиенты имеют доступ только

А инкрементальный бэкап-рестор у них есть? может, тогда им воспользоваться? а если нет — может, на Jet или MySQL перейти?

Привет, Maxim!
Вы пишешь 24 апреля 2006:

MEV>> К сожалению на форуме так и не нашёл алгоритма для организации
MEV>> backup/restore c удалённого клиента для Firebird.
MEV>> Предполагается что к серверу клиенты имеют доступ только

MSS> А инкрементальный бэкап-рестор у них есть?

Только с версии 2.0

--
With best regards, Alex Cherednichenko.

Здравствуйте, Пацак, Вы писали:

П>Здравствуйте, MEV, Вы писали:

MEV>>B/R базы переодически запускать неоходимо, т.к. данные часто обновляются в немаленьких объёмах добовляются/удаляются и т.д.

П>Каким образом одно связано с другим? Конкретно — частота изменения данных с необходимостью периодического restore?

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