SSRP/SQL Browser Service

steffengy / tiberius

TDS 7.4 (mssql / Microsoft SQL Server) async driver for rust. Fork at: https://github.com/prisma/tiberius

Apache License 2.0

151 stars 2 forks source link

SSRP/SQL Browser Service #110

Closed wokket closed 4 years ago

wokket commented 4 years ago

Hi,

I started playing with Tiberius, but ran into issues connecting to a named instance. This was caused by a (previously unknown to me) behaviour where SQL named instances run on a random high port by default, and require a query to the SQL Server Browser Service (using SSRP over UDP) to get the actual connection information for a named instance.

I started looking into building a SSRP library, but was interested to know whether you saw this as:

something tiberius should handle (as a SQL client), or
something to be kept external to tiberius (as it's a TDS library).

Cheers,

steffengy commented 4 years ago

That's already implemented? https://github.com/steffengy/tiberius/blob/77042cc2ed2770f2b8dc0f85faafb6184ce7e5e3/tiberius/src/lib.rs#L610

steffengy commented 4 years ago

If you use a connection string, you need to use server=yourserver\instancename, as with the .NET implementation.

wokket commented 4 years ago

Hmmm, right you are!

I'm not sure how I both missed that code when I searched for it, or why I'm still having troubles but I'll keep digging as it's obviously my issue!

A side note: Is that instance name correctly NUL terminated in the SSRP message?

Thanks for getting back to me :+1:

steffengy commented 4 years ago

Whats the behavior you're observing? Is the SQL Browser service running?

wokket commented 4 years ago

I only have a SQL Express named instance running on this machine. I was totally unable to get the connect_to_named_instance test to pass, error was 'connection string pointing into the void.'. netstat -an showed both UDP 1434 and the high TCP port open.

I've reverted to the github codebase (having stepped all over the in-code conn strings/env vars) and it is now connecting fine.... typical.

I have a suspicion that something in the recent Insider/WSL2 builds is playing havoc with my local TCP connectivity, but it's just as likely a total SNAFU from me.