Skippr Docs

Appearance

How MSSQL Source Authentication Works in Skippr ​

June 2026

MSSQL source authentication in Skippr lives inside one ADO.NET connection string, so the server name, database, login, password, and TLS settings need to be correct together.

Short Answer ​

MSSQL source authentication in Skippr is connection-string based. The connector expects an ADO.NET connection string in MSSQL_CONNECTION_STRING, so the auth model is the SQL Server login embedded in that DSN together with the server, database, password, and any TLS-related settings such as TrustServerCertificate or Encrypt.

That matters because the same login model behaves differently across environments. A local Docker SQL Server often works with TrustServerCertificate=true, while Azure SQL expects the fully qualified server name and Encrypt=true. Skippr is not trying to infer those details for you. It will authenticate with exactly the DSN you provide.

Why Teams Struggle with This ​

The main risk is assuming that a valid username and password are enough. The docs frame MSSQL authentication as a full connection-string problem, which means hostname, port, database name, TLS behavior, and login rights all participate in whether the source can authenticate cleanly.

  • The connector authenticates through one ADO.NET connection string rather than separate host and password fields.
  • Azure SQL commonly needs Encrypt=true, while local dev setups may rely on TrustServerCertificate=true for self-signed certificates.
  • The SQL Server login must be able to read the tables or views the source will ingest.
  • Using ${MSSQL_CONNECTION_STRING} keeps credentials and environment-specific TLS settings out of checked-in config.

How Skippr Handles It ​

Skippr makes the SQL Server auth model easier to review by keeping it to one DSN. That is useful because an engineer can test and discuss the exact string the runtime will use instead of reconstructing the final connection from several disconnected fields.

The result is a source that is easy to explain operationally. If the DSN names the wrong server, wrong database, or wrong TLS mode, authentication fails for a clear reason. If it is correct, the same string works consistently for repeated runs.

  • Single-field MSSQL authentication through ${MSSQL_CONNECTION_STRING}.
  • Support for environment-specific TLS parameters inside the DSN.
  • A documented requirement that the SQL Server login can read the intended tables or views.
  • A small auth surface that works equally well for local SQL Server and Azure SQL.

What the First Useful Version Looks Like ​

The first useful version is one DSN that opens one known database from the same runtime environment that will execute Skippr. That proves server naming, TLS, and login access together.

If you are moving between local SQL Server and Azure SQL, treat the connection string as environment-specific configuration, not as a reusable constant with one token swapped in.