Harry Catharell

Members
  • Content count

    74
  • Joined

  • Last visited

  • Days Won

    1

Harry Catharell last won the day on October 14 2015

Harry Catharell had the most liked content!

Community Reputation

1 Neutral

About Harry Catharell

  • Rank
    member
  • Birthday

Profile Information

  • Gender
    Male
  • Location
    Milton Keynes, UK

FIleMaker Profile

  • FM Application
    13 Advanced
  • Platform
    Cross Platform
  • Skill Level
    Expert
  • Certification
    7
    8
    9
    10
    11
    12
    13
  • Membership
    TechNet
    FileMaker Business Alliance
    FIleMaker Platinum Member

Recent Profile Visitors

1,055 profile views
  1. One of our clients has an internal FM server [FMS1] running a solution that we built for them and we have a cloud based FM Server [FMS2] running another solution for them with a smaller dataset that they publish to their own clients Data is periodically pushed to and pulled from FMS2 using server schedules that run on FMS1 and trigger very simple scripts to manage the movement of data This was all running without issue whilst both servers were FMS v14 Last week the client upgraded FMS1 to FMS v15 and since that point in time the scripts have been failing when FMS1 has been trying to update data from FMS2 which is still running FMS v14 Any ideas or guidance or questions ? Cheers Harry
  2. Thanks Jesse We use simple auto incrementing primary keys but there is a process which moves data to be updated into the hub so it looks like what we are saying here is that there is a problem at source in moving this data :-) I'll check on the processes involved ..... Cheers and thanks Harry
  3. I have reported this through the bug reporting system ( ticket number: 13920 ) but wanted to add the screenshot of the error that I received running an incremental backup this morning Everything had worked perfectly until this morning and then we got the duplicate record error I understand the problem and how to remedy it but wonder if there are any reasons why the duplication would exist and whether I need to test for errors like this as part of a maintenance routine of some description ? Cheers Harry
  4. Hi Jesse The errors are few and far between from our users and so I would be happy to wait Cheers Harry
  5. Hi Jesse Apologies for delay in getting back to you Thanks for the heads up I will get that config change made as soon as possible Cheers Harry
  6. Reported a sync error and have ticket: 13886 issued and following that up with the screenshot from my remote device when sync was run Apologies as I think that one of my colleagues reported a similar error a while back but he is on holiday at moment until next Monday Cheers Harry
  7. Got it this time :-) I have replied to your ticket response - let me know if you don't get it :-) Harry
  8. Hi I have reported this error to 360Works on tickets: 13763 & 13801 but in the interim wondered whether anybody else had ever seen the error shown on the attachment and typed below: 'Communication Error With Server' 'Error from server: problem with log file: - file check mismatch - 26318877' Any help or response much appreciated whilst I wait for the wonderful people at 360Works to reply Cheers Harry
  9. Hi Many apologies for the 'bump' on this but I have a client chasing me for an update and a resolution I just want to stop Mirrorsync and remove the log folder and then restart but I worry about the potential conflict resolution issue that was raised and it may just be that I am not understanding the point being made The original advice from Jesse was: It's safe to stop tomcat (using the c:ProgramFiles360Works360Admin.jar), trash the audit log directory, and thenstart it back up. The only downside is that if there are recordconflicts from records synced prior to deleting it, those will need tobe manually resolved instead of automatically merged. If I follow Jesse's advice, will users be able to sync again ? When would a conflict occur which may require the older log data ? Apologies for the 'doh' questions Cheers Harry
  10. Hi Jesse I did not want to leave this on the other thread regarding the initial sync errors so thought that I would continue to ask questions on here as I do not seem to getting any replies via the ticket system responses as you remarked You answered regarding the removal of the AuditLog directory: 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. And I had two questions on the back of this: 1) We sync only one way - from hub to spoke - so would there be any conflict in this scenario ? 2) Would users receive a sync error based around any conflicts ? Sorry to be a pest but the site has not been syncing for two days now Cheers Harry
  11. 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 ?
  12. 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
  13. 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
  14. Hi Jesse Thanks for the feedback I will run this by the client and ask them to decide We do the grunt work, they pay the bills :-) Cheers Harry
  15. Our client has asked whether there could be any cosmetic or branding changes made to the bug reporting web page to make it less obvious that it was a 360Works page ? Their reasoning is that remote users are unaware of the connection to 360Works and may find it confusing to be using a branded FileMaker solution and then be taken, on the rare occasion that any error requires a bug report, to a page showing another supplier name I said, that I would post the request :-) Cheers Harry