Select subscription’s name in the Azure Console, select database and click on the Create button.

You will have to select the region where you want to host the new server:

Choose your region and click Next.

In the next screen, you will have to create a login in order to administer the server. You must use a strong password.

Remember that SQL Azure does not support Windows Authentication. Next, you will have to create a firewall rule to enable access to this server.

In the Create Server window click on Add button

In the Add Firewall Rule window, add a name for this rule and enter an IP range authorized to access the server.

Finally, click on OK button. Now, you will be able to access the portal, to do this, select the server in the administration console and click on Manage.

The SQL Azure Access Window is displayed. Enter the login information (user and password). Since we have not created a database yet, you can omit this field.

Click on Log On to access the portal. Now you are inside the administration portal. Click the Create Database button as shown in the following illustration.

Enter the database name in the Name field and select the database size. The available sizes depend on your subscription type. You can type a different collation for the database if you want at the bottom of the page. Click Submit to create the database.

After the database is created, you will see its properties including the fully qualified name on the upper left corner.

Although you can administer the database from here, it’s easier to use SQL Server Management Studio. All you have to do is click on Connect button and enter the fully qualified name in the server box and the login information:

Once connected, you will see your SQL Azure database in the object explorer:

An interesting point is that you can implement data synchronization using any Edition of SQL Server, including Express Edition. In fact I used this version in my own tests.

Configuring SQL Azure Data Sync

To configure SQL Azure Data Sync you have to access the Windows Azure Portal and select Data Sync option and click on Provision button.

Configuring Data Sync requires working on the Azure portal as well as in the local service user interface. You will need an Agent Key to configure the local service; the Agent Key is obtained from the SQL Azure Portal.

Accept the Terms of Use.

Select your subscription:

Click on Next and select the region where you want to provision the Data Sync Service:

Click on Finish and start configuring the service.

To start configuring the service, you have to follow the next steps:

1. - Enter a name for the Sync Group and click on the next arrow (>)

2. – In the Step 2 you will have to add a local database:

The window “Add Database to Sync Group” will appear:

3. – Choose Add new SQL Server database to the sync group and select the synchronization direction. Sync to the Hub lets you synchronize information from the On-Premise database to the SQL Azure database while Sync from the Hub is the opposite. If you want to sync from either side select Bi-Directional.

Click Next. Now you will have to configure the data sync Agent:

4. -Since this is the first time we are configuring the Agent, it is necessary to click on Install a new Agent. In case you have already installed and configured the Agent, you can select the option Through an existing Agent. Click Next to continue. You will be able to download the agent from the Internet in the next page:

5. – Click on Download and proceed to install the agent. The setup program is quiet straightforward and requires Microsoft.NET Framework 4.0; the setup programs will give you a link to download .NET Framework 4 in case you do not have it. The minimum OS version required is Windows Vista; if you have Windows XP you won’t be able to install it.

Once installed, you will need to specify a name for the Agent. Enter the name you wish to assign in the Agent Name textbox:

6. – Now you will need to an Agent Key which is required in order to configure the Agent. Click on Generate Agent Key to generate a new Key. The button will be enabled once you have installed the Agent.

7.- Click the Copy Button to copy the Key to the clipboard

In order to finish the SQL Azure Data Sync configuration, it is necessary to configure the Sync Agent first. I´ll switch to SQL Azure Sync Agent configuration.

Configuring SQL Azure Data SYnc Agent

The First time you start the Agent, the only available option is Submit Agent Key Configuration.

a) - Click on Submit Agent Key Configuration button to enter the agent Key.

If you still have the Key in the clipboard, you can paste it in the Agent Key textbox.

a) Click OK. If the key is correct, all the buttons in the toolbar will be enabled.

Now you will need to register your local server as well as the database you want to synchronize.

b) Click the Register button.

The SQL Azure Data Sync Agent will connect to your local SQL Server in order to register your database, this connection can use SQL Authentication or Windows Authentication, and you can choose whatever you want.

a) Enter the server name as well as the database name and click the Test Connection button.

If everything is fine you will see a confirmation message:

The registration information will be saved in the Data Sync Agent window:

This concludes the SQL Data Sync Agent configuration process. Now let´s switch to SQL Azure portal to continue with SQL Azure Data Sync process.

Database Sync Group (Continued…)

Now switch to the Add Database to Sync Group window and click Next.

8. – In Step 2 click the Get Database List button to display the database you just registered.

9. - Finally, select the database, in this case SalesOnPremise which is the local database:

10. - Click Finish.

Add the SQL Azure Database

Now you we have to add the SQL Azure database that will be synchronized with the On-Premise database. This is done in the CLOUD section in the SQL Azure Portal.

1.- Click on the icon with the leyend “Click to add a Windows Azure SQL database as the Sync Hub”

The window titled “Add Database to Sync Group” will display, enter the SQL Azure server name, the SQL Azure Database name and the authentication information.

2.- Click Test to verify the connection:

Click Add to save the information.

3. – Go to Step and configure the Synch Schedule, you can select any value between 5 minutes and 1 month. You can also specify conflict rules in case you have to overwrite data.

4.- Go to Step 5 and click the Edit Dataset button in order to define which tables and columns you want to synchronize.

5.- Apply a filter if you want to specify which rows will be synchronized, click on the Filter check box and write an expression.

6.- Finally, deploy the changes by clicking Deploy button on the toolbar:

7.- To star synchronizing. Click on Sync Now button on the toolbar:

After the synchronization occurs, you will see a new Schema called DataSync inside your databases as well as several tables used to maintain synchronization:

And several stored procedures too:

Verifying synchronization

To test the process, I insert some rows into Products:

Click on Sync now:

And query the SalesOnCloud database to see the records:

Sync data is stored inside an XML schema inside the data sync tables:

Adding more databases

Once you have configured the initial database is easy to add more On-Premise databases, just go to the ON-PREMISES region in the portal and click the Add a SQL Server database icon

Just repeat the previous steps to register the database in the Sync Agent:

And add the database to the Sync Group

And you will see the database in the ON-PREMISES section in the portal:

You can also add another SQL Azure database to your topology just clicking the corresponding icon:

The process is similar to the previous shown before.

Conclusions

The SQL Azure DataSync is an excellent tool for manage scenarios similar to replication but using a SQL Azure Database. The process Works fine and quick and once it is released to production will be a good alternative for consolidate and replicate information.

With Cloud Computing as an emerging platform we have now new possibilities covering different scenarios.

SQL Azure Data Sync is a new service (currently in beta) hosted in the Windows Azure Platform used to synchronize data between an On-Premise Database and a SQL Azure Database or between multiple SQL Azure Databases.

SQL Azure Data Sync works along with a service called SQL Data Sync Agent which must be installed where the On-Premise Database resides or in a PC that can reach the On-Premise Database and be able to access the SQL Azure Database. The service looks for changes in the On-Premise Database and propagates changes to the SQL Azure Database.

In this Post I will explain how to configure and use SQL Azure Data Sync, SQL Data Sync Agent and some scenarios where these tools can be implemented.

Distributed Data Scenarios

According to the way data is distributed, its characteristics, update frequency and location there are multiple scenarios to solve each of these requirements. The following are some examples of how Data Sync could be used.

Data Consolidation in a Central Location

Imagine an organization which has several remote locations (branch offices) which could be point of sales where an On-Premise data base exists en each one. All the information in each location must be submitted to a central database (corporate office). If the central database is also an On-Premise database the common way to implement this requirement would be using replication using a central subscriber model. The following diagram shows this scenario.

Scenario 1: Central Subscriber using replication with On-Premise databases

For simplicity, the illustration only shows a conceptual architecture however several components would be required to implement replication. You would need to configure 3 different roles: A Publisher, a Distributor and a Subscriber as well as the publications and articles. On the other hand, SQL Server must be at least a workgroup edition (whose replication features are limited) in order to publish data. Although replication is not difficult to implement, it requires some kind of knowledge not only to implement it but also to maintain replication working properly.

Having good connectivity is also important including band width, availability, latency, security, etc. If all databases are On-Premise, maybe you should use a VPN or another kind of secure connection between your systems.

Implementing common replication models using SQL Azure Data Sync

Another way to implement this requirement would be using SQL Azure as the central location. This way, remote locations would only need an internet connection and install and configure SQL Data Sync Agent which connects to SQL Azure Data Sync.

Scenario 2: Central subscriber using SQL Azure Data Sync

It is possible to implement many different scenarios using SQL Azure Data Sync. Not only to consolidate data in a single location but in the opposite way: distributing data from a central place to a remote location, a typical example would be to distribute products catalogs. Another scenario includes bi-directional synchronization where information can be maintained in any place (remote or central) and all changes can be applied to its counterpart. By combining these configurations it is possible to define more complex scenarios, for example re synchronize in more than one SQL Azure Database, implement read-only and read-write simultaneous, etc..

The following illustrations show these ideas:

Scenario 3: Central Publisher – Remote Subscribers using SQL Azure Data Sync

Scenario 4: Multiple Publishers – Subscribers using SQL Azure Data Sync

Scenario 5: Multiple Publishers – Subscriber with a remote subscriber in SQL Azure.

In fact, any possible combination can be implemented just configuring the SQL Azure Sync Agent. Also it is possible to select the data to synchronize (tables, and columns), filter rows using expressions and defining a synchronization Schedule.

Creating Databases

Before starting configuration, I will use the next Script to create a local database called SalesOnPremise with 2 tables and I will use the same script to create the same database with a different name (SalesOnCloud) to re create the same 2 tables. It is important to notice that SQL Azure does not support some transacts, so they must be deleted. The following script shows these conditions which are shown in the red boxes.

Here´s where the importance of  the function definition makes sense, the way partitions split or merge depends of the RIGHT or LEFT specification. The easiest way you can understand how they work is looking at the following examples. I will use a partition function with  LEFT specification, look at the process and the result after splitting and merging the table:

I already created a database PartitionDBLeft, this is how the database looks like:

And these are the definitions for partition schema, partition function and orders table:

In this case, the orders table is stored in a partition schema (psOrderDateRange) as well as the index. Also note that my primary key contains the columns OrderID plus OrderDate which is the partition key (the column by which the table is partitioned). When you create a primary key, SQL creates an index, usually a clustered index which sorts the table by that column. If the column OrderDate is not part of the primary key, you won´t be able to create a clustered key because in partitioned tables the sort order is determined by the partition key so you would need to create a non-clustered key instead. Later in this post you’ll see how important is this.

The partition function is defined using LEFT, now let´s insert some orders for 2008:

Now, let’s query the partitions, using the queries explained the Part 1, as you see the records are stored inside partition 1 (FG1)

Repeat the procedure inserting 300 for 2009 and 300 records for 2010, (just change the value for @OrderDate), this is how it looks:

Maybe you would expect to have 300 records for each year (2008, 209 and 2010) but the results are different, this is due to the function definition. When using LEFT, each value defined in the function corresponds to the UPPER limit of each partition which you can see in  the the column Max Value in the last query. On the other hand if you had use RIGHT instead of LEFT, the result would be the expected. By now, I will drop the table as well as the schema and the function and will define the function again this time using a different value for each range:

The schema will remain the same as well as the table, this time using the new partition function. After inserting the same records this is how it looks:

In fact, you could insert the dates ‘2008/12/31, 2009/12/31 and 2010/12/31 and those would be the limit for each partition:

Split a partition

According to the partition schema definition, If you insert a record for 2011, that record will be inserted in partition 4 which is the PRIMARY partition. Suppose you need to insert the orders from 2011 in a new partition (inside a new filegroup, let’s say FG4).  First, you have to add a new filegroup (FG4) and a new partition (an .NDF file) inside FG4:

Now you can modify your partition function to SPLIT the last range (which currently holds all records greater than 2010/12/31) to create a new range for orders from 01/01/2011 to 31/12/2010. Before doing so, you need to alter the partition schema to include the new filegroup (FG4) to let the partition function map the new range data to this filegroup, otherwise you will get this error:

The following script will alter the partition schema making FG4 the next available filegroup:

Now let´s alter the partition function to include the new range:

Now, check how the partition schema and partition function look after the change, you can use Management Studio to create the scripts:

This is the result:

This is the expected behavior in most of cases when you need to add a new partition in a rotating base of time to hold new data, in this scenario I would do it in december to prepare my orders table for the next year data. I can always use PRIMARY as the last partition for future data since I´m sure there will not be data there, however the partition function requires an additional range for all data that exceeds the last range value.

If I insert data between 2011/01/01 and 2011/12/31 that would be inserted in FG4:

For the next year, all you have to do is repeat the process, I mean: add FG5, alter partition function marking FG5 the next used filegroup and alter the partition function splitting the last range including 2012/12/31 and voilà, you have a new partition ready to hold 2012 records!

Merge Partitions

Now let´s talk about merging partitions. After some years, you decide all those partitions are difficult to maintain, it would be better to have all data for the first n years in a single partition. Let’s suppose you want to join all orders from 2008/01/01 to 20010/12/31 in a single file. Well, you can merge those 3 partitions but just 2 at time.

Merging is as simple as alter the partition function specifying the range that will be the new upper limit for the joined ranges:

Lets firs join FG1 and FG2 and see the result:

If you query the partitions, this is what you will see:

Note that all records from FG1 moved to FG2, now you only have 5 partitions instead of the 6 originals. and FG1 does not contains any data.

Now let´s join FG2 and FG3:

Let´s look what’s inside each filegroup:

Again, data from FG2 moved to FG3.

You can also check the reports included in management studio:

What about FG1 and FG2?. In fact, this filegroups are empty, you could use for future data, for other kind of data or you could remove them.

Switch Partitions

Now suppose you need to archive all data from 2008/01/01 to 2010/12/31 since this is historical data. At the current time, all this data is stored in FG3 which is now partition No. 1. By the way, If this data will never change anymore, you could mark this filegroup as READONLY:

This is not necessary to archive data but is recommended to protect historical information  against writing and to simplify backup strategy which I’ll discuss in another post.

The first thing you must be aware of is index aligning. Remember: if the partition key (OrderDate column) is part of the primary Key (OrderID + OrderDate) the index is aligned with the data. This means that each corresponding portion of the index is allocated in its corresponding partition because it uses the same partition schema and you can have a clustered index. If this is not the case (suppose your primary key is just OrderID), you can´t have a clustered index in the primary key because the data needs to be sorted using the partition key (which is Order Date) and you would have to create a non-clustered index in the primary key and all the index should be stored in a different partition (usually the PRIMARY filegroup).The main problem with this design is that you would need to drop the index before switching the partitions and then recreate the index after the switch operation but also, the process to move data from 1 partition to another (switch) would be slower. Fortunately our Orders table has a aligned index which you can see in the index properties window:

You can see the index is stored in the partition schema (psOrderDateRange) so it is aligned with the data.

In this scenario, I will move data from FG3 to a different table (Orders_History) which can be in the same or in a different database, I just want to archive those records and free space from my current database. Instead of write a delete query which can be slow and use a lot of transaction log space, I will simply move FG3 to a temporary table inside the same filegroup which will be very fast since only metadata will be moved and then I will transfer those records to the historical table which can be stored in the same or in a different database using an INSERT SELECT clause. Of course this will take some time but I can move it in a simpler way and without locking my production table or affecting my users.

The process is:

1. Create a temporary  table with the same structure from the original table (orders)  in the SAME FILEGROUP. This is necessary since you can only switch data from partitions located in the same filegroup.
2. Create the destination table (orders_history) with the same structure as the original and the temporary.
3. Switch the desired partition using ALTER TABLE clause
4. insert the data from the temporary table to the destination table using INSERT SELECT clause.
5. Drop the temporary table.

Let´s see:

This is my temporary table created on FG3:

This is my Historical table created in a different database, note I excluded INDENTITY since this value will exists in the source table.

The data I want to move lives in FG3 which is now partition 1. I just simply alter orders table this way:

What is surprising is that it doesn't matter how big partition 1 is, the data will be switched very fast!

Before moving the data to the history table, let´s query the partitions again:

FG3 has not any records.

All the data is now in the Orders_Temp table:

Now let´s move the data to Orders_History:

Finally, drop Orders_Temp table:

However you cannot drop FG3 because one range of the orders table is allocated in this filegroup, although you know there is not data there. However you can merge FG3 and FG4 this will release FG3 if you want to drop it. in the last query you can se FG3 boundary is 2010-12-31, so you can merge using this value:

If you query the partitions, FG3 is not used anymore:

Now you can remove FG3 if you want.

Conclusion

You can create a partitioning strategy in very large tables in order to simplify administration, enhance performance, create an archiving strategy to purge out data from the database and manage partitions merging or splitting them to provision space for future data. You must take care of table design and choose the correct partition key as well as index. If you make a wrong decision  it could be very difficult to manage future data. Try to reproduce the same examples in this post but now using RIGHT instead of LEFT and you´ll see what I mean. Also, try to create a table without the OrderDate column in the primary key to see how the index is built.

I hope you find this information helpful, If that´s the case leave me a message in the blog.

Thanks.

You can find much information about data partitioning on the Internet including the examples from MSDN and BOL, however there are important considerations you must care about and experiment with different data scenarios before implementing data partitioning in a production environment. This article focuses on these topics as well as partition management including split and merge partitions and the switch partition option.

Filegroups and Data Files

As you know, a database contains a data file (.MDF) and a transaction log file (.LDF), however you can add additional files to the database,these files are called secondary files (.NDF) and can be also use to store data rows. The files are assigned to filegroups in the same way the files are assigned to folders in the a file system, however, when assign several files to the same filegroup, data is distributed evenly  between all of them, in a round-robin way.To begin the example, let´s create a sample database called PartitionDB with 3 filegroups and 3 additional files (.NDF).

In SQL Server Management Studio, right click on Databases –> New Database. You can add the filegroups in the Filegroups page or you can add the files (.NDF) in the Files page and add the filegroup at the same time in the Files page. Just go to Files Page, click the Add Button, in the Logical Name column, type a name for the File, click on Filegroup column, select <new Filegroup> and type a name for the filegroup:

Define partitions

Now, we need decide how to partition our data. Is different the scenario where you want to partition a table which already contains data from a scenario where you are creating a new table. In the first case, you must be aware of the primary key in terms of how is build, which column (s) participate and the data types, you must also care about the unique  index which the Primary key builds automatically . In the case you are building a new table from scratch, you can decide how to create the table, the primary key and the partitioning strategy, in the first case you will be limited to what the table design allows.

In this examples we are going to create  2 new tables, the tables will simulate order information. The first example will implement partitioning by using OrderID as the partition column while the second example will use OrderDate. The partition column is called Partition Key and represents the criteria used to partition the information.

Partition Function

The partition function creates the ranges of data (partitions) according to values defined inside its body. This values are the boundaries which in turn produce the ranges. The function takes a data type as a parameter according to the column you selected as the partition key. When you define the boundaries for the partitions, you can use RIGHT or LEFT to define the limits of each partition.

LEFT means each value represents the upper limit for each range, in other words, each range goes from each boundary value to the LEFT.

RIGHT means each value represent the lower limit for each range but the first range will start to the right of the first value, so there will be an additional range  (the first range) and the first boundary value in the function defines where the second range begins.

To better understand,  suppose you have 10 000 records and want to create 3 ranges, the first range goes from 1-1000, the second from 1001 to 5000 and the third from 5001 to 10000. Since the partitions are based on numbers, you should pass a numeric datatype as an argument to the function.

Let´s create a function named pfRecordsRange in order to do this:

Note that the function uses LEFT for defining ranges, as I said before when using left each value represents the upper limit. 1000 is the upper limit for the first range, 5000 for the second and 10000 for the third.

If the first record starts in 1, this would be the lower limit for the first range (1-1000) , 10001 would be the lower limit for the second range (1001 – 5000)  and 5001 for the 3rd (5001 – 10 000)

But look, what if more records are inserted outside the limits? for example where would the record 10001 be placed?

well, in fact another range is automatically generated for all the records that are greater than the  last value defined in the function (>10000) and this will be the last range, so the record 10001 will be placed here.

Another question: If the value –1 would be inserted, where would it be placed?. The answer is: In the first range.

In fact the first and the last ranges have no limits, both have just one boundary, so consider  to add a check constraint in your table to restrict the values that can be inserted in these ranges.

Another important consideration: You will need an additional filegroup to hold the data for the additional range.  You will always need to consider 1 additional filegroup apart from those required by the function values. If your function includes n values, you will need n+1 filegroups.

This requirement is just to be sure the function will be able to place each partition in an available filegroup but it does not really mean there will be data for the last filegroup, so you could use the PRIMARY file group as the target for the last partition.

Returning to our example, If I use RIGHT instead of LEFT the first boundary value (1000) in the function would be the lower limit for the second range and the first range would include all records which are less than 1000, the last range would include the  number 10000, that is mean >=10000.

The following image shows the difference when using LEFT and RIGHT in terms of the ranges they produce:

If LEFT is used, the first value in the function will be part of the first partition. If RIGHT is used, it will be part of the second partition, also look how the ranges are defined in each case. So, the only difference is the partition each value belongs to. The symblos <,<=,>,>=, define this boundaries.

Right or Left?

This is a common question, and the answer is: it all depends how you want to define your partitions,  In my case, when I work with numeric ranges I prefer to use LEFT because usually I´ll want to include the upper limit in each range (1 to 10,, 11 to 20, etc.) however when I work with dates I prefer to use RIGHT because I prefer to define ranges by the start date not by the end date, for example If I want 3 partitions for each year (one for 2009, another for 2010 and the last for  2011) is easier to consider the start value for each range: 2009/01/01, 2010/01/01, etc. instead of the end range. Look at the script for this partition function:

Partition Schema

Once you have created the partition function, the next step is creating the partition schema. The partition schema uses the partition function to redirect the partitions defined by the function to the appropriate filegroups. Remember, if you have 3 values defined in the function it will produce 4 ranges (partitions).

In this case, assume we want a partition schema for the function pfOrderDateRange.

The schema would looks like this:

Note that I used PRIMARY for the last filegroup since no data will be stored here.

Partitioned Table

The last step is creating the table using the partition schema to store data in a partitioned fashion. When you create a table, you can define where to store the table (CREATE TABLE <name> (…) ON ). If you omit the ON part of the statement, the table will be created on the default filegroup which is usually the PRIMARY filegroup. In this case, we will tell the table to store the data in several partitions which is the job of the partition schema, so simply put the partition schema name after the ON clause and add the column name as the argument.

Before showing the script let´s talk about the primary key column.

When you add a primary key constraint to a table an index is also built on this column. The index may be clustered or non clustered (you can choose) but it must be unique. This unique index is used is to reinforce rows uniqueness. We will not discuss index structures here but remember this: if the Primary Key contains a clustered index, the table will be sorted using the index column (or columns). I f the Primary Key contains a non clustered index, an additional sorted structure will be created and the table data will remain as is.

Index and Data Alignment

The best practice when creating a partitioned table is to partition the index the same way you partition the data, this is called aligned index. But to be able to align index to data rows you must include the partition key (the column by which you are partitioning) in the index definition. If you do this, each index portion will be stored in the same data file (.ndf) where the corresponding data portion is stored, this way, if you query a table using a range expression (WHERE order date BETWEEN…), SQL Server will only use the corresponding index data for the query. The execution plan will be more efficient. Also, you can backup filegroups and create a more efficient recovery strategy because index are contained in the same filegroup. When indexes are aligned, You can move a partition to another table without moving rows just the metadata in just seconds!. It is highly recommended align indexes in order to benefit from this features.

Since this is the best scenario possible, lets create a primary Key for our table (orders)  using OrderID as well as OrderDate which is the partition key. Look at the script:

That´s all, now when you insert data into your table, each row is evaluated using the partition function to identify the corresponding partition, Partition schema will store the data to the corresponding filegroup using the partition function and the index will be stored in the same filegroups as the corresponding data.

Populate and Verify Data

Now let´s insert some rows in our table using this simple script:

I´ll run the script tree times, each using the values ‘2008/01/01’, ‘2009/01/01’ and ‘2010/01/01’ for the @OrderDate variable in order to insert 900 rows.

Finally, use the following script which uses the transact $PARTITION to verify how many rows are inserted in each partition as well as the data boundaries:

You can also view the table properties to verify data partitioning:

And look at the index properties:

If you wish, you can create the following view (taken from SQL Server 2008 Internals by Kalen Delaney, Paul S. Randal, Kimberly L. Tripp, and Conor Cunningham):

and then query the view to obtain the following results:

This view is similar to the other query but is very useful because you can also see the name of the filegroup and the name of the table where each partitions is stored,  you will appreciate this information when merging and splitting data, without this info, is difficult to see where the data was moved.

This is the simplest procedure for data partitioning, in the next post I´ll talk about split and merge data,  and what to do when you can’t align indexes as well as other scenarios.

Some times you need to create a  stored procedure with input parameters for working with rowsets instead of single rows.  For example, let´s say you want to process a bunch of customer orders all at a time. Usually you would write a stored procedure  with input parameters (OrderID, CustomerID, etc.) and would execute the stored procedure multiple times, once for each record you want to  process.

If you need to load 30 records into a table using this sp, you would have to execute it 30 times!. It´s no so good eh  
Fortunatly, SQL Server 2008 lets you use a table as an input parameter so you can fill this table with all the records you want to process and pass this parameter to the sp. You would only need to execute it once which is much better.  

The general steps are:

1. Create a user defined table type (UDTT) .
2. Create a stored procedure with input parameters (one or more) and be sure to use this UDTT for one of the parameters. Declare the parameter as READ ONLY which is required to process the table as an input parameter.
3. When executing the stored procedure, declare a variable of the UDTT type.
4. Fill this variable with some records and proceed to execute the sp passing the variable you just declared.
   

For this demo, I´m going to build a new table  using the following script:

This will be the target table where the info is going to be inserted. I have added a DEFAULT for OrderDate to simplify the demo, this way I will only need to work with 3 fields.

1. Create a UDTT:

2.  Create a stored procedure with an input parameter of OrderDate type:

3. Finally I can execute the stored procedure this way:

And here is the result:

Notice that since all records where inserted at the same time, they all have the same OderDate value. Now I´m going to show how to execute this stored procedure using ADO.NET. It´s very easy, there is a structured data type which can be used to work with table datatypes.

Lets see:

To begin, I have created a new project of type Console application, and I added a new class called Order:

Remember to include System.Data and System.Data.SqlClient namespaces.

When building the parameter for the stored procedure, dont forget to use the structured datatype for the parameter (@OrderList) as shown in the following screen:

When building the method, you can pass a DataTable as an argument in order to use it for the stored procedure parameter. You could also use a List, build a dataset, add a data table and populate it with the list, all inside the method. For simplicity I´m going to use a table and an XML file to load the data inside it.

Here is the complete code for the method inside the Order Class:

And this is the XML file: (OrderList.xml)

Finally, I can use this code to test the method:

And the orders are all inserted:

Now, you can process multiple records at once quick and easy.