You should make sure you have version 11.3.81 of the JDBC driver installed. I don't know if SyncDek has a way of displaying the version number of the JDBC driver it is using. To be sure it is using the right one, you should search your hard drive for the file named "fmjdbc.jar", and use Windows Explorer or the Finder to verify that it is 126,175 bytes in size.
If you continue to have the problem, I suggest that you narrow down the table / field / value as much as you can (i.e., make a copy of your FM database and remove as much data as possible while still reproducing the problem). The WorldSync folks are very, very good - I expect that they have diagnostic tools to help narrow the problem even further (perhaps to an API call).
If it turns out to be a problem with the JDBC driver, you should post as much detail as possible (with the smallest reproducible case) to the "Report an Issue" forum.
We've talked about the 11.3.81 drivers in the other thread; I'll add that the server is maintained by the IT department and I don't have sufficient access to the C: drive to search for fmjdbc.jar.
I've been exchanging emails with the WorldSync people and trying to pin down the culprit. I've also been talking with the server admin who did the 11.0v3 upgrade, and he said it's possible the SyncDek process wasn't shut down properly when the upgrade was running, and that might have interfered with the xDBC driver install; if we're still having problems by tomorrow afternoon, we may try re-installing 11.0v3 and making sure SyncDek is turned off first.
I've spent pretty much the entire day trying to debug this, watching for fmxdbc_listener.exe crashing and SyncDek hanging and restarting them when necessary; at first the sync appeared to be hanging at the same place every time, but as the number of attempted syncs has built up, it isn't looking nearly so cut-and-dried. Many times the fmxdbc crash happens at the very beginning of the sync process, before SyncDek even starts publishing. Sometimes it gets 10-20 records in before crashing. A couple of times, it's gotten through 5000-6000 records in the main table before crashing. So far, it's always crashed on the main table, which is the most complex (253 fields) in the solution; it has 170,000+ records, which also makes it the largest table in the solution, but others have ~50,000 records and SyncDek has handled 20,000+ record updates there without choking.
To follow up: After some great detective work with the WorldSync team, it appears the problem was caused by an interaction between the new xDBC drivers in 11.0v3 and the way SyncDek was optimizing its xDBC calls. They've put together a new version that works around these issues, and it appears to fix the problem for us here.