Does anyone use the `@pulumiverse/mssql` provider ...
# general
l
Does anyone use the
@pulumiverse/mssql
provider or recommend any other provider for managing logins and users in SQL server (specifically, RDS)? We're having a fair few issues getting it to work long-term. Right now, we're having problems refresh and/or updating old projects. This is the error message:
error: Failed to retrieve SQL login settings: sql: no rows in result set
We can access the server and view the login using the same DB credentials as Pulumi is using, so we're confused by this.
pulumi destroy
fails with
error: Failed to resolve user name: sql: Scan error on column index 0, name "": converting NULL to string is unsupported
Which means right now we have to recover from all this manually. Delete the stack and resources by hand.
Forgot to ask a question 🙂 Is anyone else getting updates or refreshes of SQL server logins (and/or users) to work, and if so, how?
m
Hey, I am not particularly familiar with the provider in question but was able to track down the underlying source code where that error message is generated. To successfully load the SQL settings the DB credentials must be able to read from the
sys.sql_logins
and
sys.databases
tables. I suggest you verify that the credentials have the correct permissions set up. If you're still having issues, perhaps you can share a code snippet of how you are using the provider.
l
Thanks for looking into it. We're running this project, which only sets up logins and uses, as the DB admin user created by AWS at the time the RDS instance is created. I presume it's not possible to grant it extra permissions.
I'll try selecting from those tables manually, but if that doesn't work, then I guess this provider isn't compatible with RDS.
Though since it creates the logins and users fine, it seems a bit odd that it wouldn't be able to read them.
Those two selects both worked fine. Credentials verified, I guess?
sharedResources is the stack resources object pointing at the stack that created the RDS instance. Outputs have been checked.
m
If you wouldn't mind humoring me what happens if you try this?
Copy code
export const loginInfo = mssql.getSqlLogin({name: userName}, {provider: mssqlProvider});
Is it able to read the existing login info like this? Or does that have a similar error?
l
Might take a while to get around to this, sorry. Working on something else right now. Hopefully I'll have it pasted here before your morning.
The call to getSqlLogin worked fine. However we can't currently read anything into this, because we've completed the manual recovery, and the logins aren't really old any more 🙂 The logins actually haven't changed, but we've deleted all the user mappings and users, created the users, and deleted an old offline database. Somewhere in there, something got cleaned up and is now working. I anticipate this problem resurfacing in the future. Unless, of course, we can upgrade away from SQLServer before it strikes again...