Skippr Docs

Appearance

How to Define MSSQL Ingestion Scope Clearly ​

July 2026

SQL Server scope is not just a connection string. It is the database named inside that string and the specific tables or views the read login is allowed to expose.

Short Answer ​

Define MSSQL ingestion scope with the database inside MSSQL_CONNECTION_STRING and the tables or views the SQL Server login can actually read. The source docs keep configuration minimal, but the namespace format still tells you what matters: mssql.{database}.{schema}.{table}. In practice, the database name and object-level permissions are what decide the real boundary.

That is why a connection string such as server=tcp:sql.internal,1433;database=erp;user id=skippr_reader;Encrypt=true should be reviewed alongside the login grants. If skippr_reader can read only sales.orders_vw and sales.customers_vw, that is a clear ingest contract. If it can read every table in erp, the boundary is broad whether or not the DSN itself looks tidy.

Why Teams Struggle with This ​

MSSQL scope often stays vague because the connection string carries host, database, auth, and TLS settings in one value, so teams stop at connectivity. The more important question is which schemas, tables, or views that login exposes once the connection succeeds.

  • A valid ADO.NET connection string does not tell reviewers whether the login can read two views or two hundred tables.
  • Using an app-level login often makes the ingest boundary much wider than the warehouse actually needs.
  • Views can be the better handoff when raw tables are too operationally noisy, but that choice should be explicit.
  • Changing Encrypt or TrustServerCertificate affects transport safety, not the source boundary, so it cannot substitute for object-level scoping.

How Skippr Handles It ​

Skippr keeps MSSQL simple by not pretending the connector can guess your intended boundary from SQL Server metadata alone. You provide the connection string, and the practical source boundary comes from the database and object permissions behind it.

That is a useful design because it pushes teams toward a cleaner upstream contract. If the SQL Server login is deliberately limited to one schema or a small set of views, the ingestion boundary becomes stable without extra connector-specific allowlists.

  • Uses a single SQL Server connection string as the connector entry point.
  • Leaves the database choice visible inside the DSN and the object boundary visible through grants.
  • Works well with read-only views when those are a cleaner handoff than raw tables.
  • Produces namespaces that reflect database, schema, and table names once objects are read.

What the First Useful Version Looks Like ​

The first useful version is one SQL Server database, one read-only login, and one or two tables or views the team is willing to stand behind as stable inputs. That is usually a much better boundary than "everything the app database happens to expose."

If the connector still depends on a broad login because the schema is messy, consider introducing views for the first release. That gives the warehouse a cleaner source boundary without waiting for a full upstream redesign.