On Wed, 3 Aug 2011, Tony Whyman wrote:
Actually, my preference for creating a database in a deployed
application is to first create it on my local system using isql with
input from a script and then to save it using gbak in a portable
format. The TIBRestoreService is then used to create the database from
the backup archive when your program fails to detect a local database copy.
The advantages of this approach are that:
- you only ever have one file to distribute
- backup/restore is very robust and quick
- you can readily add Blob data to your archive and distribute it as
part of the archive
- the initial database is consistent across all deployments
Scripts tend to be more useful when issuing patches to existing
databases. In this case, simply calling isql from your program and
pointing it at a patch script can be much easier than embedding SQL
execution in your program.
Why ? You need SQL execution anyway.
If you want to use isql, you must detect where it is installed and whatnot;
You must write code to capture output or check for errors. In SQL execution
you don't need all that - you already have it.
I've used creation and update of database with TSQLScript for years, and
we've thousands of installed databases at client sites. You need the
SQL execution technology anyway, so IMHO there is little point in using
2 different technologies.
It means extra coding, and therefor extra room for errors.
As for backup/restore being robust: this is not 100% correct.
It is extremely easy to create a corrupt backup in firebird.
Just add a required field to any table with data, create the backup.
This backup cannot be restored.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
