Skippr Docs

Appearance

What Access Skippr Needs to Read from MSSQL ​

June 2026

MSSQL access is a direct database-login problem: the connection string has to point at the right server, and the login has to read the objects you want to ingest.

Short Answer ​

Skippr needs an ADO.NET connection string that reaches the correct SQL Server database, plus a login with read access to the tables or views you want to ingest. The runner also needs network access to the configured host and port, which matters just as much as the SQL login because a correct password does not help if the endpoint is not reachable.

A common example is a connection string for server=tcp:sql.internal,1433;database=erp;user id=skippr_reader;.... If that login can read sales.orders and sales.customers, Skippr can ingest those objects, but if the login lands in the right database and lacks SELECT on the chosen views, the source still is not ready.

Why Teams Struggle with This ​

SQL Server setups often blur connectivity, encryption, and object permissions together. In practice they are separate checks: the endpoint must be reachable, the connection string has to describe the right security behavior, and the login still has to read the data objects you care about.

  • The connection string has to name the correct server, port, and database, not just any SQL Server instance you can reach.
  • The login needs read access to the tables or views the extract will touch.
  • Development environments with self-signed certificates may need TrustServerCertificate=true, while production or Azure SQL usually expects encryption settings to be deliberate.
  • A valid login can still fail the pipeline if network controls block the SQL Server port from the runner.

How Skippr Handles It ​

Skippr keeps MSSQL access close to the native SQL Server model by taking a single connection string instead of hiding connection behavior behind a connector wizard. That is useful because SQL Server teams already reason in terms of server, database, login, password, and certificate settings.

The docs also keep the read boundary simple: the login needs access to the target tables or views. Once the first run succeeds, you know the endpoint, connection string, and object-level grants all line up well enough for repeatable ingestion.

  • Uses one ADO.NET connection string for SQL Server connectivity.
  • Depends on table or view read access rather than a custom Skippr permission model.
  • Works with local SQL Server, Docker setups, or Azure SQL style endpoints.
  • Keeps secrets out of skippr.yaml by relying on environment variables for the connection string.

What the First Useful Version Looks Like ​

The first useful version is one login, one database, and one short table or view list that you can validate directly in SQL Server before broadening the source.

If SSL or port settings are still unsettled, fix that before blaming schema logic because most MSSQL access failures happen before any real extraction work starts.