How to Generate Scripts in SQL Server With Data
In SQL Server, SQL scripts can turn what's usually a multi-hour database migration into a quick, predictable task. With correct settings, you can avoid data loss, prevent mismatched environments, and deploy a complete database anywhere in just minutes. This capability is worth mastering before your subsequent migration.
This guide will explain how to do this task in a SQL Server IDE, the settings that make the difference, and how to apply them in real-world deployments where speed and precision matter most.
What does it mean to generate scripts with data in SQL Server?
In SQL Server, creating SQL scripts with data means that you make a single SQL file that contains both the database's definition and the records inside it. The script includes all objects (tables, views, indexes, constraints) followed by INSERT statements for the data itself. When executed, it rebuilds the database precisely as it exists at the moment of scripting.
It is different from the default "schema only" option in SSMS, which captures the structure but leaves the tables empty. Schema-only scripts are lighter and faster to produce, but they require separate data loading steps to create a working copy.
Schema vs schema + data scripts
| Script type | Captures | Best for |
|---|---|---|
| Schema only | Object definitions (tables, views, procedures, indexes, constraints) without any data. | Deploying a fresh database structure, version-controlling schema changes, and distributing design without exposing data. |
| Schema + data | Complete schema plus all table contents as INSERT statements. | Migrating small or reference-heavy databases in one step, cloning environments, and quick recovery without backup files. |
Bottom line: Schema-only scripts give you the blueprint; schema + data scripts give you the fully furnished building.
When do you need scripts with data?
Writing SQL scripts that include both schema and data is the right choice if you need a complete and portable snapshot of your database. Typical scenarios include:
- Migrating databases in a single deployable file that contains both structure and data.
- Capturing reference and seed data alongside the schema for version control.
- Creating tests or staging environments with realistic production data.
- Sharing a plug-and-play database for demos, training, or collaboration.
However, for large transactional systems, this method can be impractical due to file size and execution time. In those cases, backups, BACPAC exports, or bulk copy tools are more efficient.
Before outlining how to generate these scripts, let's compare the capabilities of the two primary tools available for this process.
SSMS vs dbForge Studio for SQL Server
While both SSMS and dbForge Studio for SQL Server can create SQL scripts with schema and data, their capabilities differ significantly. The table below highlights the key differences to help you choose the right tool for your workflow.
| Feature | SSMS (SQL Server Management Studio) | dbForge Studio for SQL Server |
|---|---|---|
| Script schema + data | Supported via the SQL Server Generate Scripts wizard | Supported with enhanced UI and flexibility |
| Advanced scripting options | Limited (basic options in wizard) | Extensive (collation, constraints, triggers, more) |
| Selective table row export | Not supported natively | Supports data filtering and row-based export |
| Export output options | File, Clipboard, or New Query Window | File, SQL Editor, Clipboard, and Project Export |
| GUI usability | Basic, requires multiple clicks | Modern UI with step-by-step navigation |
| Large dataset support | Limited; may lag with large data volumes | Optimized performance for large datasets |
| Automation/CLI support | No built-in CLI support | Includes command-line automation tools |
| Data comparison & sync | Not included | Built-in Data Compare and Sync features |
| Dependency analysis | Not available | Visual dependency and relationship mapping |
| Script formatting & templates | Basic, no customization | Customizable script formatting and templates |
| Pricing | Free | Commercial (with free Express Edition) |
| Best for | Basic scripting needs, small projects | Advanced scripting, migrations, and team collaboration |
With the differences in mind, let's look at how to generate schema and data scripts in each tool.
Using dbForge Studio for SQL Server to generate scripts with data
dbForge Studio for SQL Server condenses SQL Server scripting into a faster and more controlled process. Compared to SSMS, it consolidates schema and data scripting, filtering, formatting, and export options into a single, unified workflow, eliminating the need for multiple wizard screens. Additionally, such options as built-in row-level export filtering and preview and edit before saving allow us to avoid re-runs for small changes.
Now, let us explore how to generate scripts with data using dbForge Studio for SQL Server, step by step.
1. Launch the Generate Scripts tool. Choose Tasks from the Database menu, and select Generate Scripts. Alternatively, right-click the necessary database and select the same option from the context menu.
2. Check the general script generation options. You can specify the necessary SQL Server connection, the database, the path to store the script, define the output file name, and configure other options.
3. Optional: Load an existing script generation project file. If you already have a backup file, click Open to select it. Otherwise, skip this step.
4. Choose the content to script. On the Script content page, select both Structure and Data to include the database schema and all records. You can also include or exclude specific tables, views, and other objects.
5. Configure script options. On the Options page, define settings such as including indexes, triggers, constraints, collation, and extended properties.
6. Set error handling preferences. On the Error handling page, choose how the application should process errors and whether it should generate logs. Click Generate to start the process.
When the process completes, you can open the generated file immediately by selecting Open script and clicking Finish.
Next, let's walk through the same process in SSMS so you can see how it compares step by step.
How to generate a script with data using SSMS
SQL Server Management Studio (SSMS) includes a built-in Generate Scripts wizard that can output both schema and data. While it's not as flexible as third-party tools, it's reliable for small to medium datasets and quick exports. Let's explore how to use the SQL Server Management Studio's generate scripts feature.
Step 1: Open SSMS and launch the Generate Scripts wizard
- In Object Explorer, expand the server node and locate the target database.
- Right-click the database name, hover over Tasks, and select Generate Scripts…
- It opens the Generate and Publish Scripts wizard.
Step 2: Select objects to script
In the Choose Objects step, decide whether to:
- Script the entire database and all database objects - captures all tables, views, stored procedures, and functions.
- Select specific database objects - pick only the tables, views, or procedures you need.
Step 3: Set scripting options
In the Set Scripting Options page, choose how and where to save the generated script:
- Save as notebook - saves the script in a notebook format.
- Save as script file - outputs a .sql file for reuse, either as a single file or one file per object.
- Save to clipboard - copies the script for pasting directly into a query editor.
- Open in new query window - opens the script in SSMS for immediate execution or editing.
In SSMS, the Advanced Scripting Options dialog is the make-or-break step for generating scripts that contain both schema and data. By default, SSMS scripts only the schema, so you must explicitly change Types of data to script to Schema and Data.
- In the Set Scripting Options page of the Generate Scripts wizard, click Advanced.
- Scroll to the General section.
- Locate Types of data to script and change it from Schema only to Schema and data.
Without this change, the output will include only object definitions, no INSERT statements, regardless of the objects you selected earlier.
Other advanced options to consider
While you're in the Advanced Scripting Options dialog, it's worth adjusting other settings that can affect the completeness and portability of your script:
- Script DROP and CREATE: Useful when you need the script to recreate objects from scratch, replacing existing ones.
- Include Collation: Preserves collation settings for consistent text handling across environments.
- Script Indexes, Triggers, and Constraints: Ensures you capture performance and integrity rules along with the data.
Tuning these options upfront saves time later and prevents missed dependencies or inconsistencies when you run the script in a new environment.
Click OK, then Next, review the summary, and click Finish to generate the script.
dbForge Studio for SQL Server vs SSMS
While both SSMS and dbForge Studio for SQL Server can generate schema and data scripts, the experience and capabilities differ in key areas:
| Feature | SSMS (SQL Server Management Studio) | dbForge Studio for SQL Server |
|---|---|---|
| Flexibility | Exports all rows or none; no row filtering | Supports partial exports with row filtering |
| Formatting | Outputs plain, unformatted SQL | Uses customizable templates and script formatting |
| Automation | No built-in command-line scripting | Includes CLI support for scheduled or CI/CD script generation |
| Performance | Can slow or freeze on significant exports | Optimized for large datasets with faster processing |
Takeaways:
- Choose SSMS for quick, one-off schema and data scripts.
- Consider dbForge Studio for SQL Server for repeatable, significant, or selective exports; it offers a more efficient path.
Automating script generation with data
For repetitive or large-scale tasks, scripting from the GUI can be slow. Developers and DBAs often turn to automation to integrate script generation into deployment workflows, backups, or CI/CD pipelines. Two common approaches are PowerShell scripting and, where available, SSMS command-line options.
Using SQL Server PowerShell (sqlps)
SQL Server PowerShell extensions (sqlps or the newer SqlServer module) allow you to script database objects directly from the command line or in automation scripts. Below is a basic example that generates a schema and data script for a specific database.
Import-Module SqlServer
# Define parameters
$server = "SERVERNAME\INSTANCE"
$database = "MyDatabase"
$outputFile = "C:\Scripts\MyDatabase_SchemaAndData.sql"
# Connect to SQL Server
$serverConnection = New-Object Microsoft.SqlServer.Management.Smo.Server $server
$db = $serverConnection.Databases[$database]
# Set scripting options
$options = New-Object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.ScriptData = $true
$options.ScriptSchema = $true
$options.IncludeIfNotExists = $true
$options.ToFileOnly = $true
$options.FileName = $outputFile
# Script all tables
foreach ($table in $db.Tables) {
$table.Script($options)
}
Advantages:
- Can be scheduled with Windows Task Scheduler or integrated into DevOps pipelines.
- Works without opening SSMS.
Using SSMS via command line (SSMS.exe options)
SSMS supports some command-line switches for opening connections, but it does not provide a full non-interactive scripting mode. You can:
- Launch SSMS with a specific server, database, and query file preloaded.
- Use it in combination with .sql files generated by PowerShell or other tools.
Example:
ssms.exe -S SERVERNAME\INSTANCE -d MyDatabase -i "C:\Scripts\MyDatabase_SchemaAndData.sql"
This approach helps open pre-generated scripts in the IDE automatically; however, the actual generation is better through PowerShell, SMO scripting, or third-party tools like dbForge Studio for SQL Server, which offers CLI support.
Conclusion
If you need to recreate a SQL Server database precisely as it exists, scripting both schema and data is one of the most reliable methods. It preserves structure and records together, making it ideal for smaller migrations, quick recovery points, and building accurate test environments.
However, to get the most out of this approach, select the tool that best suits your workload. While SSMS is straightforward and dependable for occasional exports, it is less suited to complex or large-scale tasks. For larger datasets or when you need row filtering, automation, or consistent formatting, dbForge Studio for SQL Server delivers all of these capabilities.
Download dbForge Studio for SQL Server and see how it can improve your schema and data scripting from start to finish.
FAQ
Use the Generate Scripts wizard in SSMS or the export function in a SQL Server IDE like dbForge Studio for SQL Server. For large datasets, dbForge for SQL Server, with its row filtering and CLI automation, is typically faster.
Yes. In Advanced Scripting Options, set Types of data to script to Schema and Data to include both structure and records.
The Generate Scripts feature, which includes schema and data, is available in all modern SQL Server versions, including Express, starting with SQL Server 2008.
In the Choose Objects step of the wizard, select only the required tables. In dbForge Studio for SQL Server, you can also apply row filters to limit data further.
Yes. You can use PowerShell with SMO scripting or dbForge Studio for SQL Server's CLI to automate the process and integrate it into CI/CD pipelines.
Use Schema only for creating empty structures or version-controlling schema changes. Use Schema and Data for migrations, environment cloning, or when you need a working copy with records included.
Increase the maximum script size in SSMS settings or export in batches using filters. In dbForge Studio for SQL Server, use partial exports to keep file size manageable.
dbForge Studio for SQL Server offers built-in row filtering during export, giving precise control over which records you need to script.
Yes. dbForge Studio for SQL Server can generate scripts that include INSERT statements for selected tables and filtered datasets.
These include:
- Forgetting to set the Types of data to script to Schema and Data.
- Not including indexes, triggers, or constraints when needed.
- Exporting entire large datasets without filtering results in oversized scripts.