Frequently asked questions

It saves time, effort and cost. SyncStudio handles the whole job of syncing a Microsoft SQL Server database with many clients, including the client-side sync code you would otherwise write from scratch, so you can focus on your app and get to market sooner.

SyncStudio is built on the Microsoft Sync Framework and adds the parts it lacks. The Framework is free, but it is a low-level toolkit that takes time to learn and leaves the device side entirely to you. With SyncStudio you don’t need to learn it or write server or client sync code.

You don’t have to. On a client’s first sync, SyncStudio sees that the local database is missing, downloads the schema from your server and builds it in SQLite, SQL LocalDB or SQL Server. No coding on your part.

Yes. The sync service runs under IIS, so for a very large user base you can run several web servers to share the load.

The hard part is keeping client databases in line after server structure changes. Automatic schema synchronization handles that: if you follow a few design rules when you change structures, schema updates are transparent to clients.

No. An administrator can configure a complete sync system in the Sync Management Console without code. If your app doesn’t need a private database, a sample sync client app can handle syncing with no programming.

There are three: the free Developer license, Production licenses and Royalty-Free licenses. See the licensing page for what each includes.

Yes. Authorized resellers earn on each license they sell. See the reseller program or email sales@handapps.com.

Yes. Email sales@handapps.com about licensing for a large user base.

No. Each user needs a unique user ID. Users who share one interfere with each other and fail to sync; fixing it means deleting the affected local databases, which loses any unsynced records. Shared IDs also break the per-user license terms.

Yes. Even if clients sync only over your internal network, the server needs outbound internet access to verify the license periodically. If it can’t reach the licensing server, SyncStudio stops working.

SyncStudio applies each sync session as a single transaction. The server isn’t changed until the whole upload finishes without errors. The standard Microsoft Sync Framework commits batch by batch, which can leave a database partly updated.

Yes. Mark the tables download-only. Server changes go to clients, and changes made on the client are ignored. Only changed records are sent.

Yes. Mark the tables upload-only. Client data goes to the server and server records aren’t sent back. You can mix bi-directional, download-only and upload-only tables in one database.

No. A stand-alone sync app can only reach a database other apps can see. For a private database, add the SyncStudio client library to your project and call the sync functions from your own app.

Yes, foreign keys are fully supported. Every table and field in the relationship must be part of the sync project, and you set the table sync order during provisioning so parent rows arrive before child rows.

Generally yes, within the Microsoft Sync Framework’s rules. Every synchronized table needs a primary key, and table, field and index names can’t contain special characters such as $ or spaces. If you control the schema, rename the objects or add companion fields.

Not for rows created on devices. Two clients could assign the same number and conflict. Use uniqueidentifier keys for automatically assigned values.

SyncStudio maps each server field to the closest client type: SQL Server integer types become SQLite Integer, floating-point types become Real, and strings become Text. Geography and geometry fields can be synchronized when the client database is SQL Server or SQL LocalDB, but not to SQLite clients. Timestamp fields can’t be synchronized.

SQLite has no date type. Strings were chosen because they are the most flexible and cover the widest range of dates.

Yes, if the change touches a synchronized table. Any structure change to synchronized tables, or to which tables and fields you sync, means de-provisioning, changing, re-provisioning, and regenerating and redeploying the server code. Schema synchronization then carries the change to clients.

No. Changes that affect only tables you don’t sync don’t require re-provisioning.

The server loses its record of each client’s sync state. On each client’s next sync, SyncStudio first aligns the schema, then does a full sync of all records.

Have every client sync and confirm all data is on the server; ask clients to stop entering data; have clients delete their local database; back up the server database and make the changes; de-provision and re-provision; regenerate the code and redeploy it to IIS; then have every client sync.

Yes. Create a separate sync profile for each database.

Generally yes. Install a certificate from a recognized certificate authority, because most client operating systems reject self-signed certificates and the sync will fail. Plain HTTP is unencrypted, and some mobile carriers block non-HTTPS traffic.

Yes. You get the sync client libraries plus sample sync clients with source code. Modify the samples or integrate just the library.

Client libraries are available for Android, iOS, Basic4Android, Xamarin, .NET MAUI and Windows. Supported client databases are SQLite, SQL LocalDB and SQL Server, including Express.

Yes. With the client library you keep full control of the user experience, and on most platforms your database stays private to your app. The libraries ship as a .JAR for Android and Basic4Android and as .DLL files for .NET platforms.

Windows 10 or 11, or Windows Server 2019 through 2025 (2025 recommended for production), with IIS 10 or later and .NET Framework 4.0 or later (4.8 or later recommended). The server database is SQL Server or SQL Server Express 2019 or 2022. Code generation needs Visual Studio Build Tools 2019 or 2022, or a full Visual Studio license. See documentation for details.

Android 9 (Pie, API level 28) or later.

No. The SyncStudio installer downloads and installs the Microsoft Sync Framework 2.1 components if they’re missing.

Yes. Virtual and physical machines are both supported, and you can host just the database or the whole solution in a virtual machine.

Usually one of these: the table has no primary key; its name has disallowed characters; it uses SQL reserved words as table or field names; or a primary key field has the same name as its table. A message explains the specific problem, and the fix is usually to rename the table, field or index.

Usually it’s a data connection problem. Uploads and downloads each run as a single transaction: if an upload fails, the server is unchanged; if a download fails, the client is unchanged.

SQLite’s record buffer is limited to 1 MB. Split the table’s fields across two or more tables so each record stays under the limit.

The device may be faulty or its database corrupted, or it may hold data the server rejects, such as 30 characters in a 20-character field. SQLite doesn’t enforce field sizes, so your app should validate data. Deleting the local database fixes corruption but loses unsynced records.

Rename the fields. If you can’t, create a companion table with valid names, keep it current with a trigger and sync only the companion table.