Dimitry Sibiryakov,
Это что за база такая?! На firebird?! Хелперы решили просто локальную задачу определения последнего изменения базы без изменения кода - один выполняется при выполнении запроса (проверяет изменилось ли число записей), другой при коммите транзакции фиксирует время если число изменившихся записей ненулевое.

kdvMolochnik,

что будет, если бэкап будет длиться больше минуты?
Это может случиться не только из-за увеличившегося размера БД, но и тормозов оборудования.
И, пользователь вынужден работать с базой в условиях постоянного бэкапа? Это ведь полный скан БД,
будет малозаметно разве что если база и бэкап на SSD.

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

Dimitry Sibiryakov,
А что такое "четверка"?

kdv,
Да такие базы будут бэкапиться долго. У меня поменьше думаю максимум 500 мегов, в минут уложится.

Dimitry Sibiryakov,
Имеет ввиду четвертый FB? Он же еще в бета версии, его можно ставить клиенту? Я только месяц назад перешел на FB3.

kdv я надеюсь, вы в курсе, что удаление (delete) порождает новые версии записей, и в результате база увеличивается.
То есть чтобы этого избежать время от времени нужно делать рестор на главной машине?

Симонов ДенисОднако существуют платные версии HQ Bird, Red Database, Avalarion в которых репликация сделано нормально.
Да и есть самописные реализации, где она сделана по уму хоть и не на уровне ядра. Твоя реализация совершенно не масштабируема и не надёжна.
Платные версии не хочу потому что клиент за них платить не будет, а такая задача вряд кому то понадобится еще. Да, немасштабируемое решение согласен.

982183Molochnik Во вторых автоматическое удаление старых записей во избежание бесконечного разрастания базы.
Старых записей или старых бэкапов?
Хотя и то и другой сомнительно...
Удаление всего, что может увеличить размер занимаемого пространства, в частности старые записи базы, старые лог файлы, а бэкапов ограниченное количество. Это пожелание клиента.

Dimitry SibiryakovОн всяко не будет хуже твоего поделия. Просто обеспечь регулярное обновление.

Так и сделаю попозже в след версии и предложу клиенту онлайн синхронизацию, может клюнет

maytonУ тебя - странный подход к восстановлению. В продуктовых базах потеря даже одной записи - это
потерянные деньги. Это репутационные потери. Что у тебя за база? Что за данные? Каким образом это ты (особо парясь!) принимаешь решение - где данные будут для тебя ценнее?

Да, все так. По счастью у меня не продуктовая база, а в основном статистические данные и оперируют ими обычно в статистических целях. Одна потерянная запись ни у кого денег не отнимет. Если бы это было важно я бы конечно так делать не стал (я вообще этим изначально не хотел заниматься и планировал использовать MS SQL с своими группами доступности, но клиенту не понравились дополнительные траты)
maytonМежду прочим "цифровой ник" тебе задал интересную задачу. Я не вижу ее правильного решения ни в каком виде.

А какую задачу он задал? Не понял в каком сообщении
maytonИли для тебя данные в принципе не особо ценные. Тогда зачем так страдать по последним изменениям?
Да, не особо ценные и поэтому раньше вопрос и не возникал и никого вообще это не парило. А этому клиенту понадобилось, там реально занимается этим только один человек со своим видением решения, вот его желания и исполняю.

Кстати сейчас пока тестировал архивацию, пара вопросов возникло. В 3-ем FB пароли можно менять SQL запросом а не gsec-ом, а запроса на бэкап-рестор так и нет. Это вообще планируется в 4й версии? И еще один вопрос - как можно определить что рестор прошел успешно? Если FB на локальной машине я просто удаляю файл базы перед рестором и смотрю не появился ли он после него. А если FB и файл базы на удаленной машине и доступ к нему через UNC путь закрыт, как тогда?