Home » Microsoft Technologies

TableServiceContext query Uri is different when generated from Web Role in Dev Fabric vs. Azure

We have a LINQ query on the Partion and Rowkey against an Azure table storage instance that is generated differently when the web role is running in the dev fabric versus the Azure fabric. The query Uri (determined by calling ToString() on the IQueryable that is generated from the LINQ query) is generated as a filter when the web role is running on a dev machine and not in the fabric.

Dev Fabric Uri:

https://foo.table.core.windows.net/Bars()?$filter=(RowKey eq 'a1@gmail.com') and (PartitionKey eq '41e0c1ae-e74d-458e-8a93-d2972d9ea53c')

Azure Fabric Uri:


I believe this is causing the well known ResourceNotFound errors when methods like FirstOrDefault are called. We know the ways to handle this.

My question is why is the Uri generated differently when generated in a dev web role versus an Azure web role?

Here is some code that is similar to what was used to generate the Uri's in both cases.

TableServiceContext context = new TableServiceContext();

var qry = context.Somethings.Where(m => m.RowKey == Username && m.PartitionKey == ProjectID);


if (qry.FirstOrDefault() == null) {
  // ^ This statement generates an error when the web role is running
  // in the fabric


2 Answers Found


Answer 1

I think this is the same question I answered a bit ago on StackOverflow.  Check the answer there (http://stackoverflow.com/questions/3340448/determine-request-uri-from-wcf-data-services-linq-query-for-firstordefault-agains/3340755#3340755), copied here for everyone else's benefit:


See http://blogs.msdn.com/b/windowsazurestorage/archive/2010/07/26/how-wcf-data-service-changes-in-os-1-4-affects-windows-azure-table-clients.aspx.

Specifically, it used to be the case (in previous Guest OS builds) that if you wrote the query as you did (with the RowKey predicate before the PartitionKey predicate), it resulted in a filter query (while the reverse, PartitionKey preceding RowKey) resulted in the kind of query that raises an exception if the result set is empty.

I think the right fix for you (as indicated in the above blog post) is to set the IgnoreResourceNotFoundException to true on your context.


Answer 2

Thanks Steve. It was the same question (tweaked for here) and you provided the right answer. I have also update my original question on Stackoverflow to include the findings: http://stackoverflow.com/questions/3340448/determine-request-uri-from-wcf-data-services-linq-query-for-firstordefault-agains .


<< Previous      Next >>

Microsoft   |   Windows   |   Visual Studio   |   Sharepoint   |   Azure