[SA 7.2.338 Pro] - Connection issues with source code repo

[SA 7.2.338 Pro] - Connection issues with source code repo

I've got some issues with connecting to database with source code repository. I guess it is related to my other connection issues when names, IP or the rest were involved. There's a database on my machine that resides in SQL Server Express LocalDB. I can connect to it with SQL Editor but it seems that SQL Editor / SA are not capable to share their knowledge about the connection with the repository browser which is unable to connect to the same database.

Is there a workaround or a permanent solution?

I'm sorry I don't understand how that is possible. The repository browser and the editor share the same database connection.

How does the connection issue manifest itself?

EDIT: it does not seem to depend on localdb, it cannot retrieve code from other servers either. The DDL utility tries to connect to the server using their name and that's not working. It is using the name it has retrieved from the server not the one that had used to establish the connection.

I connect to the database then I open the Repository Browser. It connects to the database as well (the objects are visible at least). Then I try to refresh the contents of the workspace. This is the point where connection fails.
Check the screenshot below:

What kind of connectivity interface are you using ADO or ODBC?

I see something unusual in the connection reference. What's # 695795F5?

The connection interface is ODBC. SQL Express LocalDB does not support TCP/IP connections, it only works through named pipe (server name given as "(localdb)\v11.0"). That's the #number in the connection reference. It seems that LocalDB instance starts as soon as there's reference to it (trying to connect) and stops shortly after the last connection is closed, hence that number changes after closing SQL Editor (or simply closing all connections to it) and opening/connecting a few minutes later.

At first I thought named pipe was the cause but it couldn't retrieve code from TCP/IP connections either.

The Repository Browser is actually connected to the database, because the left side database tree is populated. It is the DDL scripting function that fails. That function indeed needs a separate connection which depends on SMO API.

Here is what I found out for this issue https://connect.microsoft.com/SQLServer/feedback/details/723737/smo-cant-connect-to-localdb-instances
You may need to install SQL Management Studio Express on your computer to get that working and/or apply .NET update 4.0.2 http://support.microsoft.com/kb/2544514

	SysOp wrote:
	You may need to install SQL Management Studio Express on your computer to get that working and/or apply .NET update 4.0.2 http://support.microsoft.com/kb/2544514

I've got SQL Management Studio installed (though not the Express one) so I decided to go the second option but when trying to apply the update I got an error message:

	Quote:
	KB2544514 does not apply, or is blocked by another condition on your computer.

	SysOp wrote:
	The Repository Browser is actually connected to the database, because the left side database tree is populated. It is the DDL scripting function that fails. That function indeed needs a separate connection which depends on SMO API.

That would explain why it won't work on a LocalDB instance but it doesn't work on other standard server installations either.

What do you get when running the following command

saDDL.exe -l -c "server name here" -u "login name here" -p "password here" -d "db name here" -s "schema name here" -o "table name here" -t table

Please substitute parameter values as required. If you use Windows authenticated connections, ommit u and -p parameters

I got what was expected. In case where the server was only accessible through IP option like -c "172.16.2.xx" worked (though it took very long time) but -c "LINESRV0yy" failed. Where I could ping the server using both IP and its name both options worked. The problem is that saDDL is always called using the server name regardless if that was used to establish the connection or not.

One old classics solution for dealing with name and IP mapping is to enter them into hosts file (see https://www.google.com/?gws_rd=ssl#q=windows+hosts+file). That is a simple one time change which would resolve issue of IP mapping by name.

Yes, that works, but requires regular updates to hosts file.