Is data retrieved from SQL Server compressed for transmission?
The data you are looking to compress is that sent over the wire via TDS. There is some minor compression here but nowhere near the type of compression you get with page/row compression, backup compression or ColumnStore compression.
It has been asked for before:
http://connect.microsoft.com/SQLServer/feedback/details/412131/enable-network-compression-compress-tds-stream
http://connect.microsoft.com/SQLServer/feedback/details/377479/wan-compression-option
The items are still open, so maybe there is some hope. There is no way to control this via the connection string that I've ever seen.
In the meantime there are some products that claim to do this, e.g.
http://www.nitrosphere.com/products/nitroaccelerator/
http://toonel.net/tcpany.htm
You can also potentially configure the network between your SQL Server and the application servers to support compression (and other things like encryption) but you are beyond my scope here, and I'm not sure if this would be supported by every single feature of SQL Server.
And to be honest, I'm not convinced this is the place you want to focus on optimizing. Compressing this stream might actually slow things down and outweigh the benefits of sending fewer bytes. I'd rather plunk the money down on better network connectivity between server and client(s) than to spend time investing in this type of work and testing whether it has any actual benefits - and not being able to do that until afterward. From from 10/100 to gig fiber has a known and predictable impact on network I/O.
I am not sure about the format of the bytes sent over the wire; you will have to set up some kind of packet sniffer for that (or maybe someone has already done that and will chime in).
As for the impact of compression, unless you are on Fusion-IO or other high-end SSD-type solutions, you are almost certainly I/O bound currently, and not CPU-bound. So as long as you have CPU overhead, you should see faster performance with compression enabled (but this won't change network performance, since the data is uncompressed before transmission). I say that knowing nothing about your servers, your application, your data or your usage patterns - you could very well have an edge case where compression actually hurts performance, or where the data just isn't a good candidate for good compression ratios.
Is data retrieved from Microsoft SQL Server compressed? If this is controlled by the connection string, is there any simple way to tell if any particular app is using it?
Technically, results can be compressed very slightly.
Tabular Data Stream (TDS) 7.3B—first supported by SQL Server 2008 R2—introduced something called null bitmap compression which allows rows containing multiple nulls to be transmitted using less bytes than are ordinarily required by null field values.
The server can intermix regular rows with null bitmap compressed rows at its choosing as it sends results. The client has no control over this so no relevant client-side configuration options are available.
Null bitmap is the only form of compression currently supported by TDS. If a row isn’t null bitmap compressed, it’s sent uncompressed.
As long as we're on the topic, I'm curious: is data transmitted in binary or ASCII?
Columns with non-text data types are transmitted using a binary format defined by the TDS protocol.
As mentioned elsewhere, to work around this issue you could consider setting up a VPN and enabling compression.
As others have said there is no compression built in to the SQL Server TDS Protocol. It's also worth saying that by default there is no encryption either. To enable encryption you must use certificates and specify it in the connection strings.
The easiest solution to solve both issues is to open up a VPN tunnel with encryption and compression enabled. Simple Microsoft PPTP solves both issues and is easy to setup.