通过SSMS使用Azure本地开发存储（SQL Server Management Studio）

Question

I am trying to write code to access my azure local development storage. I started off by creating a new storage for myself:

dsInit /forceCreate

I can now see the DevelopmentStorageDb20090919 in SSMS with some precreated tables such as dbo.TableContainer, dbo.TableRow etc.

1. Now, can I simply add tables to this database via SSMS (ex. Employee table) and start accessing them via code ? Is this the right way to do stuff ?

For example:

    var svc = CloudStorageAccount.DevelopmentStorageAccount
.CreateCloudTableClient().GetDataServiceContext();

                //"Employees" is the name of the table                
                svc.AddObject("Employees", new Employees("John Doe"));    
                svc.SaveChangesWithRetries();

2 . And additionally, once I am all done, how do I port the table and the data into the actual cloud account ? By running scripts there ?

Answer 1

I think you're confusing Azure Table Storage with SQL Server or SQL Azure, which are completely different. You cannot access Azure Storage tables at all with SSMS. The code sample you provided is using the Azure SDK (which is using the Storage REST API underneath). That's the only way to access Azure Storage.

If you want to create / view tables in a more graphical way, try Cerebrata's Cloud Storage Studio , ClumsyLeaf's AzureXplorer , David Pallman's Azure Storage Explorer , or some other similar tool. These tools all rely on the SDK or direct API calls.

Now, regarding your code: You need to create your table before inserting objects. See CreateTablesFromModel() and CreateTableIfNotExist(). The Azure Platform Training Kit has a great intro/lab for creating and using tables, and shows how to use CreateTablesFromModel().

Answer 2

As long as that table exists, then yes, the code you have written will add "John Doe" to the employees table. While it can be interesting to look at data through SSMS and you could try altering data that way, I wouldn't recommend trying it. Development storage is funny enough without poking it with a stick. There are differences between dev storage and actual cloud storage, so I have found that the sooner you can stop using dev storage the better.

At the moment there is no fancy way of transferring data between Azure tables (be they in dev storage or in the cloud). It boils down to running a query that selects everything from the source table, then writes each individual item to the destination table. Depending on how your data is partitioned you might be able to batch the writes or you might be able to do them in parallel. If you're willing to use the REST API directly you could avoid the storage library having to deserialise each item before it's written.

Answer 3

Even though it's best to use the APIs to talk to the DevStorage, there might be scenarios where the direct database access could prove beneficial. More specifically, it can be used to circumvent some SDK issues that are specific to DevStorage.

I once ran into a problem with renaming of large blobs - the operation would simply time out (note that blobs cannot be renamed - they first need to be copied using CopyFromBlob() and then deleted). I tried both in Azure Storage Explorer and by writing code and increasing all the timeouts. Solution? SQL to the rescue!

Here is an example of SQL that would rename a blob within a container or move it to a different one:

begin tran

alter table CommittedBlock nocheck constraint BlockBlob_CommittedBlock

update CommittedBlock set BlobName = @TargetBlobName, ContainerName = @TargetContainerName where BlobName = @SourceBlobName and ContainerName = @SourceContainerName
update BlockData set BlobName = @TargetBlobName, ContainerName = @TargetContainerName where BlobName = @SourceBlobName and ContainerName = @SourceContainerName
update Blob set BlobName = @TargetBlobName, ContainerName = @TargetContainerName where BlobName = @SourceBlobName and ContainerName = @SourceContainerName

alter table CommittedBlock with check check constraint BlockBlob_CommittedBlock

rollback tran

Of course, use it at your own risk - this is a completely unsupported way of working with dev stotage.