Initial Sync Errors

[Ocean West]

Built a new solution. Reset sync from scratch only syncing 5 tables 3 are bi-directional the latter are references and only push from HUB. 

On initial sync I am getting an error that one record couldn't be created in SPOKE because the UUID is not unique. The file SPOKE has one less record then the host. However the UUID field is unique - for giggles I cleared the UUID on the records and replaced them with a new UUID (and also reset any foreign keys in child records that were related) however even after initial sync on new clone the error persists, on different devices. 

insert operation for table Client node sync_customer on Gregg's iPad's Go_iPad 14.0.2 failed for source nodeId 'F06E23A4-4CB7-49A6-A3E1-894AABCA3D4B'. 
Record 'F06E23A4-4CB7-49A6-A3E1-894AABCA3D4B' from FileMaker Server xxxxxx.xxx/sync_customer could not be inserted to Client node sync_customer on Gregg's iPad's Go_iPad 14.0.2 because of an error 504: Value in field is not unique as required in validation entry options

Also I am getting errors on downloading the clone the file size is half the size it should be and thus corrupted and will not open. 

Another issue is before i was getting the error above during the sync on IOS or Desktop the sync would stop and FMP would quit - silently - And opening the file again the initial sync didn't resume it didn't know it had transpired.

S

[Ocean West]

ok found out that the reason wasn't the UUID field but some OTHER field that some how wasn't unique but the message above would be helpful if it would indicate what field spawned the 504 error.

-

also I believe that the issue with the corrupted clone may be a Safari bug on the desktop mac - when i try to download files using FireFox it seems to download and open just fine. Safari is about 1 out of 4 downloads is useable.

-

 

 

 

 

[Jesse Barnum]

FileMaker doesn't tell us which field causes the 504, so there's no way for us to report back which field caused the problem. We could deduce it by setting each field individually and committing the record after each set field operation, but then you'd wind up with a partially complete record that has either a blank value or invalid data.

Thanks for letting me know about the Safari issue - I haven't run into it myself, but I'll let other users know about that if they see the same behavior.

[Harry Catharell]

Interesting point regarding the file corruption and Safari

This was reported by us in this thread: http://fmforums.com/topic/97226-mirrorsync-download-url-file-corruption/

It was also being experienced on iPad and not just OS X desktop

This is still a very rare issue but has been far more reliable over the last couple of months - Whether this is down to OS X updates or to newer versions of Mirrorsync, I am not sure, but thought it worth a mention as we did submit a log file which may give you a lead ?

Cheers

Harry

[Jesse Barnum]

I've never experienced this problem myself, but I'm going to try installing El Capitan developer preview to see if that causes it.

Also, I did notice in Stephen's log files that two downloads were running simultaneously - it's possible that double-clicking the link could have something to do with this. I'll see if I can reproduce the problem that way.

[Harry Catharell]

Thanks Jesse and sorry to pester you but as I have you online, do you have time to review the reply I sent on ticket [#13763] ?

It is the AuditLog file which has grown too large and I need to know how to administer it

Cheers & thanks as always

Harry

 

[Jesse Barnum]

Hi Harry - I already responded in our issue ticket system; not sure why it didn't make it to you. Here's what I wrote:

 

It's safe to stop tomcat (using the c:Program
Files360Works360Admin.jar), trash the audit log directory, and then
start it back up. The only downside is that if there are record
conflicts from records synced prior to deleting it, those will need to
be manually resolved instead of automatically merged.

[Harry Catharell]

Thanks Jesse

email - can't live without it, can't live with it :-)

I'll get onto that - Is it worth keeping a copy of that directory at all ?

I don't want to hi-jack this thread but can you give me some idea as to how to stop the log from growing so large again ?

[Jesse Barnum]

It's a database of all every change made to every record on the hub - so it's inevitable that it will grow over time. We don't periodically clear it out, because we have no way of knowing whether somebody might try to sync a very old record and get a conflict, and we can only auto-merge those conflicting records if we have the audit log.

If you're not worried about users needing to manually resolve conflicts for records synced prior to today, I see no reason to keep that directory.

[Ocean West]

it looks like the os9 GM fixed the mobile Safari file download bug.

[Jesse Barnum]

That's a relief - it was a huge bug, it didn't just affect MirrorSync or FileMaker but all non-apple file downloads (such as zip files). 

[Jesse Barnum]

I was able to reproduce and fix the file download problem. I never experienced it myself because it only happens when doing multi-file downloads (my test database is single-file) and two users click the download link simultaneously.

It will be in the next public release. If you want this release sooner, let me know and I'll send it to you.

[Harry Catharell]

Hi Jesse

The errors are few and far between from our users and so I would be happy to wait

Cheers

Harry