Scribe for SQL Server
Restore a database
To restore backup scripts to a database all you need is a SQL Server user account with write permissions and access to the server. Following is the command line format for calling Scribe.
scribe restore /script_path:"file path" /destination:"connection string" /prep_script:"file path" /finish_script:"file path" /max_thread_count:5 /skip_thread_count:"true/false"
Output path for the generated script files. Files are named "Schema.sql", Constraints.sql, "Data0001.sql", "Data0002.sql", etc. based on the chunk size.
Destination data source to use, as a connection string surrounded by quotes.
/data_source:"Data Source=localhost;Initial Catalog=AdventureWorks;"
Path to an optional SQL Server script to run prior to the restoration. Useful for dropping objects prior to a clean restore.
Path to an optional SQL Server script to run after the restoration. Useful for ensuring multi-user mode, or other settings.
Determines maximum number of threads to allow (1-50; default: 5).
At start, scribe tries to determine if the remote database server can handle multiple concurrent recordsets. If you know it can, you can save a few seconds by skipping this check (true or false; default: false).
When Scribe runs a restore operation, it first tries to determine if the remote server can handle multiple threads (connections) by attempting a schema pull with 2 threads. This process usually takes a few seconds, so if you want to save some time you can set your thread count and disable the check.
The scripts are executed in the following order:
This file contains table, view, and other schema objects without foreign key constraints. This file does contain other constraints, like default column values.
These files, numbered from 0001 up to 9999 hold chunked data insert scripts.
This file contains table foreign key constraints and is restored last.