How Windows Mobile 6.5 Synced Databases When Docked

When a Windows Mobile 6.5 device was placed into a docking cradle, it initiated a synchronization workflow that bridged local embedded database files with enterprise database servers. This process leveraged desktop synchronization software to establish a network pass-through connection, allowing the handheld's local database engine—predominantly Microsoft SQL Server Compact Edition—to communicate with backend systems like Microsoft SQL Server through Internet Information Services (IIS) using technologies such as Merge Replication or Remote Data Access (RDA).

1. Connection Establishment via Desktop Pass-Through

Docking the device via USB or a proprietary cradle physically triggered the host operating system to establish a connection using either Microsoft ActiveSync (on Windows XP) or Windows Mobile Device Center (WMDC on Windows Vista and Windows 7).

Using the Remote Network Driver Interface Specification (RNDIS), the docking software created a virtual network adapter. This provided the mobile device with a "pass-through" IP connection, allowing the mobile device to route TCP/IP traffic directly through the host desktop's corporate local area network (LAN) without requiring direct Wi-Fi or cellular data connections.

2. The Local Database Architecture

Enterprise applications on Windows Mobile 6.5 typically stored offline operational data in Microsoft SQL Server Compact Edition (SQL CE, versions 3.1 or 3.5) files, which used the .sdf file format. Because SQL CE was an in-process, lightweight database engine running directly within the application's memory space, it could not accept direct remote connections. Instead, it relied on dedicated synchronization APIs included in the SQL CE client agent to bundle and transport local data modifications.

3. The Middle-Tier Synchronization Gateway

Windows Mobile devices did not communicate directly with the enterprise SQL Server on port 1433 due to security, bandwidth, and protocol limitations. Instead, synchronization was brokered by an intermediate web server running Microsoft Internet Information Services (IIS).

On the IIS server, a specialized ISAPI filter called the SQL Server Compact Server Agent (sqlcesa35.dll) processed incoming synchronization requests over standard HTTP or HTTPS protocols.

4. Synchronization Mechanisms: Merge Replication vs. RDA

Enterprises primarily used one of two mechanisms to exchange data between the local .sdf file and the central database:

  • Merge Replication: This was the most robust and common approach. SQL Server maintained tracking tables and triggers on the enterprise server, while SQL CE tracked row modifications locally using internal generation counters. When docked, the mobile application invoked the SqlCeReplication object. The client agent packaged change sets (deltas), compressed them, and sent them via HTTP/HTTPS to the IIS server agent. The server agent handed the data to the SQL Server Reconciler, which handled bi-directional schema and row updates, resolved any conflicts based on predefined business rules, and returned the latest server changes back to the device.
  • Remote Data Access (RDA): A simpler, programmatic alternative using the SqlCeRemoteDataAccess object. RDA allowed the application to execute direct Pull and Push commands. A Push sent local tracked changes to the central database, while a Pull executed an SQL query on the server and downloaded the result set as a new or overwritten table in the local .sdf file.

5. Automated Execution and Completion

The sync routine was executed either automatically upon docking or on-demand by the user. ActiveSync/WMDC could be configured with custom synchronization service providers (ActiveSync plug-ins) that detected the dock event and launched background sync utilities. Alternatively, mobile line-of-business applications monitored network availability notifications from the Windows Mobile Connection Manager; once the desktop pass-through network was detected, the application triggered its synchronization thread, committed the changes to the local .sdf file, and displayed a completion status to the user.