Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Synchronize Your Databases with .NET Web Services (Part II)  : Page 3

When data gets created in many locations, you often need to create a process that collects and copies this data to multiple sites. In this article, you'll see how to use Web services to automatically synchronize remote databases in a decentralized way, by letting each machine query the others until they all contain the same data.


advertisement
The Synchronization Web Service
The Web service used for this example is similar in concept and outline to that discussed in Part I of this article series. The class file (named getlogstable.asmx in the winforms-app\WebService folder of the sample code) has the following format:

<%@WebService Language="VB" Class="SynchIISLogs"%> Imports System Imports System.Data Imports System.Data.SqlClient Imports System.Web Imports System.Web.Services Imports System.Configuration <WebService(Description:="Synchronize IIS Logs Tables", _ Namespace:="http://yoursite.com/webservices/synchiislogs" _ )> Public Class SynchIISLogs ... class implementation here ... End Class

Deciding How to Return the Data
The sample Web service in Part I of this article returned a DataSet containing only a single table. However, you can add more than one table to the DataSet before returning it to the client application. There are downsides to this approach, though—it means that if an update fails you have shifted a lot of data that may not be used. By fetching each table separately and halting the process when the first failure occurs, you reduce the bandwidth requirements. Using smaller DataSets also minimizes the risk of time-outs in the Web service.

On the other hand, partial updates can cause data errors. If you copy rows from one table, but then an error occurs in another table (or in rows encountered later in the first table), the target database will not contain a valid set of rows. The ideal solution to this is to use a connection-based transaction in the client application, so that you can roll back all the updates to all the tables if any error occurs. But that means keeping the connection open throughout the entire process, rather than closing it after fetching each individual table's rows and inserting them into the database.

The end result is a compromise that can use multiple tables, but doesn't have to. The sample Web service can accept a comma-delimited string of table names. By parsing that string and running queries, the Web service builds and returns a single DataSet containing the appropriate rows from each specified table. If the request string contains only one table name, the code fetches and returns only that table in the DataSet.

Allowing clients to collect all the rows for all the tables they need to synchronize in one request, makes it possible to build efficient client-side applications that can hold the connection open and perform all the updates to all the tables within a transaction. Then, after all the updates have succeeded, they can either commit or roll back all the modifications.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Thanks for your registration, follow us on our social networks to keep up-to-date