Cannot create database ‘DevelopmentStorageDb20110816′ for the Windows Azure Storage Emulator

January 25, 2012, 11:37 am

Have you seen this error before? If you’ve spent any time with the Windows Azure storage emulator it’s highly probable. Here’s the full text:

    Added reservation for 127.0.0.1:10000/ in user account COMPUTER\User.
    Added reservation for 127.0.0.1:10001/ in user account COMPUTER\User.
    Added reservation for 127.0.0.1:10002/ in user account COMPUTER\User.

    Creating database DevelopmentStorageDb20110816...
    Cannot create database 'DevelopmentStorageDb20110816' : CREATE DATABASE permission
    denied in database 'master'.

    One or more initialization actions have failed. Resolve these errors before attempting
    to run the storage emulator again. These errors can occur if SQL Server was installed
    by someone other than the current user. Please refer to
    go.microsoft.com/fwlink/?LinkID=205140 for more details.

And an image of the error:

spacer

This error can occur when running the storage emulator (or running DSINIT.exe) for the first time. The compute emulator needs to initialize itself, which includes creating a local SQL Server database that is used to store data for local Windows Azure storage. The above error indicates that there’s a permissions when trying to create the database.

There are a number of ways to resolve this issue and, like others, I have my favorite approach. I have a script that I run which will add the executing user to the SQL Server sysadmin role.

I’ve published the entire script here: https://gist.github.com/1677788. Simply download and unzip the file. Open up an elevated command prompt and execute the file (i.e. run addselftosqlsysadmin.cmd). Once the script is executed the user can successfully initialize the storage emulator.

I hope this helps!

Category: Scripts, Storage Emulator, Windows Azure, Windows Azure Storage  |  1 Comment

Are You Building Mobile + Cloud Applications? Tell Me!

January 9, 2012, 12:02 pm

spacer If you follow my blog or on Twitter then you know that I’m passionate about using services running in Windows Azure to power mobile applications. To effectively run mobile services for mobile apps you need a platform that is responsive to a global audience and able to scale to the needs of your user base – Windows Azure provides these capabilities.

As part of the refresh of the WindowsAzure.com we have also provided additional information about mobile scenarios – it’s worth taking a look.

We’ve built a lot of resources that you should take a look at, including: the Windows Azure Toolkit for iOS, the Windows Azure Toolkit for Android, the Windows Azure Toolkit for Windows Phone, and a host of NuGet packages for Windows Phone and Windows Azure. All of these resources include native libraries (e.g. Objective-C for iOS and .NET for Windows Phone), sample applications, documentation, and tools. We also have a lot of videos and guides available to make the process of getting started as easy as possible.

How can you help?

One of my primary goals in 2012 is to continue to find and build compelling mobile applications that benefit from Windows Azure. We already have few great stories (see T-Mobile USA, Red Badger, easyJet, and more) but that’s only scratching the surface – we can do a lot more!

So, I have a few questions of you:

  • Are you building mobile applications that use services in Windows Azure?
  • Are you looking for additional PR and opportunities to highlight your applications?
  • Have you tried any of the toolkits or NuGet packages?
  • Do you have feedback for me regarding the use of the toolkits or NuGet packages?
  • What should we do that we aren’t today?
  • Do you have an application released to a marketplace – either Windows Phone, Apple, or Android – that uses Windows Azure?

If you have any feedback to these questions then please contact me at wade.wegner@microsoft.com. I want to hear from you!

Let’s see what we can accomplish together!

Category: Android, iOS, Windows Azure, Windows Phone  |  Comment

How to Handle a Faulted Channel with the Windows Azure Service Bus

December 12, 2011, 9:52 pm

Recently I wrote a WCF service that fronted an on-premises SQL Server database for an MVC application running in a Window Azure Web Role. There are a number of ways I could have approached this scenario; I decided to use the netTcpRelayBinding via the Windows Azure Service Bus for the following reasons:

  • I needed optimal performance (i.e. TCP over HTTP).
  • I wanted to reuse existing connections (rather than opening many connections).
  • I didn’t want to open up ports in my firewall (inbound or outbound).

Based on these requirements, the Service Bus is almost a no brainer. The Service Bus provides both messaging and connectivity capabilities, the latter of which provide a nice way to build loosely coupled applications in hybrid scenarios (i.e. cloud + on-premises).

I dove right in and wrote the following code:

public static IEnumerable<Customer> GetCustomers()
{
    Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb",
        "MYSERVICENAMESPACE", "Customer");
    var customersChannelFactory = new ChannelFactory<ICustomerChannel>(
        "RelayEndpoint", new EndpointAddress(serviceUri));
    var customersChannel = customersChannelFactory.CreateChannel();
    customersChannel.Open();

    return customersChannel.GetCustomers();
}

(I put much of the binding, client, and endpoint behaviors in the Web.Config.)

This code works but has problems. The channel to the Service Bus will open every time the service is called, resulting in suboptimal performance. To make this more efficient I decided to make the ChannelFactory and Channel variables statics so that I could reuse the channel if it had already been opened.

static ChannelFactory<ICustomerChannel> customersChannelFactory;
static ICustomerChannel customersChannel;

public static IEnumerable<Customer> GetCustomers()
{
    if (customersChannelFactory == null || customersChannel == null)
    {
        Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb",
            "MYSERVICENAMESPACE", "Customer");
        customersChannelFactory = new ChannelFactory<ICustomerChannel>(
            "RelayEndpoint", new EndpointAddress(serviceUri));
        customersChannel = customersChannelFactory.CreateChannel();
        customersChannel.Open();
    }

    return customersChannel.GetCustomers();
}

This updated does a good job of improving the performance of the service call but has it’s own problems. When you create a Channel through the ChannelFactory your channel can enter a faulted state – with the Service Bus there are a number of ways that this can occur (in my testing it was because I often stopped/started the service host). When this happens the WCF communication static must be reset by recreating the client channel.

Finding an efficient – and somewhat elegant – way of handling the faulted state proved to be a fun challenge. Fortunately, I received a lot of help from folks on the Service Bus team.

In the end I went with the following code:

static ChannelFactory<ICustomerChannel> customersChannelFactory;
static ICustomerChannel customersChannel;

public static IEnumerable<Customer> GetCustomers()
{
    List<Customer> customers = null;

    if (customersChannelFactory == null)
    {
        Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb",
            "MYSERVICENAMESPACE", "Customer");
        customersChannelFactory = new ChannelFactory<ICustomerChannel>(
            "RelayEndpoint", new EndpointAddress(serviceUri));
    }

    int tries = 0;
    while (tries++ < 3)
    {
        try
        {
            if (customersChannel == null)
            {
                customersChannel = customersChannelFactory.CreateChannel();
                customersChannel.Open();
            }

            return customersChannel.GetCustomers();
        }
        catch (CommunicationException)
        {
            customersChannel.Abort();
            customersChannel = null;
        }
    }

    return customers;
}

More verbose but much, much better.

The key is correctly handling the CommunicationException, aborting the channel, and setting the channel to null. Since we have retry logic via the while loop it will try again, determine that the channel is null, and re-open the channel.

There are certainly other ways to do this correctly. For example, you could decide to create a Faulted event handler.

I hope this helps!

Category: Service Bus, WCF, Windows Azure  |  2 Comments
« Previous Entries
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.