Named connections get overwritten in ADS

[sergten]

Wnen I connect to a server (SQL Server or Oracle, doesn’t matter) with the same server name and same login name, but give it different names – then the first connection gets overwritten by the second one.

Example:

1. Create the first connection:

2. Watch it appear in the list of Servers:

3. Create the second connection with the same server and username:

4. Upon connection, watch the first connection replaced by the second one:

The example above uses an Oracle connection type, but same behavior can be observed for SQL Server connections.

It appears that the name (marked as optional) doesn’t make it into the connection identification.

[alanrenmsft]

Hi @sergten I think this is by design, you have to make sure the name is unique or empty, otherwise it will be overwritten. please let us know if you have any questions.

[Charles-Gagnon]

This doesn't seem like behavior we want - the bug @sergten is describing is that we are essentially ignoring the name when saving connections. So despite them being given unique names the new one (which should be unique because it was given a unique name) it's overwriting the original one.

We should allow having multiple connections that share connection information as long as the Name given is unique.

[alanrenmsft]

sorry, Overlooked the description, the names used are actually different.

[cheenamalhotra]

This request will require significant changes to the way connection profile identity is created. We tried the change in PR https://github.com/microsoft/azuredatastudio/pull/20534 and noticed breaking changes that would affect existing connection passwords, since connection identity URL will be impacted. I'd like to re-valuate how is this is a useful request from practical point of view?

@sergten Can you elaborate why this would be a useful feature for an end user? Why would you want to create multiple connections with differing names for the same server/db connection?

[sergten]

Namely for transaction management. I may have uncommitted changes in one connection that I don't want to see from another - that was my main use case. I can think of other use cases, such as for SQL Server I can have a DAC connection, for Oracle - SYSDBA.

[sergten]

But not critical, feel free to de-prioritize.

[cheenamalhotra]

Fyi, you don't need a new connection in server tree to not view uncommitted results btw, since every new query opens a different new connection with database underneath.

If you want to query uncommitted data, just open a new query window from the same server tree connection, and that should work for you!

[sergten]

I know. I was mocking with Oracle, whose provider doesn't allow running arbitrary scripts, so I was messing with the tree itself. Like I said - not critical. It's just mathematically incorrect to give a connection a name and watch it being applied to something else.

[artemsaveliev]

To us the usefulness is in running multiple mysql connections. In ms sql, port number is/can be part of server name. Not so in mysql - so when trying to run multiple containers with mysql running, it's not possible to store several connections.

Only possible workaround (when using localhost) is to start using multiple loopback addresses (127.0.0.1, 2, 3 etc) to disambiguate the ports.

[cheenamalhotra]

Hi @artemsaveliev

We're considering fixing this behavior in upcoming release. Similar issue we're tracking: #17438

[cheenamalhotra]

We're almost ready, moving milestone to May to add additional time to test with the insiders build.

[cheenamalhotra]

Support is now available in latest insiders with https://github.com/microsoft/azuredatastudio/pull/22735 merged, closing as resolved.

[cheenamalhotra]

Reopening as the PR was reverted, will be targeted for next release.

[cheenamalhotra]

The support is now available in latest insiders, and will be available in next release.

Oracle and other providers don't yet support the new design, but will be able to adopt this feature as needed. Contribution points are updated.