Found this link tonight and don’t want to loose it: http://code.msdn.microsoft.com/KB2006191

It is the updated ASP.NET scripts for use with SQL Azure … though Session is not supported – so not in those scripts.

Just updated the source code (not a download package) with change set 43982.

The checkin was to make the project work with Azure Storage Client Extensions.  It isn’t quite complete yet, but most of the functionality is there.  Currently the Default2.aspx only supports the output to grid option … sorry I haven’t had time to finish the file export. 

NOTE: Default.aspx is the same code as before – only Default2.aspx uses the Azure Storage Extensions.

The good news is, almost all of the queries in the Query samples file work.  In order for those queries to work you’ll need to get the code up and running for Azure Storage Client Extensions first (which doesn’t take too long).

So now you can do things like (all thanks to Azure Storage Client Extensions):

Projections (and orderby)

Joins

Some additional Linq operators, like First() and FirstOrDefault()

There are still a few bugs in the code, but over all it works good enough to do some general querying of you Azure tables.

I’m working on combining the Azure Storage Client Extensions functionality into Azure Table Query.  This will add the ability to create projections, do joins on tables, ordering results and a couple of other things.  Below is a screen shot of one of the projection queries joining two tables together:

Today I moved my new pet project out to CodePlex: Azure Table Query

This project is a result of me wanting to run ad hoc LINQ queries against Azure table storage.  Last week I wrote about How To: Query Azure Log Tables with LINQPad – but that requires a separate assembly to contain the entities and context classes.  This week I’ve taken it a step further … starting with the work I did on the Query Editor in  PowerCommands for Reflector.  The Azure Table Query is a similar tool for Azure table storage but is implemented as a Web Role project.

Besides giving you the ability to run ad hoc queries against table storage, you can also export your table entities as a compressed serialized xml file.  You do this by creating the query you want exported then choose the output type you want from the drop down.

The project is still in its early stages, but here is a list of some features and limitations.

Current features

• Ability to get the list of tables in a configured Azure table storage account
• Ability to see properties of an entity (if there are entities in the table)
• Ability to execute ad hoc LINQ queries against (a single table in) Azure table storage
• Query output is a grid by default
• Optional output currently includes Xml serialized objects (either a normal xml file or a compressed xml file)

Current limitations

• The table storage account is configured as a setting of cloud service (which means you can’t change it on the fly)
• Only able to use a single table in a query
• The LINQ syntax is limited to the same subset of operators currently supported by Azure table storage
• No security … meaning if someone finds this page they will be able to query your table storage and export the data
• UI could be improved

The download and information on how to use it are on the project’s site: Azure Table Query

Code Download: AzureLogsWithLINQPad.zip

Recently there have been some questions in the Windows Azure Forum about retrieving information from the Azure log tables, which have made me think it would be nice to just run a quick query against Azure table storage. 

Normally I use the Azure Storage Explorer (or sometimes the TableBrowser site) to view data in Azure table storage … however the filtering functionality is still a little limited with those tools.  And in the past I’ve looked at LINQPad but hadn’t taken the time to figure out how to use it with Azure table storage until today.

LINQPad (http://www.linqpad.net/) is a great utility for executing LINQ queries against a data source.  With LINQPad, you can use things like LINQ to Objects, LINQ to SQL and several other LINQ oriented ways to query a data source … but to use it with Azure table storage you need to do a little work which Jamie Thomson wrote up in July 2009.  His blog entry describes how hookup Azure table storage to LINQPad: LINQPad and Azure.  Please check his entry out for a background on what the rest of this entry is about … I’m basically just updating his.

What I want to do, is use LINQPad to query the log tables generated by Windows Azure.  When Windows Azure is populating the different diagnostic logs, some are transferred to tables (others go to blobs).

Here is a list of the tables Windows Azure creates and what is in them:

In order to have all the DataContext classes available for querying these log tables, I put together a small solution which contains the entities and data context classes.  The link for the download is at the beginning of this entry.

Once you have the AzureLogs solution compiled, getting LINQPad setup to make queries to these tables is pretty close to what Jamie outlined in his blog entry, but I’ll update the steps here (for the Nov 2009 release).

Step 1: Add the additional references

• In LINQPad, go to the Query menu | Advanced Query Properties
• Add the AzureLogs.dll
• Add the Microsoft.WindowsAzure.Diagnostics.dll and the Microsoft.WindowsAzure.StorageClient.dll (if you compile the source included in the download, these will be in the bin\debug directory after you compile)
• Add the System.Data.Services.Client.dll

Step 2: Add the additional namespace imports

• Add the additional namespaces shown in the image below

Step 3: Set the language

• In order to run multiple statements in LINQPad (which you’ll want to do), you need to change the Language to C# Statement(s).

Step 4: Write the query and Run it

If you open the query included with the download (WindowsAzureLogsQuery.linq), it will save you some time – you’ll just need to do the following then uncomment and edit the queries already started for you.

By default the WindowsAzureLogsQuery.linq is using the local storage account.

To point at a different storage account:

• Edit the accountName and the sharedKey to your storage account settings
• Uncomment the “var account” lines that uses those
• Comment out the line that sets the account variable to the development storage