mssql: Error connecting to SQL Express using instance name

[olsen232]

Describe the bug
Attempting to connect to sql express using an instance name eg:
kart create-workingcopy mssql://localhost\SQLEXPRESS/master/example
Fails with a string of database error where the following line is the initial culprit:
Invalid connection string attribute (0)

To Reproduce
Steps to reproduce the behaviour:

1. Install SQL Express
2. Verify that you can connect to it using sqlcmd eg: sqlcmd -S localhost\SQLEXPRESS -d master
3. Try to connect to the same database using Kart eg kart create-workingcopy mssql://localhost\SQLEXPRESS/master/example
4. See the error message: Invalid connection string attribute (0)

Expected behaviour
This should work because, sqlalchemy + pyodbc supports it, and Kart uses sqlalchemy + pyodbc.

However:
Kart automatically resolves any mention of localhost in database-spec to an IP address, eg:
kart create-workingcopy mssql://localhost\SQLEXPRESS/master/example actually becomes ``kart create-workingcopy mssql://127.0.0.1\SQLEXPRESS/master/example` or similar.
The comment next to this indicates that the pyodbc mssql driver prefers this (ie, in some circumstances wouldn't connect to localhost but it would connect to 127.0.0.1)
However, in this case, the opposite is true: localhost\SQLEXPRESS is a resolvable instance name, but 127.0.0.1\SQLEXPRESS is not.
The fix will be to remove this automatic resolution, and instead just go with the underlying driver's behaviour, which will allow Kart to connect to SQL express using instance names.

I've gone looking to see if I can find a case where the mssql driver understands 127.0.0.1 but not localhost. I can't find it now, so perhaps it was alleviated by upgrading the MSSQL driver or pyodbc.

If you arrive at this bug because Kart can no longer connect to your MSSQL working copy after upgrading Kart, try editing the working copy location stored in .kart/config - see if localhost or 127.0.0.1 is preferred. After each edit run kart status to see if it successfully connects to the working copy. In my experiments, both should work, but this wasn't always the case and your mileage may vary.

**Version Info **

• OS: Windows Server 2019
• Version: Kart 0.15.2

[pfw]

A drive by comment… localhost vs 127.0.0.1 could just be an IPV4 vs IPV6 issue, node has a related behavior when localhost returns an IPV6 address first, eg. Not listening on ipv4 could cause 127.0.0.1 fail. Localhost can fail if not listening on ipv6.