New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
az sql db delete does nothing #7285
Comments
Are you able to see the database with |
No. output is...
|
I see. The most likely cause of this problem is that the Azure Resource Manager API that CLI is using has a cache of resources such as servers and databases, if you create a database using other entry points such as the old Service Management API or T-SQL We can mitigate this issue if you contact support, but there is also a self-mitigation possible: you can use Sorry you were impacted by this issue. |
Hi Jared, thanks for the detail. To give you a complete picture - during build we create the database using TSQL (which is sent via the npm With the info you have provided i am going to modify it to create the database with the CLI first and see if that mitigates the issue. Will report back. |
I got this working by removing the fully qualified domain name from the i discovered this by trying your suggestion of Maybe there are some inconsistencies behind the CLI around this server name, and using FQDN |
Oh, that would also explain the problem. There is no inconsistency - an Azure SQL server's name and FQDN are not the same thing. Azure CLI and Azure PowerShell always use the server's name (e.g. |
Describe the bug
executing
az sql db delete --name mydb --resource-group mygroup --server myserver --yes
returns and does nothing. The database remains active.To Reproduce
At the command line run
az sql db delete --name mydb --resource-group mygroup --server myserver --yes
. The behaviour is the same when you omit the confirmation parameter--yes
and when you include the--no-wait
option also.Expected behavior
The SQL database should be deleted.
Environment summary
azure-cli (2.0.41)
MacOS
Same behaviour is reproduced when running in VSTS Azure CLI Task
Additional context
none.
The text was updated successfully, but these errors were encountered: