Looks like Azure Storage Emulator omits SQL Azure. Does it hold true? Then how do I test my application that uses SQL Azure without deploying it onto live cloud?
-
There are a few parity issues with SQL Azure databases vs SQL Express (however these are minimized in case of V12). I wouldn't recommend testing by creating local instance rather go with a basic database (for single threaded app functionality testing). You can always export the database and import it when needed if concerned about the billing. Before you get into production you anyways need to deal with scale / perf etc. and those can't be tested locally. To avoid future surprises best approach is to create basic edition and scale up as per the requirements– Sirisha ChamarthiCommented May 19, 2015 at 6:06
4 Answers
For local testing, you can use a local SQL Server (full, express or even CE) within your app - just use local connectionstring's in place of the SQL Azure ones in your .cscfg or .config files - then the local compute instance will connect just like any other local process would.
For the most part local SQL and SQL Azure are compatible and interchangeable. Microsoft claim that SQL Azure shares much of its codebase with SQL Server 2008 R2. As a result you can use SQL Server 2008 R2 or SQL Server 2008 Express locally in order to test your application. Indeed, for "simple" applications you should also be able to use the new file-based SQL Server CE.
For "advanced" applications, then there are some limitations with SQL Azure - see limitations on http://msdn.microsoft.com/en-us/library/ee336245.aspx - but for many ASP.Net applications, you should be able to just migrate from SQL express to SQL Azure.
For more details on SQL vs SQL Azure, see http://social.technet.microsoft.com/wiki/contents/articles/comparing-sql-server-with-sql-azure.aspx
For migrating data from local SQL to SQL Azure, see the SQL Migration Wizard on Codeplex - http://sqlazuremw.codeplex.com/
-
How do I wire a role running in the Compute Emulator to my local SQL Server? Commented May 24, 2011 at 7:05
-
1Just use connection strings exactly as you would for your SQL Azure instance. To make it configurable for deployment then you should load these in the .cscfg file rather than in your .config– StuartCommented May 24, 2011 at 7:45
-
Do you mean a role will see my local SQL Server the same way as any local process would? Commented May 24, 2011 at 8:04
-
Yes - within the local compute environment, your role is a local process.– StuartCommented May 24, 2011 at 8:08
-
That's great. Could you please include it into your answer since it's not clear at first sight? Commented May 24, 2011 at 8:26
This reply needs to be updated.
Since this year you can now emulate Azure SQL Database locally:
i suggest you use SQL server 2008 express for onpremise development. you can migrate that to cloud once you are ready. But you need to be aware of contemporary limitations and also some architectural considerations while using SQL server.
And the best part is that you just need to change the connection string to connect to SQL Azure after the migration.
No, there is no local SQL Azure emulator. As Stuart mentioned, a local DB is the best option for local development.
With SQL Server 2012, you have the option of "Local DB". It is a very lightweight flavor of SQL Server 2012 Express. More details here. It only runs in "user mode", meaning
- You don't have to install SQL Server locally
- You don't have to run SQL Server as a service in the background full time
After you install it, there's now a project type in VS 2012. Similar to CE, it creates an MDF and LDF file. You connect to it with a connection string like this:
"Server=(LocalDB)\v11.0; Integrated Security=true ;AttachDbFileName=D:\Data\MyDB1.mdf"
This has worked well for me; the lighter download size is nice (33 MB vs 133 MB). It takes load off of my dev machine not to run a database server at all times.
Note: When you create the MDF/LDF files, it will probably be included in your solution. In my opinion, you should leave these files out of your VCS. I like to use scripts to create and update DB objects, then check those scripts in with my other source files.