Blogging with Word and DasBlog#

I am a horrible blogger. I think the reason I am a horrible blogger is for two reasons:

  1. No good authoring tools
  2. I just haven't taken the time to come up with topics

I'm not someone who will blog or tweet just for the sake of blogging or tweeting. To me it needs to be meaningful and add value. However, I found out today that you can use Microsoft Word as a blog authoring tool! OK, yes, I probably should have known that, but I never really looked at Word as an option.

Until today.

I'm currently in New York at a Microsoft big data hackathon, having come from Microsoft BUILD and Ignite conferences. I have been thinking a lot about the role of the SQL DBA and how big data technologies will affect their role and what the future holds. I thought a blog series around this would be awesome, but then remembered issue number 1.

I just happened to ask a group of local MS guys here at the hackathon what authoring tools they use, and one of them mentioned MS Word! It never donned on me that Word was an option. Lo and behold, Word has a blog template. I love Word and for authoring blogs this make sense! So, this blog is actually being authored in Word. What took me a while was setting it up because my blog engine is DasBlog and that isn't an option when defining and connecting to a blog in Word.

So, after searching out on the webosphere, I found enough information to connect Word to DasBlog. So, if you are using DasBlog and want to use Word to author your blogs, the following steps will help with that. Oh, by the way, I am using Word 2013.

When connecting to DasBlog (select New Blog Account from the ribbon bar), select Other and click Next.

In the New Account dialog, set the information as follows:

API: MetaWebLog

Blog Post URL: http://<blogrooturl>/blogger.aspx

Username & Password: Your blog username and password

 

Your New Account dialog should look something like the following. Notice that my Blog Post URL points to a Microsoft Azure Web Site. Why? Because Azure is awesome and it took mere minutes to set up my blog.

So, now that I can author my blogs quickly in a tool I already know, I should be blogging more.

 

Saturday, May 9, 2015 10:46:39 AM (Pacific Daylight Time, UTC-07:00) #    Comments [0]  | 

 

On Channel9 - Azure Search, DocumentDB, Graph Databases, Bob Ward, and More!#

The Channnel9 DataExposed show is going gangbusters. We have quite a few shows already with some awesome guests from engineering, support, and DX at Microsoft. For example,

I’ll also be publishing a lot more videos on these topics that dive deeper into this technologies, and I’ll also be adding videos that talk about Azure Machine Learning, HDInsight, and more.

Scott

Thursday, September 25, 2014 10:02:22 AM (Pacific Daylight Time, UTC-07:00) #    Comments [0]  | 

 

On Channel9 - Azure Search, DocumentDB, Graph Databases, Bob Ward, and More!#

The Channnel9 DataExposed show is going gangbusters. We have quite a few shows already with some awesome guests from engineering, support, and DX at Microsoft. For example,

I’ll also be publishing a lot more videos on these topics that dive deeper into this technologies, and I’ll also be adding videos that talk about Azure Machine Learning, HDInsight, and more.

Scott

Thursday, August 28, 2014 4:14:08 AM (Pacific Daylight Time, UTC-07:00) #    Comments [0]  | 

 

Ying, Yang, Bang! Radio Show and Channel9 Show#

I haven’t been posting for a while so I wanted to take a few minutes and write about a couple of side projects I have been working on lately.

Ying, Yang, and a Bang!

For the past few months a group of us have been doing a live internet radio show called Ying, Yang, and a Bang! (@YingYangBangSho) consisting of myself (@SQLScott), Scott Hunter (@coolcsh), Corey Sanders (@coreysanderswa), and Brady Gaster (@bradygaster). You probably know most, if not all, of these guys. Scott Hunter drives the ASP.NET development features in Visual Studio. Corey Sanders drives the Azure IaaS features such as Azure VMs. Brady drives the Azure Management Libraries for .NET. I, well, we’ll stop there.

We typically run this show every other Friday at 9am PST for 1/2  hour. Depending on our schedules we’ll change that up once in a while. That is why I highly recommend you follow @YingYangBangSho as we’ll tweet about upcoming shows in advance. You can also listen to old shows we have done by going to http://www.blogtalkradio.com/yingyangbang and clicking on any one of our old shows.

I love doing this radio show because you, the listener, can actually call in and talk with myself or any one of us; ask us questions, tease us, tell Corey how well he dresses, or just give us a hard time. Well, not the last one because we might hang up on you. :-) Anyway, if you don’t feel like calling in you can chat with us via IM (this does require that you create a free BlogTalkRadio account). Either way, this is a great opportunity to talk to some of the awesome PMs at Microsoft.

Our next show is scheduled for Friday, June 13th, but keep an eye out on @YingYangBangSho in case that changes. We look forward to hearing from you!

Data Exposed

I recently just started a Channel 9 show dedicated solely to the topic of data called Data Exposed.  Following the same format as a lot of the other shows including Cloud Cover and Visual Studio Toolbox, Data Exposed is hosted by myself and will include weekly guests from our engineering teams. Focused completely on the topic of data, Data Exposed will discuss topics ranging from SQL Server, Azure SQL Database, HDInsight (big data topics), and more.

Our first show will be recorded next Tuesday and posted that same day. Look for a show on Channel9 (http://channel9.msdn.com/Browse/Shows) called Data Exposed. If there is a specific topic you are interested in hearing about, let us know.

Thursday, June 5, 2014 12:11:10 PM (Pacific Daylight Time, UTC-07:00) #    Comments [1]  | 

 

Upcoming Speaking Engagements#

What I thought was going to be a fairly calm summer for events and speaking is actually going to be busier than I thought. My June, July, and August schedule is pretty interesting and if you are in or near any one of these events, please stop by and say Hi and attend some of the awesome sessions going on (ok, mine… :-)).

My sessions at these events discuss topics ranging from SQL Server 2014 features to running SQL Server in an Azure VM and nearly everything in between (like Azure SQL Database). I’m looking forward to these events and hope to see you there!

Monday, June 2, 2014 12:39:51 PM (Pacific Daylight Time, UTC-07:00) #    Comments [0]  | 

 

Manage Windows Azure SQL Database with the .NET Management Libraries#

For quite a while I was fortunate to share an office with Brady Gaster (@BradyGaster), currently a PM on the Windows Azure SDK team. Brady LOVES the idea of developing tools that make cloud development easy. Brady has spent the last year working on a set of management libraries that make it SUPER easy to manage your Windows Azure resources, including Windows Azure SQL Database.

Last week, Brady’s team released the SQL Management Library, loaded with features for managing your databases in Windows Azure SQL Database (WASD). I have seen and played with the SQL Database Management libraries, and I must say, Brady and his team did an OUTSTANDING job. Being a SQL guy, I have to admit that this library was well worth the wait. Some of the things you can do with library for SQL Database include:

  • Import and Export SQL Databases to and from WA Blob Storage
  • List your Windows Azure SQL Database Servers and associated databases
  • List Firewall rules for your Windows Azure SQL Database Servers and associated databases
  • Create, update, and delete Windows Azure SQL Database Servers, databases, and firewall rules

Brady blogged about this management library here.

What I like about this library is the miniscule amount of code it takes to work with WASD. For example,

SqlManagementClient _sqlManagementClient = new SqlManagementClient(
    new CertificateCloudCredentials(_host.SelectedSubscription.SubscriptionId, 
        new X509Certificate2(Convert.FromBase64String(_host.SelectedSubscription.ManagementCertificate))));
var getServerResult = await _sqlManagementClient.Servers.ListAsync();
ServerList = getServerResult.Servers;

3 LINES OF CODE! Getting a list of databases is just as simple:

var listDatabaseResult = await _sqlManagementClient.Databases.ListAsync(SelectedServer.Name);
Databases = listDatabaseResult.Databases;

Want to create a database? One line of code:

_sqlManagementClient.Databases.Create(servername, createparameters)

These libraries have full intellisense making then extremely easy to use.

What I also like about these management libraries is that, even though it requires working with X509 Certificates to authenticate, the WAML makes it extremely easy by using the *.publishsettings files that you can download from Windows Azure. You can download the .publishsettings file several ways including the PwerShell cmdlet Get-AzurePublishSettingsFile which provides a Base-64 encoded representation of an X509 certificate.

Brady created a sample app to demonstrate all the cool WAML (Windows Azure Management Library) features, and you can download it from GitHub. So, download it and play with it and let Brady and I know what you think.

Happy Coding!

Tuesday, December 17, 2013 9:18:08 AM (Pacific Standard Time, UTC-08:00) #    Comments [3]  | 

 

Migrating Microsoft Access applications to Windows Azure Mobile Services–Part 3#

In the last post in this series I walked through the process of using the SQL Server Migration Assistant for Access to migrate an Access database to Windows Azure SQL Database. In this post I’ll walk through the process of creating a Windows Azure Mobile Service and then associating that new Mobile Service to the database imported in the last blog post.

Creating the Windows Azure Mobile Service

In the Windows Azure Management Portal, click the +New button at the bottom of the portal and select Compute –> Mobile Service –> Create, which brings up the New Mobile Service dialog. In the URL type of the name of the Mobile Service. In this example I named the service northwind. This name is important and will be used shortly.

SNAGHTML14461b5b[6]

Click Next.

On the Database Settings page, select the northwind database, then enter the username and password. Click Finish.

image

Modifying the Database Schema

At this point the Windows Azure Mobile Service is created but in order for the Mobile Service to access the SQL Database tables, the Mobile Service name must match the database schema associated to the tables imported in the previous post.

For example, the default schema is dbo and currently the existing tables are associated to the dbo schema. Since the name of the Mobile Service is northwind, the next step is to create a schema with the same name as the Mobile Service and re-associate the tables to the northwind schema. The following script does just that.

CREATE SCHEMA northwind;
GO
ALTER SCHEMA northwind TRANSFER [dbo].[Customers]
ALTER SCHEMA northwind TRANSFER [dbo].[Employees]
ALTER SCHEMA northwind TRANSFER [dbo].[InventoryTransactionTypes]
ALTER SCHEMA northwind TRANSFER [dbo].[InventoryTransactions]
ALTER SCHEMA northwind TRANSFER [dbo].[Invoices]
ALTER SCHEMA northwind TRANSFER [dbo].[OrderDetails]
ALTER SCHEMA northwind TRANSFER [dbo].[PurchaseOrderDetails]
ALTER SCHEMA northwind TRANSFER [dbo].[Orders]
ALTER SCHEMA northwind TRANSFER [dbo].[OrderDetailsStatus]
ALTER SCHEMA northwind TRANSFER [dbo].[OrdersStatus]
ALTER SCHEMA northwind TRANSFER [dbo].[OrdersTaxStatus]
ALTER SCHEMA northwind TRANSFER [dbo].[Privileges]
ALTER SCHEMA northwind TRANSFER [dbo].[Products]
ALTER SCHEMA northwind TRANSFER [dbo].[PurchaseOrderStatus]
ALTER SCHEMA northwind TRANSFER [dbo].[PurchaseOrders]
ALTER SCHEMA northwind TRANSFER [dbo].[Shippers]
ALTER SCHEMA northwind TRANSFER [dbo].[Strings]
ALTER SCHEMA northwind TRANSFER [dbo].[Suppliers]
ALTER SCHEMA northwind TRANSFER [dbo].[EmployeePrivileges]
ALTER SCHEMA northwind TRANSFER [dbo].[SalesReports]

After running the script, the database tables are now associated to the new schema.

image

The reason the Mobile Service was created first is to ensure that the Mobile Service name is available before creating the database schema. Otherwise, you might create the schema and then find out that the Mobile Service name isn’t available (already in use).

Associating the Existing Tables

Returning to the Windows Azure Management Portal, select the new Mobile Service and click the DATA tab. You will see that the tables still aren’t appearing in the portal. The next step is to “tell” Mobile Services about the existing tables. To do that, click on the ADD A TABLE link.

clip_image004

In the Create New Table dialog, enter the name of the tables as it exists in the SQL Database instance; for example, Employees. Leave the Permission options with their default. Click OK.

image

Repeat the process for the remaining tables. After each table is added, the DATA tab will automatically refresh after several seconds and display the table with the related number of indexes and number of records in the table.

image

Voila, the Microsoft Access database has been successfully migrated to Windows Azure Mobile Services. However, this is just only the beginning because the next few blog posts will walk through the process of creating a Windows Store app that connects to this Mobile Service.

Conclusion

These last three blog posts have walked through the process preparing and migrating a Microsoft Access database to Windows Azure SQL Database and creating a Windows Azure Mobile Service to use the new SQL Database instance. Depending on the complexity of the Access database, this process can be trivial or require a bit more work. The first two blog posts showed the process for an Access database that wasn’t too trivial but shows that it can be done.

On to the UI!

Tuesday, February 19, 2013 2:44:20 PM (Pacific Standard Time, UTC-08:00) #    Comments [0]  | 

 

Migrating Microsoft Access applications to Windows Azure Mobile Services–Part 2#

In the last post I discussed how to prepare your Microsoft Access database for migration to Windows Azure SQL Database with the ultimate goal of putting a Windows Azure Mobile Service on it. In this post I’ll walk through the process of migrating the Access database prepped in the last blog post to Windows Azure SQL Database.

Setup and Configuration

This example is going to use the SQL Server Migration Assistant for Access (SSMA) to migrate the database from Microsoft Access to Windows Azure SQL Database. The SQL Server Migration Assistant for Access is a free supported tool from Microsoft that simplifies database migration from Access 97 and higher to SQL Server 2005 and higher, including Windows Azure SQL Database. SSMA for Access automates the conversion and migration of Access database objects to SQL Server database objects as well as migrating the data.

Installing the SSMA for Access will install both a 32-bit and 64-bit version of SSMA; you’ll see two SSMA icons on your desktop. More than likely you’re running the 32-bit version of Access (or Office), so this walkthrough will use the 32-bit version.

However, prior to running the SSMA for Access, there is another component that needs to be installed. The Microsoft Access 2010 Runtime is used by the SSMA for Access. It allows the SSMA for Access to read and interrogate any Microsoft Access database without the need to install the full version of Access 2010 or higher.

Lastly, the SSMA for Access assumes that a Windows Azure SQL Database already exists that it can migrate the Access database to. This walkthrough won’t get into how to provision a Windows Azure SQL Database server or create a SQL Database instance, but for information on that you can review the Hands-on-lab Introduction to SQL Database.

Migrating the Access Database to Windows Azure SQL Database

Start the migration process by running the 32-bit version of SSMA for Access. When SSMA launches, it will begin a wizard that walks through the migration process. First, click Next on the Welcome screen.

On the Create New Project page of the wizard, enter a project name and the location where the project will be saved. SSMA projects are files that contain metadata about the Access database you want to migrate, metadata about the target SQL Server or Windows Azure SQL Database instance you are migrating to, and project migration settings.

In the Migrate To field, select SQL Azure then click Next.

clip_image002

The second page of the wizard is where you select the Access database. Click the Add Database button to browse to the location where the NorthwindData database resides. Click Open on the Open dialog box. The Add Access Database page will show the location of the database selected.

clip_image003

Click Next.

The SSMA will then iterate through the Query and Table objects in the Access database and list them on the next page of the wizard. The tables will automatically be checked for migration. We are not concerned with the queries, so simply ensure that all of the Tables are selected and click Next.

clip_image005

The next page of the migration wizard is where the SSMA will connect to the SQL Database instance. On this page of the wizard, enter the SQL Database instance connection information. The SQL Database instance must already exist; the SSMA will not automatically create the SQL Database instance. However, clicking the Browse button will display a list of existing database plus an option to create a new database.

After entering the SQL Database connection information and clicking Next, the SSMA will try to connect to the specified SQL Database instance. If the SSMA can’t connect to the SQL Database instance, it will typically be for one (or both) of the following reasons:

  • One or more of the connection information entered is incorrect.
  • A firewall rule was not configured for the corresponding Windows Azure SQL Database server in the Windows Azure Management Portal.

The Encrypt Connection check box, checked by default, ensures that the connection to SQL Database is encrypted and secure. Leave this checkbox checked.

clip_image007

Once the SSMA has successfully connected to the SQL Database instance, the SSMA will do a quick object comparison between the objects selected for migration in the SSMA and any corresponding, existing objects in the SQL Database instance, then display the comparison results in a dialog. The dialog shows which objects will be synchronized (migrated) from Access to SQL Database.

Since the SQL Database instance was recently created there shouldn’t be any Table objects. Click OK on this dialog.

clip_image008

At this point the actual migration begins. The migration is a 3-step process. First, the SSMA will perform a conversion process which takes the object definitions from the Access metadata and converts them into equivalent T-SQL syntax. It then loads the T-SQL syntax into the project.

After the objects have been converted, the SSMA will automatically load (migrate) the schema for the selected objects to the target database, in this case, the SQL Database instance. Once the schema for the selected objects are migrated, the data is then migrated. When the migration is complete, the status of the migration will be shown.

clip_image010

During the conversion, load, and migration of the Access database to SQL Database, the SSMA will print current status to the output pane, and any errors, warnings, and information messages will be output to the Error List pane. You can use this information to determine whether you need to modify your Access database or your conversion process to address items in the Access database.

Click Close on the migration wizard, and exit the SSMA for Access. When exiting, you will be prompted to save the project. You don’t need to save the project but saving it might come in useful if you need to change some of the project settings or want to look at the generated T-SQL.

The results of the migration to Windows Azure SQL Database can be viewed by opening SQL Server Management Studio and connecting to the SQL Database instance. Expand the Tables node for the northwind database and verify that all of the tables have been migrated.

clip_image011

Summary

At this point we’re ready to create the Windows Azure Mobile service which we will do in the next post.

Monday, February 18, 2013 3:56:59 PM (Pacific Standard Time, UTC-08:00) #    Comments [0]  | 

 

Migrating Microsoft Access applications to Windows Azure Mobile Services–Part 1#

Windows Azure Mobile Services is a turnkey backend solution for making and delivering mobile and Windows store applications, providing an easy and efficient way to store structured data objects in the cloud. The goal behind Windows Azure Mobile Services is to allow developers to very quickly be able to connect their client applications, such as Windows 8 apps, IOs, or Android, to a cloud-based backend hosted on Windows Azure. Mobile Services provides the foundation for how you can build a richer client experience with the cloud.

Users of current Microsoft Access application should miss out on the “richer client experience”, so starting with this post, and over the next 4 or 5 posts, I will provide an end-to-end and step-by-step solution for moving the database to Windows Azure SQL Database, creating the Windows Azure Mobile Services, associating the new Mobile Service to the database, setting up and configuring security, creating a few pages in Mobile Services, and querying the underlying data.

In this first post, I’ll walk through the steps required to prepare the Access database for migration, and the database I’ll be using is the well-known Northwind database. Any Access database will work, but to get the full effect of a true migration, but the Northwind database has been around for a long time and is a widely-known sample database. 

Requirements, Differences, and Items of Interest

Before I get to the meat of this walkthrough, there are few items I need to point out when migrating a Microsoft Access database to Windows Azure SQL Database. First, Access allows spaces in table and column names. You’re thinking “Yes, but so does SQL Server”. Yes, that is true. Windows Azure SQL Database allows spaces in table and column names too. But Windows Azure Mobiles Services (WAMS) does not. As such, it is possible to import the Access database into a SQL Database instance, but Mobile Services will not recognize them without removing the spaces.

Also, each table must have a primary key column simply named ‘id’ (lower case). In fact when you create a new table in Mobile Services, the service will automatically add the ‘id’ column for you. However, for Access, this means some renaming of columns prior to the migration process.

Chances are that your Access database has table and/or column names with spaces. Meaning, instead of a column named FirstName, the column is named [First Name]. Plus, your primary keys more than likely are not simply named ‘id’. This is the other reason I am using the Northwind database. It is close to a “real-world” scenario.

The Northwind database has roughly 20 tables, and luckily a lot of them have their primary keys called ‘ID’. They are uppercase, but we can fix that. Since Access is a relational database, it has Primary Key / Foreign Key relationships which will need to be taken into consideration during the migration process.

clip_image002

Taking a quick look at the Employee table shows several things that need to be addressed:

  • Spaces: Nearly every column has a space in the column name, and some have forward slashes ‘/’ in their names.
  • Data Types: Access uses different than SQL Database. Most of the data types can be converted during the migration process. We’ll discuss the Attachments data type in another blog post.
  • Primary Key: The ID column name needs to be renamed to lower case.

clip_image003

Preparing the Access database for migration

So, with that, let’s begin. Preparing the Access tables and data for migration is a multi-step process:

  • Export the tables to text files
  • Apply the fixes in the text files
  • Import the text files into Microsoft Access

It is possible to migrate the Access tables as they currently are into Windows Azure SQL Database and then apply the fixes in SQL, but there are two main reasons why it will be easier not doing it that way. First, applying the fixes in SQL will require hundreds of sp_rename statements. Second, and more importantly, it is not as simple as calling sp_rename. If the object being renamed has a dependency on it, the rename will fail. For example, the [First Name] column in the employee table has a constraint on it. Trying to rename the column results in the following:

Msg 15563, Level 16, State , Procedure sp_rename, Line 497

Object 'dbo.[Employees].[Last Name]' cannot be renamed because the object participates in enforced dependencies

The fix would be to also script out all of the dependencies and fix those. What you will end up with is a fairly lengthy script to fix to rename the objects (to clear up the spaces) and fix the names in the dependent objects.

For this example, keeping the constraints isn’t important. I just want the data. I can always apply the constraints later when the tables and data are in the SQL Database instance.

The first thing to do is export all of the tables to text files. There are several ways to export the data. Not being an Access guy, the first thing that came to mind was to do the obvious and walk through the export wizard (right mouse click on the table and select Export -> Text File. However, Microsoft Access has Macros which help automate and group tasks, which is much easier.

NOTE: This walkthrough uses Access 2013 so if you’re using earlier versions, your menus and options might be a bit different.

The idea is to find and use a Macro that will easily export the tables to text file with a delimited format and with the column names on the first row of the text file.

Click the CREATE tab and then select the Macro button which opens the Logic Designer for creating Macros.

clip_image005

In the Logic Designer is a new Macro called Macro1 with a dropdown of available macro actions to add to the macro. The problem is that the only “export” option is called ExportWithFormatting. Also present is the Action Catalog window, to the right of the Macro, which likewise lists the macro actions available. Expanding the Data Import/Export node in the Action Catalog window shows the same list of available import and export actions that are available in the dropdown, including the ExportWithFormatting macro.

The export files needed for this walkthrough don’t need any special formatting, so the trick here is to ensure that the DESIGN tab is selected (it appears when working with macros) and click the Show All Actions button. New macro actions appear in the Action Catalog, which is perfect because the one needed for this walkthrough is called ImportExportText. Double-click the ImportExportText macro action and it will show up in the macro design surface and display argument boxes for the ImportExportText macro. Set the properties and arguments as follows:

  • Transfer Type: Export Delimited
  • Table Name: Access table name
  • File Name: Path where text file will be created
  • Has Field Names: Yes

Add the ImportExportText action to the macro design surface once for each of the tables.

clip_image007

It is important in the step to make sure that the file name entered in the File Name property does not include spaces. As shown in the above figure, the Employee Privileges file name is EmployeePrivileges.txt. Not including spaces in the file name will make the import process much easier.

Once all of the export actions have been added, click the Run button on the toolbar. This will generate a file for each table which includes the data, as well as the column names on the first row. The columns are comma separated and use the double quotes (“”) as the text qualifier.

The next step in the process is to clean up the spaces in the names. For tables, that was taken care of by specifying the file names without spaces in the export process above. For columns, the process is a bit more laborious. Open each text file, and remove all of the spaces in the column names in the first row.

Next, ensure that any primary key columns are simply called ‘id’ (lower case without the quotes). Since the primary key column in the Employee table was already called ‘ID’, the change was simply changing it to lower case.

clip_image009

The Invoices table, for example, is a little different; its primary key column is named ‘Invoice ID’. Same thing here; simply need to change that to ‘id’.

Importing the Text Files

The next step is to import the text files back into Access. There are several reasons for this. First, it will be easier to migrate the data into Windows Azure SQL Database from Access. Second, exporting the data to text files to clean them means that primary key and auto-number information was lost.

The quickest and easiest way to address this is to create a new, blank desktop Access database. For this walkthrough, I called it NorthwindData. This is the database the data will be imported into to fix the primary key and auto-number issues.

clip_image010

The process for importing the data is the same for exporting the data using the ImportExportText action in a macro. The only difference here is setting the Transfer Type property to Import Delimited (which is the default action). The import properties should be set as follows:

  • Transfer Type: Import Delimited
  • Table Name: New Access table name
  • File Name: Path to the corresponding text file
  • Has Field Names: Yes

Add the ImportExportText action to the macro design surface once for each of the tables. Once all of the import actions have been added, click the Run button on the toolbar which will import each file.

clip_image012

Once the text files are imported as tables into the new Access database, the next step is to quickly go through each table and add the primary key back. Open each table, select the ‘id’ column, and click the Primary Key button on the toolbar.

clip_image013

The AutoNumber data type cannot be set here because there is already data in the table. That’s OK because this can be addressed after the table is migrated to Windows Azure SQL Database.

Now, you’ll probably notice as you go through the tables setting the primary key that exporting to, and importing from, a text file reset some of the data types on some of the columns. For example, the Notes field in the original database is a Long Text, but in the new database it is a Short Text. The Attachments column is no longer an Attachment data type but also a Short Text.

Not to worry, because as we’ll see in the next blog post, the migration tool we will use will help us with that.

clip_image014

The last step is to reset the relationships. Select the DATABASE TOOLS tab then click the Relationships button. Add the tables to the designer and recreate the relationships as they exist in the original Northwind database.

clip_image016

Summary

The intent of this post was to focus preparing a Microsoft Access data for migration to Windows Azure SQL Database which will ultimately be used as a backend for Windows Azure Mobile Services. In the next blog post we’ll actually walk through the migration process.

Monday, February 18, 2013 3:40:57 PM (Pacific Standard Time, UTC-08:00) #    Comments [0]  | 

 

Windows Azure Office Hours Online#

Windows Azure Office Hours are Back!

Have a question about Windows Azure? Join myself and Mike Benkovich every Friday at 9:00 AM PST where we open the doors to the masses in a fast paced and deep conversation into the technologies regarding Windows Azure. Each week we’ll try and have a special guest from Microsoft from the Windows Azure product group. On Friday, February 22nd, our special guest will be Josh Twist, Program Manager on the Windows Azure team and first full-time member of the Mobile Services project. On Friday, March 1st, our guest will be Scott Hunter, Principle PM Lead for ASP.NET.

We’ll also be recording each session so you will be able to check out past Office Hours Online conversations.

Visit http://www.benkotips.com/OfficeHrs for information and to join the meeting and post questions which will be answered during the session.

Monday, February 18, 2013 11:30:00 AM (Pacific Standard Time, UTC-08:00) #    Comments [0]  | 

 

All content © 2016, Scott Klein
On this page
This site
Calendar
<August 2016>
SunMonTueWedThuFriSat
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Archives
Sitemap
Blogroll OPML
Disclaimer

Powered by: newtelligence dasBlog 2.3.12105.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Send mail to the author(s) E-mail

Theme design by Jelle Druyts


Pick a theme: