引发了类型为“Microsoft.WindowsAzure.StorageClient.StorageClientException”的异常

引发了类型为“Microsoft.WindowsAzure.StorageClient.StorageClientException”的异常

有时，即使我们运行了fabric并且角色管理器启动了，我们也会遇到这种例外情况

代码在第行中断：

 emailAddressClient.CreateTableIfNotExist("EmailAddress");

---

简单的解决方法是将EmailAddress更改为EmailAddress。出于某些原因，它不允许使用骆驼套。因此，请确保在表的名称中也有一个大写字母。由于表名不区分大小写，您也可以将其命名为“emailaddress”

我一直为Windows Azure表提供大小写名称，没有任何问题

---

我想知道您是否碰巧已经使用了这个表名，并且最近删除了它？在删除后的一段时间内，当表仍在异步删除时，您将无法重新创建它。我相信409冲突是这种情况下的错误代码。

我同意史蒂夫·马克思的观点，外壳似乎不会影响这个问题。事实上，微软的Azure诊断表是用不寻常的大小写创建的，例如：WADPerformanceCounters。即使在开发环境中，我也会遇到这个问题。所以这完全是另一回事——我的观点

在我的案例中修复了错误：问题是webrole或workerrole项目属性中定义的连接字符串出现错误或缺少连接字符串。 修正： 右键单击云应用程序中“角色”文件夹下的webrole。从关联菜单中选择属性。 选择“设置”选项卡。 验证或添加用于初始化表存储的连接字符串的设置

---

我的是一个简单的错误-没有设置我的连接字符串。

没有。在使用存储资源管理器删除表名后，我重新创建了该问题。同样的问题和同样的答案。您使用的SDK版本是什么？不管怎么说，这对我来说很有效，我在博客上写道，因为例外情况是误导性的。是的，但问题是删除是否及时完成。如果你看一下通过运行Fiddler最容易实现的异常的细节，我猜你会看到真正的错误是什么。这是我博客文章的一部分，第一个异常发生在这里，修复后会导致另一个异常。Delete实际上已经完成了，正如我说的，我使用了存储资源管理器，所以如果它没有被删除，它怎么可能不返回表呢。它显示为已删除。然而，我明白问题是什么——我忘了把这个问题与另一个问题相连的博客链接放在一起。读了这篇博文，博文声称骆驼壳就是问题所在。我一直往后推，因为我不希望这个问题的未来读者被误导。表删除是异步的。。。它将立即显示为已删除，但如果在删除完成之前尝试重新创建它，则会发生冲突。驼峰大小写不是问题所在。你匆忙中得出了错误的结论。

public EmailAddressDataContext(CloudStorageAccount account) :
            base(account.TableEndpoint.AbsoluteUri, account.Credentials)
{
   this.storageAccount = account;

   CloudTableClient emailAddressClient =
                new CloudTableClient(storageAccount.TableEndpoint.AbsoluteUri, 
                                     storageAccount.Credentials);
   emailAddressClient.CreateTableIfNotExist("EmailAddress");
}