Azure / azure-powershell

Microsoft Azure PowerShell
Other
4.22k stars 3.82k forks source link

Provide more reference material (cmdlet, documentation) on MaxSizeBytes property #15958

Open ojintoad opened 3 years ago

ojintoad commented 3 years ago

Description of the new feature

AFAICT there is no clear algorithm that indicates what values are allow for MaxSizeBytes on most Az.Sql single database manipulating commandlets or AzureRM apis.

In reviewing:

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=azuresqldb-current&preserve-view=true&tabs=sqlpool

and

https://docs.microsoft.com/en-us/rest/api/sql/2020-11-01-preview/databases/create-or-update

and

https://docs.microsoft.com/en-us/powershell/module/az.sql/new-azsqldatabase?view=azps-6.4.0

I don't see any formula to get valid values for the MaxSizeBytes property other than:

There used to be a MaxSizeGB but that was removed - I'm also not sure that would help in all cases.

There is some evidence Microsoft has had some challenges keeping this in order on their end based on documentation that became invalid:

https://github.com/MicrosoftDocs/azure-docs/issues/66298

Let me know if I can provide more info, I have searched across many forums and even asked on the PowerShell Discord/Slack Azure channel for advice (still waiting to receive an answer there).

Proposed implementation details (optional)

I think documentation is reasonable - if you prefer to migrate this to MicrosoftDocs or tell me to open an issue there, that's fine by me. However, if there was some way to also have the values assignable in portal be translatable via cmdlet that could be run from powershell, that'd also be great. That or an API call? I'm open to anything. I'm even open to just having an explanation here.

ojintoad commented 3 years ago

I think this may be as simple as documenting that all values are done in GB and using powershell values works so long as you use GBs or MBs. TB doesn't seem to.

C:\Users\ojint
> 1250GB
1342177280000

1342177280000 is a correct value for the api.

There might be more guidance needed than that, but that seems to work for me currently.

ghost commented 2 years ago

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @azureSQLGitHub.

Issue Details
## Description of the new feature AFAICT there is no clear algorithm that indicates what values are allow for MaxSizeBytes on most Az.Sql single database manipulating commandlets or AzureRM apis. In reviewing: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=azuresqldb-current&preserve-view=true&tabs=sqlpool and https://docs.microsoft.com/en-us/rest/api/sql/2020-11-01-preview/databases/create-or-update and https://docs.microsoft.com/en-us/powershell/module/az.sql/new-azsqldatabase?view=azps-6.4.0 I don't see any formula to get valid values for the MaxSizeBytes property other than: * Deploy using portal * Export template and observe maxsizebytes * Use that maxsizebytes There used to be a MaxSizeGB but that was removed - I'm also not sure that would help in all cases. There is some evidence Microsoft has had some challenges keeping this in order on their end based on documentation that became invalid: https://github.com/MicrosoftDocs/azure-docs/issues/66298 Let me know if I can provide more info, I have searched across many forums and even asked on the PowerShell Discord/Slack Azure channel for advice (still waiting to receive an answer there). ## Proposed implementation details (optional) I think documentation is reasonable - if you prefer to migrate this to MicrosoftDocs or tell me to open an issue there, that's fine by me. However, if there was some way to also have the values assignable in portal be translatable via cmdlet that could be run from powershell, that'd also be great. That or an API call? I'm open to anything. I'm even open to just having an explanation here.
Author: ojintoad
Assignees: -
Labels: `feature-request`, `Doc - Reference`, `SQL - Managed Instance`, `Service Attention`, `question`, `customer-reported`
Milestone: -