Connecting DatabaseSpy to a SQL Azure Database in the Cloud

Tips and techniques to ease introduction of Microsoft’s cloud-based SQL Azure database into production environments led the topics in June at the Tech-Ed conference in New Orleans. SQL Azure is built on Microsoft SQL Server technologies and is designed to provide a highly-available and scalable database service hosted by Microsoft in the cloud. Developers who deploy databases in SQL Azure do not have to install, setup, patch, or manage any relational database software, only their own database structure and content. Automatic redundancy and fault tolerance are built-in and no physical administration is required. You can build a manual connection string and use SQL Server syntax and datatypes to connect DatabaseSpy and other Altova tools to SQL Azure databases to perform typical database development and maintenance tasks. This blog post makes a connection to a SQL Azure database from DatabaseSpy and demonstrates several typical operations you might want to perform as you migrate an existing database to the cloud. To retrace these steps on your own you will need a SQL Azure account, or a login and password created by a SQL Azure account holder. For more information on setting up a SQL Azure account, visit the Microsoft SQL Azure home page. You will also need to install the SQL Server Native Client 10.0 (or later). SQL Azure does not behave exactly like a local SQL Server database, so we can’t use the Altova SQL Server connection wizard. Instead we will use an ODBC connection. We won’t illustrate all the details of the process of building a new connection string here. You can paste an existing connection string into the dialog shown above, or, if you need specific instructions for each step to manually create a new string, you can refer to the Tech Note titled Build an ODBC Connection String for SQL Azure on the Altova Web site. After you connect to SQL Azure the first time, a DatabaseSpy project file lets you save all your connection settings along with frequently-used SQL scripts, database design files, and database comparisons in a convenient bundle to reload later. The screenshot below shows a new DatabaseSpy project with two databases connected simultaneously, Sakila in MySQL and Sakila in the cloud in SQL Azure. Microsoft provides a number of conversion tools to help users migrate existing databases to the SQL Azure platform. We used the Microsoft SQL Server Migration Assistant for MySQL to convert our local MySQL Sakila sample database to our SQL Azure account. DatabasesSpy lets users open multiple connections simultaneously, even to databases of different types. The database comparison functionality of DatabaseSpy makes it an ideal tool to check the results of the Sakila conversion. First we will open a database schema comparison and select a few tables from the MySQL database for the left side of the comparison. After we select the corresponding tables from SQL Azure version, the tables open in a database schema comparison window. When we click the green compare button at the top left corner of the window, DatabaseSpy compares the database structures, highlights differences, and generates a summary in the message window. Some differences represent datatype definitions that vary between databases. For instance, the MySQL type unsigned small int does not have an exact equivalent in SQL Server, so the conversion tool substituted the int type for the film_id column in the film table. Also, the year datatype assigned to the release_year column in MySQL has been converted to a smallint in SQL Azure. I guess this will make the SQL Azure version of the database more forward-compatible, since it will be able to accommodate films released all the way through the year 32,767, as opposed to 2155, which is the maximum value of the year datatype in MySQL! We can compare data contained in the two databases via a selection in the right-click context menu, opening the selected tables in a new data comparison window. The data comparison shows us the contents of the tables are not identical. When we open the results window, we see that the description column did not migrate successfully. Looking back at the Database Schema Comparison window, we can see the length of the description column was set to zero. This explains the red arrows that point from the description column in MySQL to the description column in SQL Azure in the Results window. We cannot copy any string of text into a column with a defined length of zero. Instead, let’s open the SQL Azure version of the film table in a new Design window. We can increase the size of the description field in the Properties window, and run the resulting change script. Next, when we re-run the data comparison, we find that the data was converted, but the previously defined field length of zero made the data invisible. Latency Issues You can use DatabaseSpy to explore latency issues for the cloud database vs. the local copy. We saw from the data comparison above that the film tables in the two databases contain 1,000 rows of identical data. We can repeatedly run SELECT statements to retrieve the data from SQL Azure and from the local MySQL database to time the results. The DatabaseSpy SQL Editor message window displays the execution time. Running the above SELECT statement five consecutive times on the SQL Azure version of the sakila database generated results ranging from 60.632 seconds to 63.851 seconds. Running a SELECT statement for the same film table in the local MySQL database yielded the following result: Repeating the test for the local version generated similar times. The takeaway for developers is your database-driven application will likely need to accommodate latency as you move your data to the cloud. Try your own connection to SQL Azure with a free trial of Altova DatabaseSpy.