Skippr Docs

Appearance

What to Check Before Ingesting from MSSQL ​

May 2026

MSSQL ingestion tends to fail for predictable reasons: wrong server naming, incorrect TLS settings, or a login that can connect but cannot read the tables you need.

Short Answer ​

Before ingesting from MSSQL, validate the ADO.NET connection string end to end: server, database, user id, password, and any TLS-related options such as TrustServerCertificate or Encrypt. The docs also call out a different shape for Azure SQL, where the fully qualified server name and Encrypt=true matter. On a first run, the most valuable question is not "can I ping the host?" but "does this exact connection string open the intended database with a login that can read the tables or views I want?"

A local Docker test often uses server=tcp:127.0.0.1,1433;database=master;user id=sa;password=...;TrustServerCertificate=true. An Azure SQL setup usually needs a server like myserver.database.windows.net,1433 with encryption enabled. Those are both valid MSSQL setups, but swapping the TLS assumptions between them is a fast way to turn a healthy ingestion into login or certificate failures.

Why Teams Struggle with This ​

SQL Server setups often look close enough to work until the connection string is exercised by a real client. A missing database name, the wrong server hostname, or certificate validation mismatches can all block the first ingestion even though the surrounding infrastructure appears healthy.

  • The connector expects an ADO.NET connection string, so the exact parameter names and formatting matter.
  • Azure SQL usually needs the fully qualified server name and production-safe encryption settings.
  • Local or dev environments with self-signed certificates may require TrustServerCertificate=true to avoid SSL provider errors.
  • The SQL Server login still needs read access on the tables or views you plan to ingest.

How Skippr Handles It ​

Skippr keeps the MSSQL source simple by relying on one connection string rather than a long list of separate fields. That makes first-run reviews easier: if the DSN is correct, the connector has what it needs to connect; if it is wrong, the failure surface is much smaller to inspect.

The docs are also refreshingly concrete about local Docker testing and Azure SQL differences. That helps teams verify the environment-specific pieces before they spend time blaming the ingestion layer.

  • Single-field MSSQL source config built around an ADO.NET connection string.
  • Clear connection-string examples for local SQL Server and Azure SQL setups.
  • TLS-related guidance for TrustServerCertificate and Encrypt when certificate behavior differs by environment.
  • A namespace shape of mssql.{database}.{schema}.{table} when you need to reason about extracted objects.

What the First Useful Version Looks Like ​

The cleanest first MSSQL pipeline targets one database with a connection string you have already validated from the same network environment as the Skippr runner.

If SSL or login errors appear during early testing, recheck the exact DSN values before you assume table access is the real problem.