There is no Tables option in Azure Storage Account - azure

I have consulted the documentation for creating an Azure Storage Account and succeeded in doing so, but there is only the option for containers and not for Tables or any other option as the documentation said so.
This feature has been moved?
How do I create an Azure Storage Account with the tables option available?

Please check your storage account type, if it's a blob storage kind only or premium tier kind, then it's no table storage there.
Please make sure the storage account is General-Purpose V2 or V1 and standard tier, you can check it's type as per screenshot below:
And this link is the full list of the azure storage account type, you can see the table storage is supported from which type.

Related

Microsoft Purview - selecting sources type when registering

We have created Purview Collections based on Storage Accounts Types: Azure Blob Storage, Azure Data Lakes, Azure General Purpose v2. Our Collection names are:
Blob-Storage-Collection
Data-Lake-Collection
General-Purpose-v2-Collection
For each collection when we try to register a source of the above type, we get the following screen to select source type. For Blob Storage account, we select Azure Blob Storage (shown on top row of the image below), for our Data Lakes account, we select Azure Data Lake Gen2 (shown in third row of the image):
Question: For our General Purpose v2 storage account, which source type should we be selecting from the image below? We don't see a source type of General Purpose v2 to select from.
• The sources that you are trying to make a collection of are the types of various resource services available in the storage account, i.e., Blob storage, Data Lake Gen2, File share, etc. But the source type that you want to make a collection of is a type of storage account and not the inherent storage services that can be hosted on it. Thus accordingly, a collection of the source type for the type of storage account cannot be created in Microsoft Purview. In fact, if you check the available sources of purview collections in the Microsoft Purview portal, you can find out that they all are related to various azure resource providers registered in Azure, i.e., ‘Microsoft.DataLakeStore, Microsoft.DBforMySQL, etc.’. Thus, you can find sources according to the available resource providers in Azure for making a purview collection, not according to the type of that resource available.
For more information, kindly refer to the below documentation link: -
https://learn.microsoft.com/en-us/azure/purview/microsoft-purview-connector-overview

Blob storage compatibility with Azure Functions

I have some e-mail attachments being saved to Azure Blob.
I am now trying to write a Azure Functions App that would connect to that blob storage, run some scripts and re-save the file.
However, when selecting a storage account for the function, I couldn't select my blob storage account.
I went on the website and it said this:
When creating a function app, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. Some storage accounts don't support queues and tables. These accounts include blob-only storage accounts and Azure Premium Storage.
I'm wondering, is there any workaround this? and if not, perhaps any other suggestions? I'm becoming a little lost in all the options, and which one to actually choose.
Thanks!
EDIT: Might I add I writing the function Python
I think you are overlooking the fact that you can have multiple storage accounts. In order for an Azure Function to work you need a storage account. That storage account is used to store runtime information of the Azure Function for internal purposes like state management. This storage account is subject to restrictions as you already found out. There is no workaround for that.
However, if the function you are writing needs to access another storage account it is free to do so. You just have to provide details to connect to that specific storage account. In that case you also have a clear seperation between the storage account that is used by the azure function for its internal operations and the storage account your application needs to connect and which you have total control about withouth having to worry that you break things by deleting internal used blobs/tables/queues.
You can have a blob triggered function that gets triggered when changes occur on your specific blob storage. That doesn't need to be the storage account that the azure function internally uses, which is created/selected when creating the azure function.
Here is a sample that shows how to add a blob triggered azure function in Python. MyStorageAccountAppSetting refers to an app setting that holds the connection string to the storage account that you use for storage.
The snippet from the website you are quoting is for storing the function app code itself and any related modules. It does not pertain to what your function can access when the code of your function executes.
When your function executes it will need to use the Azure Blob Storage SDK/modules to connect to your blob storage account and read the email attachments. Here's a quickstart guide for using Azure Storage with Python: Quickstart with Azure Storage Blobs SDK for Python
General-purpose v2 storage accounts support the latest Azure Storage features and incorporate all of the functionality of general-purpose v1 and Blob storage accounts here
There are more integration options with GPv2 accounts including Azure Function Triggers. See: Azure Blob storage bindings for Azure Functions
Further refer: Types of storage accounts
If Blob, based on your need, you can choose an access tier based on the frequency of access for the data (e-mail attachments)Access tiers for Azure Blob Storage - hot, cool, and archive. If General purpose storage account, its standard performance tier.

Azure Media Services and existing Storage Account

Can Azure Media Services re-use an existing Storage Account, for example one we use for Table storage ? Or is this Storage Account dedicated only for AMS ?
Thanks !
You should be able to use an existing storage account as long as it's redundancy type is Locally Redundant, Geo-Redundant, or Read-only Access Geo-Redundant.

How are Azure BlobStorage type accounts different from StorageV2 accounts?

In my Azure subscription, I have used both Storage Accounts that are of the type BlobStorage and some that say Storage or StorageV2...
I know the difference that my BlobStorage types do NOT support Tables, Files, etc containers.
But, are there other differences that I should be aware of? Is StorageV2 any faster that Blob only storage?
General-purpose v2 storage accounts support the latest Azure Storage
features and incorporate all of the functionality of general-purpose
v1 and Blob storage accounts. General-purpose v2 accounts deliver the
lowest per-gigabyte capacity prices for Azure Storage, as well as
industry-competitive transaction prices.
From the description, the v2 General Storage account which takes the features of the blob storage accounts and combines then with the general storage account, plus tiering. And I think the most important to the custom is the price. Follow this link, there is an exmaple analysing the difference in price of the two type storages.
No real 'nuances', just feature differences as stated in document, new storage you want on V2, older storage you want to migrate to V2 if possible.
Example:
General-purpose V2
Blob Tier: Hot, Cool, Archive
Replication: LRS, ZRS4, GRS, RA-GRS
Resource Manager
General-purpose V1
Blob Tier:N/A
Replication: LRS, GRS, RA-GRS
Resource Manager, Classic
Hope this help.........

Azure storage account: general purpose vs blob storage

Having the need to store and access blobs which type of storage account is the most appropriate? Both types (general purpose and blob storage) seem to support blobs and in addition to this general purpose accounts allow selecting default or premium performance while blob storage accounts allow only default performance but on the other hand they also allow selecting the access tier (cool or hot).
In the end I find unclear what would be the best option.
A few differences between Blob and General Purpose Storage Accounts:
Blob storage account only support blobs while General purpose storage accounts support blobs, files, queues & tables (some exception apply - please see note about replication below). So if you ever need these additional services, you may want to choose general purpose accounts over blob accounts.
Blob storage account only supports block and append blobs while General purpose storage accounts support block, append & page blobs (some exception apply - please see note about replication below). So if you need to create virtual machines, you would want to choose general purpose accounts over blob accounts.
Blob storage accounts support both Hot and Cool access tier while General purpose storage accounts only support Hot access tier. So if you need to use Cool access tier i.e. use storage primarily for near-shore archiving, you would want to choose blob accounts over general purpose accounts.
You may want to be careful in choosing replication type in general purpose accounts as features offered varies by replication types.
LRS, GRS, RAGRS: Supports everything. Blobs (Block, Append, Page), Files, Queues & Tables.
ZRS: Supports only block blobs and nothing else.
Premium LRS: Supports only page blobs and nothing else.
Microsoft's guidance on this (as of 7/13/2018) recommends using General Purpose v2 (GPv2) Storage Accounts over Blob Storage accounts for two reasons I recently discovered (there might be more):
They offer more flexibility in terms of what you can store and do with them (Queues, Tables, Files and/or Blobs vs just Blobs). Ref: Microsoft Azure Documentation - Azure Storage account options
Microsoft recommends using general-purpose v2 storage accounts over Blob storage accounts for most scenarios.
There are more integration options with GPv2 accounts including Azure Function Triggers via Event Grid. Ref: Microsoft Azure Documentation - Azure Blob storage bindings for Azure Functions
Blob-only storage accounts are supported for blob input and output bindings but not for blob triggers. Blob storage triggers require a general-purpose storage account.

Resources