Almost There but still returning duplicates.

[Peter Barfield]

So, after heaps of frustration I am almost there. However the one sticking point I am getting is the return of data to the host creates a duplicate record with the updated data. I suppose the question is Is that the way this is supposed to work? I would have thought there would have been just an update to the existing table data to reflect the changes. Now I have checked to make sure that the ES_Record_UUID is not empty and no both hosted and remote (read mobile) version have identical IDs ie one on mobile being child record UUID. So my next question is what could possibly be the answer to this. I have re invented the whole db. and started from scratch and same result so I am at a dead end and completely stumped with no further remedy in site. I suppose the positive is that it is at least "syncing" (pulling updated data back to the server even if it is a duplicate).

[bcooney]

You're missing something in your setup. If a mobile record is pushed to the server, and that record id already exists, then that record is updated (if the timestamp comparison test passes as true).

Can you zip your files and I'll see if I can find the flaw in your setup?

[Peter Barfield]

Thanks for the reply, I did some further investigation based on your reply and noticed that the portal on the easysync payloads on both hosted and mobile was showing related records from "unknown" so I changed that in accordance with the sample db both mobile and host i.e. I changed it to easysync_payload_details now when I do a sync I get a 101 error. Any thoughts on that one. If not I will zip and send them to you.

[bcooney]

Peter,

You do not have the recommended table occurrences structure. Each table that you wish to sync needs to be wired to the EasySync_Payload_Details table occurrence.

[Peter Barfield]

Barbara, Thanks for having a look at this issue for me I am truly appreciative however, I am a little confused. Am I badly misunderstanding something?  isn't the relationships I have exactly as laid out as per above? I am  syncing the one table and as I look at mine they look like the sample above. I know you have had a look and obviously there is a difference but I am just not seeing it. Yes you can call me stupid if you wish. :-)

[bcooney]

I would never call you stupid!

I do not see anything like the above in your host file. You have a table, "sync list," not sure what it's for.

[Peter Barfield]

Barbara. Thanks for not calling me stupid. (although I am ok with it) :-) The Sync list table is the data that is synced to the mobile device and conversely back from the mobile device (the push and pull).At this point (based on your reply) maybe this is where I am missing something in the way I am interpreting Tim's instructions or indeed the way this works. I assumed (there probably is the first error in my thinking) that if I had a table in this case the synclist I simply create a table occurrence with an ES_Prefix e.g. ES_Synclist, create the join from child record_uuid in payload_details to record _uid in ES_Synclist mirror that in both mobile and host and voila we have a sync "link". as below

Thanks for taking the time to help it is much appreciated. Hope you can throw some more light on my plight and tell me if I am thinking this through correctly.

[bcooney]

OK, my apologies. I didn't realize that the only table you're hoping to sync is "SyncList."

I do see that B64_sl_CusSigFi is not set as a text result calc in the mobile file. In the host file, they should be calcs, result text as well.

Edited July 27, 2015 by bcooney

[Peter Barfield]

Thanks for that tip Barbara, I remember changing to sort out another problem and forgot to reinstate them. That being the case I have duly changed them back but on sync I am getting the dreaded 101 error record is missing and it appears to be only picking up record 1 of 1 (When 3 records are present) the error occurs on the pull side as I see it. So if I wasnt pulling my hair out before I certainly am now. Any thoughts I just dont understand the record missing. What exactly is it not finding? As far as i can ascertain all fields are present 3 records are present so stumped yet again. Although oit is a good way too learn it can be very frustrating.

Thanks again hope yopu can shed some light on it.

 

[bcooney]

Found it!

You named the table occurrence "EasySync_Payloads_Details" rather than the singular, "EasySync_Payload_Details" in the mobile file. 

As you can see from the screen shot, the Pull Payload script "hard-codes" the TO names in the Set Field By Name steps. So, the 101 error couldn't find the field, given the misspelling of the TO.

-B

Edited July 28, 2015 by bcooney

[Peter Barfield]

Barbara, you are a legend. That has certainly done the trick. it's amazing what one little letter can do. It was actually duplicated in the host file as well so it must have been my brain thinking multiple payloads when creating the table occurrence.Who Knows? You know I never would have found that in a million years. Tried a sync and works beautifully.

Thanks again Barbara most appreciated.

[Peter Barfield]

Good news Barbara Im Back in the game.

Dont ask me how because i really dont know it has me beat. Anyhow, I have 2 questions i thought you might be able to help me with to hopefully complete the task. ES_EXCLUDE. Using this field I would like to exclude from a sync, records that do not match the operator login field in the sync table.(Do the ES_EXCLUDE fields have to match in host and mobile DB or is it specific to each table?) I am not sure of the syntax for this I thought Get(AccountName) = Table:Operatorlogin ID but that doesnt work as an unstored calc. I thought about the $additional_settings in the Set Variable $dyn_sql but thats not in my league(I Think). Also on this idea. If a user syncs and there are records which are not his ie another users record the other users records I assume stay in the sync "table" awaiting that user to log in and get the record is that correct?.

And finally the big question. What is the method involved to copy the B64 fields and the 2 container fields with signatures in them to another table? I can't use variables i assume as I have tried that. Do I have to export contents and then somehow re-insert them. This seems a long way round a short course. I'm sure there has to be a simple method but for me it eludes me.

Oops 1 other small question. Is there a method whereby once a succesful sync back to the server has been completed and the record is finalised from the mobile point of view that this can then be deleted from the mobile device?  (Iam thinking from what I can read that the easysync scripts delete the successful payload only)I have a field set whereby it is checked to say completed and I could run a script to delete those records accordingly however, if a successful sync hasnt occurred this could be catastrophic. (If I am thinking this through correctly)

Thanks again for your help.

[bcooney]

Peter,

Easysync obeys any RLA calcs that you've defined. For example, if you want a user to only have access to records that they create, set a view RLA for that table using Security, where AccountCreated = Get (account name). You don't need ES_Exclude for this. AccountCreated is a field set to auto-enter AccountName.

Now, onto the B64 fields. Why are you copying them to another table? Can you build a relationship? I suppose the question I originally had when I viewed your files is the purpose of the SyncList table. Notice how in Tim's example, there is no table built just to capture data that should sync. So, not sure what you're doing with SyncList. I haven't really spent time looking at your solution, but would suggest that you don't gather all the fields that you want to sync in a table. Build tables that support the entities that you need. Also, see Tim's suggestion to separate all container fields into a table devoted just to them. This way, if a field changes in a table, you're not also syncing a container. Containers are the albatross of sync solutions. You want to limit their presence in a payload as much as possible.

Thinking thru about when records can be deleted from mobile is a good idea (as space, esp if storing images) can be at a premium. You could build a script that runs on open in your mobile file that culls records based on a date (if older than 30 days and has synced). You could put that in the user's control, perhaps, and simply flag the record as "can be deleted."

Barbara

[Peter Barfield]

Barbara, Thanks for the reply.

1. Not sure what you mean by RLA calc but I assume any calc you can create it would obey. I think my point was more not so much who created the account but who will use the data in the field. So in other words eg someone in the office would create the job. "Bill" would be assigned the Job and "Bill" and only "Bill" would need to sync that particular job to his device. Thus using his login as the basis for excluding,  such as If (Get(accountname) not equal to "Bills Login" then exclude it from the Sync. The next part, as the day has progressed I have thought through and in my head have come to the conclusion that jobs should remain available to sync if not equal to, in this case "Bill".(Hope I am right on that one).

2. Yes, you ask a very pertinent question in relation to the synclist. That idea originated from a post in another forum (I Think) which suggested it would be a better way to go in that I was having a mountain of trouble syncing. That being said now that I have worked out the various problems so far I will in fact re - work this and go back to the original sync method and not use the synclist which was and is my preferred option as you quite rightly point out.

3. I thought that's how I would have to handle the deletion on the mobile. My only concern is, how exactly do you know the sync has occurred successfully for that record. As I said I can set a checkbox to say when a job has been completed and delete when checkbox is "active" etc. and the 30 day period should be more than sufficient. It's just that I obviously don't want any records deleted before a successful sync.

Thanks again

[bcooney]

1. http://www.filemaker.com/help/14/fmp/en/html/passwords.15.15.html#1028797

However, seems like you're creating records on the host file and pushing to mobile. Then, your restriction would be looking at the assigned to field, not created.

see: http://fmforums.com/forums/topic/28989-best-calculation-for-custom-record-privileges/

"Bills Login", oh my, what is that? I do hope that you're using FM's Security and not storing credentials in a table. 

2. Yes, I think your abstraction will not work out in the long term.

3. ES_Last_Full_Sync < ES_UTC_Time. EasySync is transactional. Either all records that should sync do so or none.

[Peter Barfield]

Barbara, Sorry I have given you a heart attack :-)

maybe it's my way of explaining things causing some confusion. No all users have been assigned to a privilege set in fm security obviously with restrictions and such. However, they all rest under the one privilege set for the "in the field" users. So using something like what Tim Suggests (as an example only) - If ( Get ( AccountPrivilegeSetName ) = "Sales"; 1; 0 ) which would exclude all those users whose privilege set is equal sales would be redundant in my thinking as it wouldn't isolate it to 1 user. As there could well be 30 users with that privilege set. So I am just trying to work out a way to isolate by an assigned to name for argument sake and sync only when a match from the mobile device account name = assigned to name in host. Hope this makes sense.

I have played with this idea but not sure as to the issues of re syncing -  I do not worry about who gets the sync data uploaded. On the mobile device,  script it so it only shows on the mobile device those records where the rule  - assigned to is equal to the account name. Then they can edit that data to their hearts content and re sync back. that's simple and it works. Here in lies my question.

I am thinking that the data stays able to be synced again to another device and will only become unavailable to other devices when a device sends back a change. (hope this makes sense). If this is the case then my above scenario is ok and workable.