SchemaSmith Documentation
AppSettings - SQL Server (Enterprise)
Standardize defaults via appsettings.json for CI/CD and repeatable deployments.
Standardize defaults via appsettings.json for CI/CD and repeatable deployments.
appsettings.json centralizes runtime configuration for SchemaQuench on SQL Server.
For the shared configuration loading order (file, environment variables, CLI switches) and
the SmithySettings_ environment variable prefix, see
Configuration Loading and
Environment Variables.
This page documents the SQL Server Enterprise-specific settings, including secondary server support for Availability Group deployments.
| Setting | Value |
|---|---|
| SchemaPackagePath | The path to the root of the product repository/package. SchemaQuench requires the repository to be placed in a location where the files can be loaded by the executable. The location will contain the Product.json and the folders for templates and other files. This can be a folder or a zip file containing the package contents. |
| Target:Server | The server to connect to. |
| Target:User | The sql user to authenticate as. Leave blank for windows authentication. |
| Target:Password | The sql user password. Leave blank for windows authentication. |
| WhatIfONLY | Defaults to false. When true a what if run is done that shows the changes that are detected and what would be applied if allowed to. This run may not be accurate if there are dependencies upon other actions that have not been applied. |
| Target:SecondaryServers | The secondary server(s) to quench. The login information must be identical to the primary. Secondary servers are for supporting the other, non-primary servers in a clustered setup. Can be a list if there are multiple servers setup in the cluster. |
| MaxThreads | Defaults to 10 (max of 20 allowed). The number of threaded updates that happen simultaneously for each template being quenched. |
| DropTablesRemovedFromProduct | Default true. Allows for updating only a subset of tables in a patch scenario, without removing tables not included in the package. |
| UpdateTables | Default true. Allows bypassing the table update completely. For data fix pipelines it is sometimes desirable to deploy via a user with write access but not enough privileges to modify tables or procedures. |
| KindleTheForge | Default true. Allows bypassing the forge kindling, again to allow for the use of limited access users in specific pipelines. This option assumes a release has been previously applied to the environment in the past to properly create the procedures and tables needed by the tool suite. |
| CheckpointDirectory | The directory where checkpoint files are written when using the --ResumeQuench flag. Defaults to the log directory if not specified. See Checkpointing for full documentation on checkpoint-based resume. |
| DeliverData | Default true. When set to false, skips the automatic Data Delivery step during quench. Useful for pipelines that only need schema updates without data synchronization. |
| RunScriptsTwice | Default false. Re-executes all user scripts a second time after the initial pass. Useful when scripts have circular dependencies that resolve across two passes. See Migration Scripts for details. |
| VerboseLogging | Default false. When set to true, includes PRINT messages and other informational output in the logged results from table updates and scripts. |
If a template defines multiple databases, each of those updates occur in a thread. This is
defined in the configuration file in the option MaxThreads, the default is 10.
Schema Quench supports clustered sql server installations. Synchronizing Logins and Jobs are at least two cases where you may need to quench parts of your configuration against a secondary set of servers.
Secondary servers can be defined in Target:SecondaryServers and
configured for use in
product and template script folders.
Additionally, there is the ability to add the ServerToQuench in the
template.json which can be Primary,
Secondary or Both just like the product folder definition. A use
case for this would be to apply objects to master on both servers or any database not part
of the availability group.
While our primary focus is on ensuring that each server and database is in a true and expected state after a release is deployed, we also recognize the need to sometimes perform limited scope changes whether specific data fixes or emergency patches between releases. We also recognize that it is preferable not to have to add additional tools processes for such actions.
To that end we have exposed several granular control properties in the settings file:
DropTablesRemovedFromProduct, UpdateTables, and KindleTheForge. These settings combined
with the content of the update package will determine which steps are taken by SchemaQuench.
For a patch or data fix you can include a limited set of folders to simplify the update
package though product and template files are still needed, along with the basic folder
structure. to ensure quenching only the correct servers and databases.