Skippr Docs

Appearance

How to Configure MSSQL as a Source Connector ​

May 2026

MSSQL source setup is mostly connection-string discipline: server, database, encryption behavior, and a login that can actually read the tables.

Short Answer ​

Configure MSSQL as a source by setting source.kind to mssql and passing a full ADO.NET connection_string. The connector expects the usual SQL Server fields such as server, database, user id, and password, and the docs call out Encrypt and TrustServerCertificate because those often decide whether the first connection works.

For local development, a connection string like server=tcp:127.0.0.1,1433;database=testdb;user id=sa;password=...;TrustServerCertificate=true is a common starting point. For Azure SQL, use the fully qualified server name and typically Encrypt=true, which makes the connector behave more like the production deployment you will eventually run.

Why Teams Struggle with This ​

SQL Server connectivity problems usually sit inside the connection string rather than the source definition wrapper. Teams often have the right server and login but miss the port, certificate behavior, or Azure SQL server naming conventions that ADO.NET expects.

  • The connection string should be stored in MSSQL_CONNECTION_STRING, not checked into skippr.yaml.
  • The SQL Server login needs read access to the tables or views you want to ingest.
  • The runner must reach the SQL Server endpoint on the configured port, usually 1433.
  • Certificate settings matter: TrustServerCertificate=true can help local dev, while Azure SQL and production systems often require proper encrypted connections.

How Skippr Handles It ​

Skippr keeps MSSQL source setup direct by accepting the same ADO.NET string DBAs and application teams already understand. That is useful because you can validate the connector with the exact connection material the environment already uses instead of translating it into a custom parameter set.

A healthy first run means more than a successful login. Skippr should be able to connect to the intended database, read the target tables, and keep the source definition compact enough that later changes usually happen in one environment variable, not scattered across several fields.

  • ADO.NET connection-string support for SQL Server and Azure SQL.
  • Straightforward env-var handling through ${MSSQL_CONNECTION_STRING}.
  • Compatibility with certificate and encryption settings that often matter in enterprise environments.
  • A first-pass source setup that maps well to both local Docker SQL Server and managed Azure SQL.

What the First Useful Version Looks Like ​

If the connector reaches the server but fails authentication, inspect the exact login format and database segment inside the connection string before changing anything else.

For Azure SQL, validate the server FQDN and encryption settings from the actual runner host so local workstation assumptions do not hide a network policy issue.