Production Tracing Configuration

For production environments, Mertech recommends leaving tracing enabled at a minimal level so that errors and warnings are always captured without impacting application performance. The following configuration strikes a balance between visibility and overhead.

What This Configuration Does

  • Error and warning capture — TRACE_LEVEL -3 logs only errors and warnings, which has negligible performance impact. Normal application operations are not traced.

  • Bounded disk usage — TRACE_CIRCULAR_MODE Yes combined with TRACE_FILE_MAX_SIZE 1073741824 (1 GB) ensures the trace file never exceeds 1 GB. When the limit is reached, the file wraps and overwrites the oldest entries.

  • Preserved history — TRACE_OVERWRITE No prevents the trace file from being wiped clean on each application restart. Each startup is recorded in the file along with any errors, giving you a continuous history across restarts.

  • Startup information — Even at level -3, each application startup writes header information to the trace including the driver version, settings, and connection details. This makes it easy to confirm the runtime configuration of each client.

With this configuration in place, a production client machine maintains a rolling log of up to 1 GB of errors and warnings. The file can be collected at any time for analysis without disrupting the application and will contain startup information for every application launch along with any errors and warnings that occurred.

Choosing a Trace File Location

Tip

The user’s application data folder (e.g., %APPDATA%\YourApp\Logs\) is often the best location for trace files. It is writable without elevated permissions, specific to each user, and easy to locate for collection. This allows the trace file to be quickly gathered and sent to Mertech Technical Support when needed for analysis.

Avoid these common pitfalls:

  • System-protected folders (e.g., C:\Program Files\) — the application may not have write permissions, causing tracing to silently fail.

  • User temp folders — may be cleaned up by system maintenance or difficult to locate across different user profiles.

  • Network paths — can add latency to trace writes, may be unavailable during network outages, and risk multiple users overwriting each other’s trace files.

Writing to the user’s application data folder (e.g., %APPDATA%\YourApp\Logs\) is the best choice for most deployments — it avoids permission issues and keeps each user’s trace data separate. If that is not practical, a dedicated local folder (e.g., C:\BTR2SQL_Logs\) is a good alternative. If you have multiple applications on the same machine, use distinct trace file names for each.

Adjusting the Configuration

You can adjust the configuration to fit your environment:

Need

Adjustment

Smaller disk footprint

Reduce TRACE_FILE_MAX_SIZE (e.g., 104857600 for 100 MB).

More diagnostic detail

Increase TRACE_LEVEL to 0 (basic) or 1 (detailed). Be aware this will increase trace volume and may impact performance.

Temporary deep tracing

Use MdsSetSetting to increase the trace level at runtime without restarting the application, then reduce it when done.

Per-machine trace control

Use environment variables (e.g., btr2sql_TRACE_LEVEL) to override the mds_global.ini setting on specific machines.

See also