When we execute a query in SQL Server Management Studio,
connect through a .NET application, or retrieve data using an ODBC or JDBC
driver, communication must take place between the client and SQL Server.
The protocol responsible for much of this communication is
called TDS, or Tabular Data Stream.
TDS is an application-layer request-and-response protocol
used by SQL Server clients and database servers to exchange login information,
SQL commands, stored procedure calls, results, errors, and other messages.
Understanding TDS can help database administrators,
developers, and support engineers troubleshoot connection issues, analyze
network traffic, and better understand what happens behind the scenes when a
SQL Server query is executed.
What Is TDS?
The client sends requests to SQL Server, and SQL Server returns responses through TDS.
These responses may contain:
TDS is called a tabular data stream because SQL Server commonly returns information as structured rows and columns.
Where Does TDS Operate?
TDS is an application-layer protocol. It commonly operates
over TCP/IP when applications connect to SQL Server across a network.
A typical communication path is:
Client application → TDS → TCP/IP → SQL Server instance →
Database
A default SQL Server instance normally listens on TCP port 1433.
However, it is important to understand that port 1433 is not permanently
required by TDS. Named SQL Server instances commonly use dynamically assigned
ports, and administrators can configure both default and named instances to use
different static ports.
Therefore, a more accurate statement is:
TCP port 1433 is the conventional default port for a default
SQL Server instance, but TDS can operate through other configured ports.
How TDS Communication Works
A SQL Server connection generally involves several stages.
1. Connection Establishment
2. Pre-Login Negotiation
3. Login Request
4. Login Response
Login Response
5. Client Request
Client Request
For example, when the following statement is executed:
SELECT *
FROM dbo.Employees;the SQL statement is packaged as a TDS SQL batch request and sent to SQL Server.
When an application executes a stored procedure through a
parameterised command, the request may be sent as an RPC request instead.
6. Server Execution
After receiving the request, SQL Server performs its normal
query-processing activities.
Server Execution
TDS transports the request, but it does not optimize or
execute the SQL statement. Those activities are handled by the SQL Server
Database Engine.
7. Server Response
SQL Server returns the results through TDS response packets.
The client driver interprets these tokens and presents the
result in a form the application can understand.
Understanding TDS Packets
Large TDS messages may be divided into multiple packets
before transmission.
Each TDS packet begins with an eight-byte packet header.
Microsoft’s specification states that this header identifies important
information such as the packet type and total packet length.
The header includes fields such as:
The data portion follows the header and contains the actual request, response, token stream, or protocol payload.
The requested TDS packet size can be supplied by the client
during login. SQL Server can acknowledge a negotiated packet-size change
through an ENVCHANGE token.
It is important not to confuse a TDS packet with a TCP
packet. A TDS packet belongs to the TDS protocol, while TCP and IP have
their own segmentation and packet-handling mechanisms.
Common TDS Message Types
TDS supports multiple message types for different
operations.
Common examples include:
These message types allow SQL Server to distinguish between
different categories of client activity.
Important TDS Response Tokens
SQL Server responses are often organized as a stream of
tokens.
COLMETADATA
Describes the structure of the result set.
It can contain information about:
The client must understand the column metadata before
correctly interpreting the returned row values.
ROW and NBCROW
These tokens contain row data.
NBCROW (Null Bitmap Compressed Row) is a variation
that can represent null columns efficiently through a null bitmap.
DONE
Indicates the completion of an operation or part of a
response.
These tokens can communicate details such as row-count
availability, errors, or whether more results follow.
ERROR
Contains SQL Server error information.
INFO
Contains informational messages that are not necessarily
execution failures.
RETURNSTATUS
Returns the integer status value generated by a stored
procedure.
RETURNVALUE
Returns output parameter information from an RPC or stored
procedure call.
ENVCHANGE
Indicates that something about the connection environment
has changed.
Examples may include:
LOGINACK
Confirms a successful login and provides information about
the server’s TDS compatibility.
A Simple TDS Request-and-Response Example
Suppose a user runs:
SELECT *
FROM dbo.Customers
WHERE country='USA';The process can be simplified as follows:
Client side
The client driver:
SQL Server side:
Returned token stream
The response may conceptually look like this:
COLMETADATA
ROW
ROW
ROW
DONE
The client library converts this stream into the grid,
dataset, data reader, or application object visible to the user.
TDS and Stored Procedure Calls
An application can execute stored procedures using RPC
messages rather than sending plain text as a SQL batch.
For example:
EXEC usp_GetCustomer
@CustomerID=102,
@IncludeOrders = 1A properly configured client library may send the procedure
name and parameters in an RPC request.
This provides a structured way to transmit:
SQL Server can return result sets, output parameters, a
stored-procedure return status, errors, and completion tokens through the TDS
response stream.
TDS and Multiple Active Result Sets
Multiple Active Result Sets, commonly called MARS,
allows supported SQL Server clients to have more than one active command or
result set on a single connection.
Without MARS, an application may need to fully consume or
close one result before executing another command on the same connection.
MARS does not mean that all commands automatically run in
parallel. It enables multiple logical activities to share a connection, while
execution behavior still depends on the application, command type,
transactions, and SQL Server processing.
TDS and Connection Pooling
Connection pooling is usually managed by the client provider
rather than TDS itself.
When an application closes a pooled connection, the physical
network connection may remain open and be reused for another logical
connection.
Before reuse, the provider and SQL Server must ensure that
the session is reset appropriately. This avoids the cost of repeatedly creating
a TCP connection, negotiating security, authenticating, and building a new
database session.
Therefore, TDS provides the communication mechanism, while
the client driver manages pooling behavior.
TDS and Encryption
TDS carries SQL Server communication, while TLS can protect
that communication in transit.
Depending on the SQL Server and driver configuration, the
client and server can negotiate encryption during connection establishment.
Encryption helps protect:
- Login
information
- SQL
statements
- Returned
data
- Session
messages
- Authentication
exchanges
Current SQL Server environments should use properly
configured encryption and certificate validation, particularly when connections
cross untrusted networks.
TDS 8.0 is the newer application-layer protocol version used
by supported clients to connect to SQL Server and is associated with modern
strict-encryption capabilities.
Why TDS Matters to Database Administrators
Most database administrators do not work directly with TDS
packets every day. However, understanding the protocol is useful in several
situations.
Troubleshooting connectivity
TDS knowledge helps distinguish among:
Analysing performance
Network traces may reveal:
- High
numbers of small requests
- Excessive
round trips
- Large
result sets
- Long
delays between requests and responses
- Client-side
delays in consuming rows
- Query
cancellation attempts
- Repeated
connection establishment
However, TDS analysis should be combined with SQL Server
tools such as Extended Events, Query Store, execution plans, wait statistics,
and performance counters.
Investigating application behaviour
TDS can help determine whether an application is:
- Sending
SQL batches or RPC requests
- Repeatedly
reconnecting
- Cancelling
requests
- Retrieving
unnecessary columns or rows
- Leaving
result sets open
- Generating
frequent network round trips
Supporting security investigations
Protocol-level evidence can help identify:
- Unencrypted
connections
- Unexpected
clients
- Abnormal
login behaviour
- Suspicious
request patterns
- Connections
to incorrect instances or ports
Because TDS payloads may be encrypted, network captures do
not always expose readable SQL text or returned data.
Common Tools Associated with TDS
Applications and tools that communicate with SQL Server
through compatible drivers include:
For deep troubleshooting, administrators may also use:
- Wireshark
- Microsoft
Network Monitor or equivalent tracing tools
- Extended
Events
- SQL
Server error logs
- Driver
tracing
- Windows
event logs
- SQL
Server Configuration Manager
Packet capture should always be performed in accordance with
the organization’s security and privacy policies.
TDS Compared with Other Protocols
TDS is specifically designed for database communication. It
supports structured requests, authentication, SQL execution, metadata, rows,
parameters, errors, and database-session management.
Common Misunderstandings
“TDS always uses port 1433.”
Not always.
Port 1433 is the conventional TCP port for a default SQL
Server instance. Named instances commonly use dynamic ports, and administrators
can configure another static port.
“TDS executes the SQL query.”
TDS transports the SQL request and the response.
The SQL Server Database Engine parses, optimises, and
executes the query.
“One SQL statement always equals one TDS packet.”
Not necessarily.
A message can span multiple TDS packets, and the network
stack can segment or combine data independently.
“TDS and TCP are the same protocol.”
They are different layers.
TDS is an application-layer protocol that can operate over
TCP/IP.
“A successful backup or query is directly controlled by
TDS.”
TDS communicates the request and outcome, but the relevant
SQL Server engine components perform the actual database operation.
Practical DBA Troubleshooting Sequence
When investigating a SQL Server connection problem, a DBA
can examine the process in stages:
- Confirm
that the server name resolves correctly.
- Verify
that SQL Server is running.
- Identify
the port used by the instance.
- Test
whether the TCP port is reachable.
- Check
SQL Server network-protocol configuration.
- Review
firewall rules.
- Examine
pre-login and encryption settings.
- Validate
the certificate and client trust configuration.
- Confirm
authentication details and login permissions.
- Check
the default database and database availability.
- Review
SQL Server and client-side logs.
- Capture
network or Extended Events data when deeper analysis is required.
This staged approach helps determine whether the failure
occurs at the network, protocol-negotiation, authentication, session, or
database level.
Conclusion
TDS is the language through which SQL Server clients and
database servers exchange information.
It carries login requests, SQL batches, stored-procedure
calls, data rows, metadata, errors, status information, and session changes.
Although users normally interact with friendly tools such as SSMS, Power BI, or
application screens, TDS is working behind the scenes to transport their
requests and return SQL Server’s responses.
In simple terms:
TDS is the communication language that allows an application
to talk to SQL Server and receive structured database results.
