Mark Stuller Posted June 8, 2017 Share Posted June 8, 2017 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 Link to comment Share on other sites More sharing options...
Jesse Barnum Posted June 8, 2017 Share Posted June 8, 2017 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. Link to comment Share on other sites More sharing options...
Mark Stuller Posted June 8, 2017 Author Share Posted June 8, 2017 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 Link to comment Share on other sites More sharing options...
Jesse Barnum Posted June 8, 2017 Share Posted June 8, 2017 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. Link to comment Share on other sites More sharing options...
Mark Stuller Posted June 12, 2017 Author Share Posted June 12, 2017 Thanks Jesse Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 2510 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now