“But does your solution integrate with…?” This is one of the top questions that application developers hear today, as customers want to ensure that new solutions preserve previous investments in applications and hardware. For many application developers, the “integration question” becomes an “integration nightmare” as they struggle to integrate their applications with disparate systems, such as third party databases, application servers and enterprise applications.

Whether you are synchronizing one database or one thousand,this tutorial is for you. 

So what is synchronization…

To us at iAnywhere, synchronization is the idea of sharing information between a consolidated or central database and a number of remote databases not permanently connected to that consolidated or central database.

Typically what we would see in a synchronization environment is an administrator who would choose to publish or synchronize a subset of the consolidated databases’ information to his/her remote users, thus allowing the remote user to be disconnected but still have access to their pertinent information.

For various reasons, such as data transfer costs and security, the majority of users and organizations tend to synchronize only a subset of the corporate database’s data.

The subset of information would either be defined by the administrator or by the actual remote client, i.e. an occasionally connected user may wish to subscribe to a specific section of the data to be downloaded to him/her.

Regardless of the type of connection - wired or unwired, synchronization offers many important benefits over a permanent connection:

• Fast Data access to remote users

• Increased control over data availability

• Reduced data load on the corporate server

Both connectivity models are supported within the Mobilink Synchronization Server, a component of SQL Anywhere Studio that is available on the front cover of this magazine.

Why do I want to Synchronize?

A reason that most people would not necessarily first think of when they think of synchronization is where a branch office is involved.

Imagine an insurance company that has different offices throughout the country or maybe even global.

Those branch offices will need access to information that is typically stored at the corporate head office.

Now of course, you could have some form of persistent network connection from that branch office to the corporate office to access the main database, but in some cases that is just not viable or realistic, so in those instances what you might want to do is synchronize the information down to a local database which is required by that branch office for its day to day operations.

This would allow the branch have a client server type of connection and make changes to the local branch office database. These in turn will then be synchronized back up to the main corporate database.

The second reason, is probably one that most people would think off,  which is to allow your remote and mobile users to have information on their laptops or handhelds, so as they do they work out of the office, they still have access to all the information and resources as they would when they are in the office