Here’s one way to migrate your SqlServer Database to the Azure platform.

1) Get the SQL Azure Migration Wizard http://sqlazuremw.codeplex.com/

2) Start the wizard and select SQL Database Migrate option

3) Select your source database

4) Choose the objects you wish to migrate (all in my case)

5) See the results and review the SQL Script if necessary.

6) Now we need Sql Azure in the cloud for the next part, log into your http://windows.azure.com account (get a 3 month free trial if you don’t have one)

Select your Azure Server and create a new database.

7) You’ll be prompted to select where you want your server located if you don’t already have one.

8) Add some rules to your database, you’ll need to do this to allow access for MS Services and Visual Studio

9) So now that you have a database in the cloud you’ll need to continue with your migration wizard by selecting this database.

10) That’s pretty much it. Hope these screenshots helps someone out.

When you modify a table in SqlServer and this change requires the table to be dropped and recreated, it’s necessary that SSMS is configured to allow this.

Go to SSMS/Tools/Options designers and uncheck this option.

See below

Was asked how to do this the best today...

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9dfb1773-5594-44a9-869f-a891629f80a5&displaylang=en

Here's an easy one to get caught out on.

Say you remove a constraint on a table to do some maintainance ect.

e.g.

ALTER TABLE BANDWIDTH NOCHECK CONSTRAINT FKUserLimits;

When you wish to bring the constraint back on stream you may be surprised to find the following does not quite work...

ALTER TABLE BANDWIDTH CHECK CONSTRAINT FKUserLimits;

You may be be able to see this in the execution plan on SSMS if the constraint was used in query optimization.

but you can check for sure by executing the following

select name, is_not_trusted FROM sys.foreign_keys where name = 'FKUserLimits';

you'll find that is_not_trusted is 1, indicating that the constraint is not trusted, this is because someone could have modified the table while the constaint was turned off, the sql to reenable the constraint needs to be told to check it while doing so..

here's how

ALTER TABLE BANDWIDTH
WITH CHECK
CHECK CONSTRAINT FKUserLimits;

This option tells SQL server to verify that all rows in the table comply with the constraint prior to turning it back on. If any rows do not comply with the constraint, an error message is returned and the alter table statement is rolled back.