Hello

We have frequently observed this error. We are curious if 360Works knows if this has been fixed in FMS 16.

We are interested in knowing if there is something about the content of the records this affects that we could avoid while retaining the JDBC sync. Also interested if, or how much, switching to XML affects the client's sync. Duration only I suspect. I'd assume the switch to XML is a 'server side' change only and does not require a client update. Let us know if that is incorrect.

• update operation for table FileMaker Server xxxxx failed for target nodeId '1B207AE7-4063-4BF9-B450-62522235B189'. 
A bug in the FileMaker JDBC driver prevented record '1B207AE7-4063-4BF9-B450-62522235B189' from Client node xxx on xxxx from being written to FileMaker Server xxxx. You can delete this record and retry the sync, or you can switch to XML for the sync. Please report this problem to 360Works so that we can forward it to FileMaker. [1 more warnings like this]

Thanks, Mark

Hi Mark - yes, you can safely switch between XML and JDBC on the server without needing to distribute new offline files. Keep in mind that the method for filtering records is completely different, so if you did switch, you should first set up your MirrorSync customization script to do the same filtering as your SQL qualifiers with JDBC.

The bug with the JDBC driver does still exist, although for most of our clients it seems pretty rare.

Thanks Jesse. I was hoping this was the answer.

Any tho't on if there is an issue with the content to the records that precipitates the error (so that we can avoid it)?

Any any idea on the 'efficiency' angle? Say, is XML a ##% slower sync generally?

Thanks again. Mark

No, I don't have any solid benchmarks. And JDBC is not always faster either. JDBC slows down a lot if 1) MirrorSync is not on the same LAN as FileMaker Server, or 2) if you have a complex SQL qualifiers, or 3) you have any SQL qualifier at all with a very large (millions) total record set.

Thanks Jesse