In implementing sqlcmd open ads for Mac, we've hit an issue, in that the name of the credential that ADS is expecting (via SqlToolsService) is named using UTF16 characters (the internal representation for strings in .Net (C#)), but all the KeyChain packages for golang correctly take a string parameter for the credential name, which is UTF8, which means there is no way using golang keychain packages to name a credential using UTF16 characters. But naming the credential with UTF16 characters is incorrect anyway, is causes all sorts of problems in the Mac Keychain UI
The following bugs have already been filed in ADS, SqlToolsService:
When we have solved the UTF16 issue, there is another issue in that SqlToolsService ACLs the credential to just the SqlToolsService process, I'm not sure how sqlcmd will be able to do this (since sqlcmd won't necessary know where the SqlToolsService is)
As a temporary workaround, rather than trying to clone the UTF16 bug in ADS, we are going to require the user run a sqlcmd config cs to get the password from the sqlconfig to the console, and then cut and paste it into ADS the one time (and save password). We have an effort going on to work out the correct path forward to solve this.
In implementing
sqlcmd open adsfor Mac, we've hit an issue, in that the name of the credential that ADS is expecting (via SqlToolsService) is named using UTF16 characters (the internal representation for strings in .Net (C#)), but all the KeyChain packages for golang correctly take a string parameter for the credential name, which is UTF8, which means there is no way using golang keychain packages to name a credential using UTF16 characters. But naming the credential with UTF16 characters is incorrect anyway, is causes all sorts of problems in the Mac Keychain UIThe following bugs have already been filed in ADS, SqlToolsService:
https://github.com/microsoft/azuredatastudio/issues/22385 https://github.com/microsoft/azuredatastudio/issues/19269
When we have solved the UTF16 issue, there is another issue in that SqlToolsService ACLs the credential to just the SqlToolsService process, I'm not sure how sqlcmd will be able to do this (since sqlcmd won't necessary know where the SqlToolsService is)
As a temporary workaround, rather than trying to clone the UTF16 bug in ADS, we are going to require the user run a
sqlcmd config csto get the password from the sqlconfig to the console, and then cut and paste it into ADS the one time (and save password). We have an effort going on to work out the correct path forward to solve this.