This post has been republished via RSS; it originally appeared at: Azure Database Support Blog articles.
Recently I came to a support issue where we tried to use REST API to list SQL resources on an Azure subscription. The output returned results, but it did not show any of the SQL resources that we expected to see. Filtering the result with a GREP only brought up a storage account that had "SQL" in its name, but none of the servers or databases.
These are the commands that were used:
The Azure portal showed the full list of Azure SQL servers and databases, for either drilling down through the subscription or going directly to the "SQL servers" or "SQL databases" blades. Commands like az sql db list or az sql server list also returned all SQL resources. Permission issues were excluded by using an owner account for subscription and resources. And it turned out that only one specific subscription was affected, whereas it worked fine for all other subscription.
Some list operations divide the result into separate pages when too much data is returned and the results are too large to return in one response. A typical size limit is when the list operation returns more than 1,000 items.
In this specific case, the subscription contained so many resources that the SQL resources didn't make it onto the first result page. It required using the URL provided by the nextLink property to switch to the second page of the resultset.
When using list operations, a best practice is to check the nextLink property on the response. When nextLink isn't present in the results, the returned results are complete. When nextLink contains a URL, the returned results are just part of the total result set. You need to skip through the pages until you either find the resource you are looking for, or have reached the last page.
The response with a nextLink field looks like this:
This URL can be used in the "-u" parameter (or --uri/--url) of the REST client, e.g. in the az rest command.