C
ChUIMonster
Guest
In the scenario where one is wanting to update a DEV db as described incremental backup and restore makes perfectly good sense. When the same data is being repeatedly updated incremental backup can create smaller files than after-imaging. That's because you are sacrificing point in time recovery -- all that you get is the end result. Which is fine for what he needs. On the other hand... 0) I would not recommend this as an alternative to after-imaging in a production environment. 1) If the backup is only taking a few seconds I'm not sure why there is much of an incentive to improve it... the files can't be all that big if they are being created that fast. 2) Developers who think that AI is complicated really ought to spend more time working with it 
3) AI is not /quite/ a "set it and forget it" that can just be made into a default option (even though I sincerely wish that it could be). The ai daemon does go a long ways towards getting there but the lack of a purge daemon to clean up the logs means that eventually your disk fills up and goes BOOM! If Progress would implement a retention policy with the ai archive daemon then it would truly be a feature that could be enabled by default.
Continue reading...
3) AI is not /quite/ a "set it and forget it" that can just be made into a default option (even though I sincerely wish that it could be). The ai daemon does go a long ways towards getting there but the lack of a purge daemon to clean up the logs means that eventually your disk fills up and goes BOOM! If Progress would implement a retention policy with the ai archive daemon then it would truly be a feature that could be enabled by default.Continue reading...