Two log streams per run, a color-coded console mirror, automatic numbered backups, and engine-notice routing that differs by platform. Everything a CI pipeline needs from a deploy tool.
Good logs are the difference between a quick diagnosis and a long night.
All CLI tools use Apache Log4Net. Each tool ships with an embedded Log4Net configuration that is loaded automatically at startup — there's nothing to configure.
Each tool writes two log files per run:
| Tool | Progress log | Error log |
|---|---|---|
| SchemaQuench | SchemaQuench - Progress.log |
SchemaQuench - Errors.log |
| SchemaTongs | SchemaTongs - Progress.log |
SchemaTongs - Errors.log |
| DataTongs | DataTongs - Progress.log |
DataTongs - Errors.log |
The progress log receives all informational output: the startup banner, active configuration, per-object progress, and completion status. Everything written to the progress log also appears on the console in real time.
The error log receives only error-level entries (such as SQL execution errors) and does not echo to the console.
Both log files are overwritten at the start of each run. Previous runs are preserved through the backup rotation described below.
The console is a live mirror of the progress log, not a separate channel. Watching the console while a quench runs lets you follow startup, per-object progress, and completion in real time without tailing a file. Log4Net colorizes the console stream by level so trouble catches your eye the moment it appears:
| Level | Console color |
|---|---|
| Informational | Green |
| Warning | Yellow |
| Error | Red |
When a script fails, you see a short error summary on the console and in the progress
log (red, so it's hard to miss): the failing script path and the engine's error
message, along with a Debug Script: pointer when a generated procedure
is the source. That's enough to know what failed and where to look.
The full detail — the exception line numbers and the complete SQL batches SchemaSmith submitted — lands in the error log only, so the console and progress stream don't drown in multi-KB failed-batch text during a rough deployment. When a run fails, the progress log tells you what broke; the error log tells you exactly what SQL was sent when it broke.
CI agents that capture stdout get the progress stream for free. If your pipeline step only saves stdout, you still have a readable transcript of successes and error summaries; archive the error log separately to keep the failed-batch detail.
By default, logs are written to the tool's executable directory. Override this with
--LogPath:
SchemaQuench --LogPath:C:\Logs
SchemaTongs --LogPath:C:\Logs\schemasmith
DataTongs --LogPath:D:\BuildLogsSchemaQuench --LogPath:/var/log/schemasmith
SchemaTongs --LogPath:/var/log/schemasmith
DataTongs --LogPath:/var/log/buildlogsImmediately after loading configuration, every tool logs its complete active configuration to the progress log. This includes the tool name and version number, followed by every configuration key and its value (with passwords masked). This makes it straightforward to verify what settings were in effect for any given run.
Configuration keys whose names contain Password or Pwd
(case-insensitive) are replaced with ********** in the log output. All
other values are logged as-is, including connection strings, server names, and token
values.
2026-03-06 09:14:01,234 - SchemaQuench
2026-03-06 09:14:01,235 - Version: 5.2.1.0
2026-03-06 09:14:01,236 - Configuration:
2026-03-06 09:14:01,237 - Server: sql-prod-01
2026-03-06 09:14:01,238 - User: schemasmith
2026-03-06 09:14:01,239 - Password: **********
2026-03-06 09:14:01,240 - VerboseLogging: falseWhen a tool finishes (whether successfully or after an error), it backs up its log files before the process exits:
--LogPath value, or the executable directory if not specified).<ToolName>.0001. If that directory already exists, it increments: .0002, .0003, and so on.<ToolName> - *.log into the new subdirectory.The base log files in the log directory are not deleted after backup. Each run overwrites the base files and writes a copy into a new numbered subdirectory. This preserves the history of every run while keeping the base files current with the latest.
Example after three SchemaQuench runs:
C:\Tools\
SchemaQuench - Progress.log (latest run)
SchemaQuench - Errors.log (latest run)
SchemaQuench.0001\ (first run backup)
SchemaQuench.0002\ (second run backup)
SchemaQuench.0003\ (third run backup)
When SchemaQuench runs one of its generated procedures against your target database,
it dumps the exact SQL it sent to a companion .sql file next to the tool
executable. If the procedure throws, the error log points you at the file by name.
Open it in your query tool of choice, re-run the SQL by hand, and reproduce or narrow
the problem without guessing what SchemaSmith actually executed.
Generated procedures cover missing tables and columns, modified tables, indexes,
foreign keys, materialized views, indexed views, and the table-JSON parse step. Debug
files follow the pattern SchemaQuench - <operation> <server>.<database>.sql:
SchemaQuench - Quench Missing Tables And Columns prod.NW.sql
SchemaQuench - Quench Modified Tables prod.NW.sql
SchemaQuench - Quench Indexes prod.NW.sql
SchemaQuench - Quench Foreign Keys prod.NW.sql
SchemaQuench - Quench Materialized Views prod.NW.sql
SchemaQuench - Quench Indexed Views prod.NW.sql
SchemaQuench - Parse Table Json prod.NW.sql
Each run overwrites the debug files for the operations it actually performed.
Operations that don't apply to your platform (for example, Indexed Views
on PostgreSQL or Materialized Views on MySQL) produce no file. Debug
files always land next to the tool executable — --LogPath controls
the progress and error logs, not debug SQL.
Debug files only cover SchemaSmith's own generated procedures. The user-authored
scripts in your package (Before/, After/, migration scripts,
programmable objects) already live on disk at their original paths — when one
of them fails, the error log points at the file you authored.
SchemaSmith surfaces the database engine's informational output — notices, prints, and server-side status messages — into the progress log so you can see what the engine is telling you. The wiring differs per platform because each driver exposes that stream differently.
PRINT output and severity-10-or-lower errors arrive through the
InfoMessage event. By default SchemaSmith promotes only
severity-above-10 errors and RAISERROR ... WITH STATE 100
notifications to the progress log; set VerboseLogging: true to
include every PRINT and informational message.
RAISE NOTICE and RAISE WARNING output arrives
through the Npgsql Notice event and lands in the progress log.
SchemaSmith filters out the "... does not exist, skipping" and
"... already exists, skipping" notices that
DROP ... IF EXISTS and CREATE ... IF NOT EXISTS
produce during normal runs, so your log stays readable.
The MySQL connector doesn't fire info-message events for long-running stored
procedures, so SchemaSmith uses a table-based status channel. A
SchemaSmith_StatusMessages table in the target database (created
automatically during kindling) holds per-session progress rows; the generated
quench procedures INSERT into it as they work, and a background
poller on a separate connection reads the new rows every 200ms and writes them
to the progress log. SessionId is scoped to
CONNECTION_ID() so concurrent runs don't cross-talk, and the
monitor deletes its rows on shutdown. There's no VerboseLogging
dial on MySQL — what you see is whatever the procedures chose to publish.
VerboseLogging is a SchemaQuench setting and applies only to SQL Server's
InfoMessage stream. The PostgreSQL and MySQL paths already behave the way
VerboseLogging: true behaves on SQL Server — SchemaSmith surfaces
every engine-side notice (PostgreSQL) or procedure-emitted status message (MySQL) by default.
| Code | Condition | Recommended action |
|---|---|---|
0 |
Normal completion | None — the operation succeeded. |
2 |
One or more database quenches failed (SchemaQuench only) | Check the progress and error logs for details on which databases failed and why. Fix the failing scripts and re-run. |
3 |
Unhandled exception | An unexpected error occurred. The exception is logged to both the progress and error logs before exit. Report the error with the log contents if the cause isn't obvious. |
4 |
Log backup failure | The tool completed its main work but couldn't back up the log files. Check directory permissions and disk space in the log directory. The base log files may still be readable even though the backup failed. |
Last reviewed May 2026 by the SchemaSmith Team.