Summary:

10 tables consisting of 5.2k records to be synchronised - data going one way only from hub to spoke

1 table contains images and contains a little under 1k records

We get errors following the sync being run telling us that there were problems writing 5 image records

We wiped/reset the mobile device and ran the sync again

We got similar errors showing AGAIN that 5 images could not be written - but this time they were 5 different image records noted by the different PKs !

Details in attached screenshots

Any possible reasons for this or things that we should be looking for ?

Cheers

Harry

As a short addendum, I ran a sync onto an iPad2 to compare the sync timings and once again received an error regarding 5 image records which were a different 5 records than the previous two occasions identified in the prior thread !

Confused, I am !

screenshot attached

Harry

Edited April 30, 201510 yr by Harry Catharell

Could you please try the sync again, and assuming it fails again, immediately file a problem report by clicking the 'send problem report' link on the MirrorSync launch page in your browser? That will send us the server log file with much more detailed information.

Thanks Jesse - I will do this tomorrow (Friday) and get the result off to you

Cheers

Harry

New error log attached from this morning's sync and a bug report has been sent via the MirrorSync Launch page

Cheers

Harry

Got the log. There are two ways that MirrorSync can communicate with FMS: XML Web Publishing or JDBC.

It looks like the server is just returning an empty value intermittently when we try to retrieve container contents using the XML Web Publishing Engine. I don't know the answer here; it's got to be something related to the server itself.

What I would recommend is switching to JDBC and see if that fixes the problem. All you need to do for this is enable the fmxdbc extended privilege for the syncing user's privilege set. You also need to enable xDBC on the server, but in your case, this is already enabled.

Hopefully, switching to JDBC will solve the problem of the dropped container requests from the XML Web Publishing Engine.

Hi Jesse

Thanks very much for taking the time to check this

I will setup the extended privileges next week and give it a try and let you know here

Do I need to deactivate the xml extended privileges ??

Cheers

Harry

No, leave xml extended privileges enabled. We use a mixture of JDBC for some operations (when enabled) and XML for other operations.

Hi Jesse

Changed the privileges, ran a vanilla initial sync and there were no errors reported this time

However, the data appeared in the container fields in filemaker as blob data and does not seem to have been converted back into FM container data

See screenshot

Cheers

Harry

Harry, I responded directly to your ticket in our support system, but for anyone else reading this topic, the Binary object 'Untitled.dat' is a bug in this version of MirrorSync that we've fixed in our latest codebase. If you're running into this issue, message me and I'll send you an updated version.

Hi Evan

Thanks - I saw your support replies and have responded to one of them

I'll replay it here just in case your support emails are one way:

<snip>

 

I have a client who is looking for us to try to implement MirrorSync for them over the next few weeks and the image transfer is a deal-breaker for them

 

I understand your point about the build not being a stable release as yet but do you have any potential release date for it as I need to be able to manage client expectations at my end :-)

</snip>

Hi team

Just to let you know that we installed the new build this morning and testing successfully returned the images

Thanks for all of the help and let me know if we can provide any more information or feedback for you

We will continue to test and refine the processes and will let you know if anything else occurs

Cheers

Harry

We are in a position to start testing the MirrorSync solution with the client

It was mentioned that the new build that was given to us to resolve the image sync problem is not a release version as yet

So what do we do when we are ready to put the client live ??

Cheers

Harry

Go ahead and use the version we sent you, it will be bundled into version 2.406 at some point but I'm not sure when.

Thanks Jesse :-)

 

Harry

Hi All,

I am working with Harry on this same project. We have successfully used this build on our client server this morning and ran testing on desktop with no image problems - perfect!

However, when it was tested on an iPad, our original issue came back where we had an error 10 on 2 of our images. This time, it was only for 2 images and not 5 continuously cycling ones. 

Screenshot attached - I hope it is OK I have hidden sensitive information. 

Any help or guidance you can give on this would be greatly appreciated.

Thank you

Lewis

 

Edited May 22, 201510 yr by Lewis Stairs

Please send a problem report from the MirrorSync launch page so that I can look at the server log; it contains much more detailed information than the screenshot.

Hi Jesse,

I have sent over the logs. Ticket number:11874

We did try it on a local iPad (initial error occurred on client iPad) and it worked fine. We also tried again on desktop with no error. 

The original error occurred around 14:54 (BST) today. 

Thank you