After almost one hour or failed attempts, I understand that arguments are positional and should go in strict order. The supplied examples in this guide doesn't work.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
If options are required to be specified in a particular order, that would be a bug. Thanks for the report.
This has been fixed not to require prepending ? but using a different order is still crashing this command for version 2.0.63.
What shell are you using?
The & character in the SAS key needs to be escaped in PowerShell. Notice that anything after & gets treated as a separate command:
> az sql db export -g jaredmoo-may2019-restapi -s jaredmootest1 -n db1 -u myuser -p mypassword --storage-key 'sp=w&sv=2018-03-28&sr=b&se=2020-01-01T00%3A00%3A00Z&sig=xxxxxxxxxxxxxxxxxxxxxxx' --storage-key-type SharedAccessKey --storage-uri https://jaredmoostorage1.blob.core.windows.net/container1/myBacpac.bacpac
az sql db export: error: the following arguments are required: --storage-key-type, --storage-uri
usage: az sql db export [-h] [--verbose] [--debug]
[--output {none,yaml,table,tsv,jsonc,json}]
[--query JMESPATH] [--subscription _SUBSCRIPTION]
[--name DATABASE_NAME] --storage-key-type
{StorageAccessKey,SharedAccessKey} --storage-uri
STORAGE_URI --storage-key STORAGE_KEY
[--ids ID [ID ...]] --admin-user ADMINISTRATOR_LOGIN
[--auth-type {SQL,ADPassword}]
[--resource-group RESOURCE_GROUP_NAME]
--admin-password ADMINISTRATOR_LOGIN_PASSWORD
[--server SERVER_NAME]
'sv' is not recognized as an internal or external command,
operable program or batch file.
'sr' is not recognized as an internal or external command,
operable program or batch file.
'se' is not recognized as an internal or external command,
operable program or batch file.
'sig' is not recognized as an internal or external command,
operable program or batch file.
Try again with escaping and it works:
> az sql db export -g jaredmoo-may2019-restapi -s jaredmootest1 -n db1 -u myuser -p mypassword --storage-key 'sp=w"&"sv=2018-03-28"&"sr=b"&"se=2020-01-01T00%3A00%3A00Z"&"sig=xxxxxxxxxxxxxxxxxxxxxxx' --storage-key-type SharedAccessKey --storage-uri https://jaredmoostorage1.blob.core.windows.net/container1/myBacpac.bacpac
@jaredmoo is the perceived "argument ordering issue" a result of the bad escaping? If so, this issue can be closed.
Yes, at least when repro'd using PowerShell. It is very unintuitive escaping though, so I'm thinking about how to better document this and/or adjust the cmdlet design. Please leave the issue open.
I was trying this with powershell and cmd.exe. The bad escaping fixed the argument ordering but I'm not sure if the example is incorrect in another way. I had to request a SAS token with --permissions wr (not only 'w') or else it would fail with this error:
cli.azure.cli.core.util : Operation failed with status: 'Bad Request'. Details: There was an error that occurred during this operation : '
Error encountered during the service operation. ; Exception Microsoft.SqlServer.Management.Dac.Services.ServiceException:Unexpected exception encountered while retrieving metadata for blob 'https://ACCOUNT.blob.core.windows.net/CONTAINER/DBNAME.bacpac'.; Inner exception Microsoft.WindowsAzure.Storage.StorageException:The remote server returned an error: (403) Forbidden.; Inner exception System.Net.WebException:The remote server returned an error: (403) Forbidden.; '
Operation failed with status: 'Bad Request'. Details: There was an error that occurred during this operation : 'Error encountered during the service operation. ; Exception Microsoft.SqlServer.Management.Dac.Services.ServiceException:Unexpected exception encountered while retrieving metadata for blob 'https://ACCOUNT.blob.core.windows.net/CONTAINER/DBNAME.bacpac'.; Inner exception Microsoft.WindowsAzure.Storage.StorageException:The remote server returned an error: (403) Forbidden.; Inner exception System.Net.WebException:The remote server returned an error: (403) Forbidden.; '
Either way, fixing the escaping got me past "the following arguments are required".
Sounds like this is resolved.