SQL Packager™
Five good reasons to use SQL Packager in place of native SQL Server backups
- SQL Server backups can only be restored to another SQL Server that is exactly the same version as the original, and that includes service packs.
Although you may have a backup of a SQL Server database from a SQL Server 2000 and want to restore it to another SQL Server 2000, the restore operation will still fail if the two servers have different service packs installed. Since Red Gate's SQL Packager packages contain the information necessary to restore the database schema and data as SQL scripts, this bypasses the need to have identical versions of SQL Server in order to transport data from one server to another. - Restoring a SQL Server database to another server will attempt to restore the database's security accounts to the other database.
If those accounts have not been configured at the server security level, then the restore will also fail. A server administrator would be needed to re-create the security accounts before the restore takes place. SQL Packager does this bit for you – you do not need to know the names of the accounts in the database backup because SQL Packager will create them for you when the package is executed. - Restoring a SQL Server database backup can be tricky even for the most seasoned administrator.
The person performing the restore operation needs to be familiar with all aspects of database disaster recovery including the location of the data and log files as well as the proper order to restore full backups, differential backups, and transaction logs. SQL Packager eliminates the need for specialized skills on-site where your customers are located. Restoring a database package is as simple as double-clicking. - SQL backups are static archives of a database.
What if you want to apply changes between a backup to a live database? It simply can't be done. To restore a backup, you need to remove the live database and replace it. You can direct a SQL Packager package to only apply the differences between the package and the database, saving downtime. - Databases can become corrupt for a variety of reasons.
Perhaps an object has been deleted and, due to a system error, an entry for the object was left behind in the sysobjects table. If this causes a problem, you could always fall back on the database backup, right? But what if all your backups contain the same corruption? By using SQL Packager, you are creating the schema and data on a fresh database. All of the tables, indexes, and views are newly created, and all of the data will be consistent and verified. Any problems that would be "backed up" in SQL Server are not backed up using SQL Packager.
