Helen,

> Well - either/ you want the raw data in the database (because
> you have to return to it for some reason) and therefore it should
> be backed up or /you are not interested in the raw data once
> it has been extracted into tables
>
> Are you using external tables for the raw input?

While I generally agree, there is a case at BroadView where we don't want to backup all the data all of the time.

In our case, there are 2 types of backups which are performed: system/complete vs. testing/debugging transfer.

Our application is deployed to 50+ client locations across the world. The local client databases store many details which are important to the clients usage of the application, but a un-important from a system testing and debugging perspective (this includes all user generated reports and user added file attachments).

These un-important items can account for a significant amount of space (2GB+/25%), and contributed to a significant amount of data transfer/transfer time.

So, we created a modified GBAK which added a new "-SKIP_DATA" option to the backup/restore to allow for us to specify tables which we didn't want the data backed-up/restored for. Naturally, this option is only used when the testing/debugging backup are created.


Sean


P.S. We will be offering the modification to the project for possible inclusion in a future release.