In short: time, effort and cost. If you need to synchronize a Microsoft SQL database with multiple mobile clients SyncStudio will take care of the complete synchronization task for you. For Software Developers, this translates into 100's of hours of work, including the need to write the mobile client synchronization code from scratch. Off-loading the synchronization code and task to SyncStudio will let you concentrate on writing a great app and will get your product to market much faster and cost you less.

SyncStudio is dramatically more enhanced, robust, up to date and reliable than the Microsoft Sync Framework.  While SyncStudio does use the Microsoft Sync Framework as its base we have made significant improvements which result in a totally transformed solution.  A solution that saves you time, money and effort. While the Microsoft Sync Framework is free it is also a very a low-level developer’s tool, and not a simple one to learn or master. SyncStudio insulates you from having to learn anything about the MS SyncFx and from having to write even one line of synchronization code (server or client side).

When a client synchronizes for the first time SyncStudio will detect the fact that the database does not exist and will download the database Schema from your server and create an equivalent database structure in SQLite, SQL LocalDB or SQL Server. With SyncStudio, deploying the database schema to your client devices is completely transparent and does not require any coding or development effort on your part.

Yes. The SyncStudio Synchronization code runs under IIS. If you have a very large user base all you have to do is install multiple web servers and have them share the load.

The biggest source of maintenance issues and problems in Database Synchronization systems is the need to align the client’s database whenever you make changes to the database structure at the server. Some schema changes can cause database corruption and severe problems for your application if some clients are updated and some not. SyncStudio has an Automatic Schema Synchronization feature that takes care of this issue for you. All you have to do is follow some simple and common sense design rules when making changes to your data structures and SyncStudio will make the client Schema Synchronization completely transparent to your clients.

SyncStudio is licensed in several ways:  Free Developer License, Royalty Free and Production    For details please visit our product licensing page

Yes. You can because an authorized reseller and make money from every SyncStudio license you sell. For more information on our reseller program please contact sales@handapps.com.

Yes, please contact us at sales@handapps.com for special licensing arrangements.

Sorry, no. Every user must have a different User Id, otherwise they will interfere with each other and you will not be able to synchronize. If two of your users accidentally use the same User Id the only recourse is to have them delete the local database (you will lose any pending transactions), enter the appropriate User Id and Password for each one in their respective devices and re-synchronize. Please note that this should never happen during normal usage because every user should have not only a unique User Id, but also their own secret password, which they should never give to anyone else. Additionally, sharing User Ids is a violation of the SyncStudio licensing terms, since we license this product on a per-user basis. In other words, it is not allowed (or possible) to buy a 5-user license and then have 100 users by giving everyone the same User Id and password— it will fail, your users will lose any transactions that have been entered but not uploaded to the server and will be forced to re-synchronize with a full download.

Yes. Your server needs to have an Internet connection with access to the outside world, even if your clients will only synchronize over your own internal network (i.e., the case where the clients come back to the central office, connect to an internal Wi-Fi network and synchronize). The SyncStudio server-side component needs to verify the license from time to time to ensure compliance with the terms of the license. If you do not provide an Internet connection or if you block access to our licensing server SyncStudio will stop working.

SyncStudio transactions operate at the sync session-level. When a client synchronizes with your server, SyncStudio will not make any changes to the server until the entire upload session is finished without errors. Unlike SyncStudio, the standard Microsoft Sync Framework uses batch-level transactions that could leave your database in a corrupted state.

Yes. In this respect the only difference between Replication and full Synchronization is that in a Replication scenario you want the server data sent to the clients, but the client should never send any changes back to the server. Some typical uses of Replication are financial databases, news etc. that need to be sent to the client. In SyncStudio all you need to do to create a complete Data Replication solution is to mark the tables as Download-Only so that client changes are ignored. You still get the benefit of the synchronization mode in that the only records that are exchanged are those that have been changed at the server.

Yes. Data Collection applications are a bit special, in that you still want to synchronize one or more database tables, but you do not want any server records for these tables sent to the client; all you want is for the data entered at each client to be sent to the server. All you have to do in this scenario is to mark these tables as Upload-Only and SyncStudio will take care of it. Of course, you can always combine Bi-Directional, Download-Only and Upload –Only tables in the same database.

Unfortunately no. Private databases are not visible to other applications. The Stand-alone SyncStudio Sync Client only supports “public” databases.  When your application needs to have a private database then you will need to include the appropriate SyncStudio class library (,JAR in Android) in your project. This way you can call the sync functions directly from within your application.

Yes. Any change to the database structure requires that you de-provision the database. This is the reason that we developed the Schema Synchronization feature of SyncStudio, to ease the task of propagating Schema changes to the clients; however, it requires a de-provisioning.

Yes. All you have to do is create a separate profile for each database.

It loses all knowledge of the state of the clients. In practical terms, what happens is that the next time that your clients synchronize SyncStudio will first align the database structures (the Schemas) and then perform a complete sync of all the records, new and old alike.

If you absolutely need to make this type of change you should consider the following strategy: a) Have all the clients synchronize. Make absolutely sure that you have all the data. b) Tell your clients to STOP entering data. c) Have your clients DELETE the local database (if you are using our sample SyncStudio client there is a menu option to delete the local database. If you are using the API then you need to delete the database yourself). d) Make your Schema changes (please back-up your old database first). e) De-provision/Re-provision your server database f) Re-generate and re-deploy the code to IIS g) Have every client synchronize.

Generally yes, but there are a few limitations imposed by the MS Sync Framework. Your database cannot use special characters such as $ or spaces in field names, for example. Please refer to the SyncStudio documentation for the complete list of restrictions. If you have control over the database structures you should be able to work around these limitations by renaming fields and/or creating “companion” fields that can be synchronized.

Sorry, no. You cannot use auto-increment fields as primary keys. The reason for this limitation is that you will, in general, not have any control over the numbers assigned to new records at the client. If you use an auto-increment field for the primary key then two clients may use the same value and cause a conflict. Whenever you need to have primary keys that are automatically assigned you should use UUID (uniqueidentifier in SQL Server) fields instead of auto-increment fields.

The reason why we do this conversion is that SQLite does not have a date data type. Unfortunately, our choices for dates were rather limited, in that we could store dates as integers or as strings. We chose the string data type because it is the most flexible format and allows the maximum possible range of dates.

Yes. SyncStudio has full support for Foreign Key relationships.  Of course, all tables and fields involved in the foreign key relationship need to be part of the sync project.

No. If the changes to your database only affect tables that are not being synchronized, then you do not need to re-provision the database.

Generally speaking, Yes. If you are going to use HTTPS you must purchase a real certificate for your server from a recognized certificate authority.  A self-signed SSL certificate is not supported by most client device operating systems. If you use plain HTTP the data will not be encrypted so keep this in mind for security reasons.  Furthermore, some cellular service providers will not allow the mobile device to access a URL that is not HTTPS.

No. A system administrator (or just a plain user!) can use the SyncStudio SMC to configure a complete database synchronization system, without writing a single line of code. So long as your client application does not require a private database, you can use one of the SyncStudio Sync Client application to synchronize with your database(s) and solve your synchronization problem with zero coding. There are Sync Client versions available for Windows, Windows CE/Mobile 6.5, Android, Universal Windows Platform and Xamarin Android.  The Sync Client sample for Xamarin iOS creates a private database.

Yes. SyncStudio has both sample Sync Client’s (with source) and a Sync API (Class Library) that you can add to your project.  SyncStudio API’s are available for Android, Basic4Android, Windows Forms, Windows CE/Mobile 6.5, Universal Windows Platform and Xamarin (Android/iOS). Client databases supported are SQLite and Microsoft SQL LocalDB, SQL Express as well full featured SQL. You are perfectly free to modify our sample clients to suit your needs, or you can use just the SyncStudio API and integrate the synchronization process into your application.

Yes. You can incorporate our Sync API into your application and keep full control over the user experience. In most platforms, this allows you to have a private database that is visible only from inside your application. Our Sync API is provided in the form of platform specific class libraries. Currently we support .JAR for Android JAVA and Basic4Android (B4A) and .DLL for Windows, Windows CE/Mobile 6.5, Universal Windows Platform and Xamarin (Android/iOS)

The SyncStudio Sync Management Console and Sync Web Services run on Microsoft Windows 7,8x,10,2012 and up. This machine needs to have IIS 7 installed and enabled, and have at a minimum the .NET Framework 3.5. The client side Universal Sync Client and SDK supports Android 2.33 and up (Gingerbread, API Level 10), Windows, Windows CE/Mobile 6.5, Universal Windows Platform and Xamarin (Andoid/iOS). The server database can be any MS SQL Server version (including Express) from 2008 R2 and above.  Yes, we support all versions up to and including MS SQL 2016. The client side database can be SQLite, SQL LocalDB, SQL Server Express or any other flavor of MS SQL

Yes. We have tested SyncStudio with several virtualization tools including VirtualBox (https://www.virtualbox.org/), VMWare and Microsoft Azure.  We don't know of any reason other virtualization environments should not work. For example, you can have your database only hosted in a virtual machine, or you can have the complete SyncStudio synchronization solution including the database hosted in the same virtual machine.

SyncStudio requires Android 2.33 (Gingerbread, API Level 10) or higher.

This can happen for a few reasons. One possibility is the table does not have a primary key. Another possibility is that the name of the table is invalid (i.e., it contains characters that are not allowed). Also, using SQL reserved words for table or field names is not supported.  Nor is naming the primary key field the same as the table name. Whenever this happens you will get a message box explaining the reason why the table cannot be synchronized. Normally, all you have to do is rename the table, fields or indexes that are causing the problem.

A sync session can fail for a number of reasons, the most common being data connection problems. SyncStudio uses a single-transaction during data upload or download.  So, if a sync session fails during upload the net result is that no records will be synchronized and no changes will be made to the server. If sync fails during download then no changes get made to the client.

This is due to a limitation of SQLite in which the “buffer” used to hold a table record is hard-coded to be 1 Mb max. Your only solution is to break-up the table and split the data fields between two or more tables, so as to stay under the 1 Mb limit.

You probably have a bad device or a corrupted database. One possibility is to delete the local database (please keep in mind that if you do this you will lose any new records entered at the client). Another possibility is that the client has entered data that cannot be synced. An example is a string field that is defined as 20 characters long at the server but where the client has entered 30 characters. Keep in mind that SQLite does not have any concept of size limits on string fields, so your application is responsible for these types of data checks. The same thing happens if you have a byte field defined at the server and the client enters a number too large to be stored in one byte. SQLite will happily let you do this, but SQL Server will reject it when you try to synchronize.

Rename the fields. If you do not have control over the field names your other option is to create a “companion” table with equivalent (but legal) field names, write a trigger to keep the two tables aligned and then sync only the companion table.