Skippr Docs

Appearance

What Network Access Skippr Needs for MSSQL ​

June 2026

MSSQL source access means the runner can reach the SQL Server endpoint and the login in the connection string can read the tables you want.

Short Answer ​

Skippr needs network access to the SQL Server endpoint named in the MSSQL connection string, including the configured port, plus a login that can read the tables or views you want to ingest. The docs show this plainly through the ADO.NET connection string format, with examples such as server=tcp:127.0.0.1,1433;database=testdb;user id=sa;password=..., so the effective boundary is one server name and one port that the runner can actually reach.

That is why MSSQL access is less abstract than it sounds. If the server sits behind a private network boundary, the job runner has to be inside that boundary or have a permitted path into it. If the server uses self-signed TLS in development, TrustServerCertificate=true may be the difference between a usable source and an SSL failure, even though the host and credentials are otherwise correct.

Why Teams Struggle with This ​

SQL Server connectivity problems are often blamed on credentials first, but the network shape usually shows up just as early. The runner might be pointed at a hostname that works only inside one subnet, or the login may authenticate while TLS settings still block the session from becoming useful.

  • The connection string has to point at the real SQL Server endpoint and port the runner can reach.
  • The SQL Server login must have read access to the tables or views you plan to ingest.
  • TLS settings such as Encrypt and TrustServerCertificate matter when the server certificate is not straightforward.
  • A working desktop client from inside a bastion host does not prove the job runner has the same path.

How Skippr Handles It ​

Skippr keeps MSSQL configuration compact by accepting one connection string, which is useful because it keeps the network question concrete. You are not asking whether Skippr can see SQL Server in general. You are asking whether this exact DSN can open a session from the runner environment and read the target objects.

The docs also give operators a practical path for test environments. A local Docker example on port 1433 and the Azure SQL example with Encrypt=true make it easier to explain what has to be reachable in local, Azure, and private-network setups.

  • Uses one ADO.NET connection string as the source boundary.
  • Supports explicit server, database, login, and TLS settings in the same DSN.
  • Works for local SQL Server, Docker-based test setups, and Azure SQL style endpoints.
  • Keeps the namespace tied to the actual database, schema, and table path being read.

What the First Useful Version Looks Like ​

The first useful version is one connection string stored in MSSQL_CONNECTION_STRING, one known server endpoint, and one or two readable tables that prove both the network and the login are correct.

If there is still debate about whether the problem is network or auth, test from the runner environment first. MSSQL issues get simpler as soon as you stop treating those as the same thing.