SchemaSmith Enterprise Documentation
appSettings.json
How to configure application settings
How to configure application settings
After the appSettings file is loaded, environment variables are applied. The settings
defined below can be set via setx commands or standard windows environment variables
using the prefix SmithySettings_. You can even override various production
configuration, such as setting Script Tokens.
See the
docker-compose.yml for an example of this usage.
| 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. |
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.