SQLCMD and SQL Azure
I've seen several questions on forums over whether or not you can use SQLCMD with your SQL Azure instance. Well, I'm here to say yes you can! You can even create databases using the command line.
Create a .sql file with a script that creates your database, then save the file.
CREATE DATABASE databaseName
Then drop back to command line and use the following command:
sqlcmd -SyourInstanceName.windows.net -Uyou@domain.com -PyourPassword -dmaster -i –N CreateDatabase.sql
The server is whatever your SQL Azure instance name is, your login and password should be the login and password you have set up to access your Azure instance. I would like you to notice you're connecting to the master database, just as you would in a local SQL instance. Run this command, and you have your database. If you wanted to drop a database, just change out the script file to one that points to a DROP DATABASE command.
If you want to run any other script from SQLCMD, just make sure you update master to the database that that contains the objects you're going to reference in your script. Just remember, you cannot use GO databaseName with SQL Azure. Pretty easy stuff, right?
If you have any questions or concerns with SQL command and SQL Azure, let me know! I'm here to help!
Microsoft TechEd 2010 SQL Azure updates!
Microsoft TechEd is your chance to learn about cutting-edge insights and gain expertise that will make life easier for you and everyone you work with. You can Immerse yourself in hundreds of learning opportunities and get your questions answered by renowned technology experts. Today, Bob Muglia, President of Microsoft's Server and Business Tools gave the keynote speech. During that speech he revealed a number of enhancements that have be pretty excited.
Azure will be getting new spatial data support. New GIS style applications will be possible as well as some awesome mash ups with location based features!
We'll soon get access to 50 GB databases in SQL Azure, extending the scalability and flexibility of SQL Azure.
A public preview of SQL Azure Data Sync Service was also announced, a service which allows users to control where and how data is distributed and synced across multiple data centers. With finer controls over how and when data moves between centers, we can support more powerful interactions with users spread across the globe!
A new Microsoft SQL Server Web Manager (a management tool to aid in developing, deploying and managing cloud applications) was also announced. This should make deployment even easier than it is now.
This week should provide many little tidbits like this! I can't wait to learn more! What have you heard that I missed? Let me know in the comments!
SQL Azure DATETIME Functions
Microsoft SQL has always included a number of date and time functions. These results of these functions were always based on the operating system for the machine the SQL server was running on. But what results will you get when you're dealing with SQL Azure?
The server(s) are all virtual.
They are all based on UTC, Coordinated Universal Time. Yes, I know the acronym should be CUT. Just go to Wikipedia if you want to try and make sense of this.
Since all these functions will run based on UTC, you'll always get the same results, no matter which data center you choose to be your primary.
The table below shows the results from the following query run against a SQL Azure instance hosted in South Central US on 30th May 2010 13:00:42 UTC.
SELECT
SYSDATETIME() as SYSDATETIME,
SYSDATETIMEOFFSET() as SYSDATETIMEOFFSET,
SYSUTCDATETIME() as SYSUTCDATETIME,
CURRENT_TIMESTAMP as currenttimestamp,
GETDATE() as getdate,
GETUTCDATE() as getUTCdate;
Query
| SYSDATETIME() | 2010-05-30 13:00:42.2422123 |
| SYSDATETIMEOFFSET() | 2010-05-30 13:00:42.2422123 +00:00 |
| SYSUTCDATETIME() | 2010-05-30 13:00:42.2422123 |
| CURRENT_TIMESTAMP | 2010-05-30 13:00:42.250 |
| GETDATE() | 2010-05-30 13:00:42.250 |
| GETUTCDATE() | 2010-05-30 13:00:42.240 |
Results from SQL Azure Database (time of query 30th May 2010 13:00:42 UTC)
The same results were returned from SQL Azure databases hosted in Northern Europe, South Central US and South East Asia.
If you are like me, whenever you deal with international users, you already changed your servers to UTC, so taking this into consideration for SQL Azure should be nothing new. If you're not used to this. Perhaps now is the time to consider the benefits to having your server use UTC, store UTC + offsets in your tables, and allow users to run with multiple time zones.
It sure makes scheduling easier that way. Or at least it beats trying to figure out what time to hold a meeting between India the US and Mexico, both before and after Daylight Savings time kicks in!
