EasySync mess up after changing occurrences names

[Lutmers]

Hi Tim and others,

 

Does anybody have experience with a situations where EasySync is going crazy because of some Table occurrences changes AND RESETS?

 

I'm mean, while testing I added some table occurrences, try to hook up more tables to sync. I broke the EasySync function. I tried to get back to the old situation but things got worse by the minute. A lot of 201 and 106 error for apparently no reason.

 

I have seen Filemaker doing that before with ExcecuteSQL. I than had to replace occurences to have this fixed... but today seems a bad day and noting helps :-(... Yes I did do a Wipe and reset and di clean the sync dates

 

Hope to here from you

 

Jeroen

[timdietrich]

Jeroen --

 

The 106 errors ("Table is missing") would indicate that the table occurrences aren't matching on the mobile and hosted sides. You might want to double-check their names and confirm that they are wired up properly.

 

The 201 error might be caused by the same problem. You might also want to double-check the permissions on the tables.

 

-- Tim

[Lutmers]

Tim,

 

I checked a million times... everything is equal. iPad does take records from Server but nog updates back.

I cleaned all up.. made new records... nothing... it's quite cumbersome as soon as EasySync decides to not play ball ;-)

 

Any ideas?

[timdietrich]

Are you still getting the 201 and 106 errors?

[timdietrich]

Two quick thoughts...

 

1. In the hosted database, check the relationships between "EasySync_Payload_Details" and the TOs that you are syncing. On the "ES_Table" side of the relationship, enable the "Allow creation of new records" option. (Do not set the the "Delete related records" option.)

 

2. Make sure that the TOs are named with the "ES_" prefix.

 

-- Tim

[Lutmers]

Tim and others,

 

I had checked all relationships, references, field names, TO's and ES_ prefixes, cleaned everything, check for old payloads and add new records... and was still left with 'funny behavior'.  One of them was that my largest table (70 fields) was not synced but generated not error's as well. I decided to rebuild, but since I would like to know what's was wrong I first did a 'break down' of existing tables. And some curious things happened. These are my findings up to now:

 

1. Corrupt fields break the sync?

Because I thought off field corruption I had FMPro rebuild the DB >> result: No change.

I created fully new tables - did all install steps - and COPIED 70 OLD fields to the NEW table... > result: EasySync did NOT work.

2. Within that new database I deleted 60 of the OLD field and where left with a table with 10 fields... > result: EasySync DID work.

 

2. One record left alone:

With a fully empty 6 tables, I added 4 records to a table... I did a Sync and.. > result: Only record 2, 3 and 4 were synced. record 1 was left alone.

(this record was NOT excluded). Was this an incident or what?

>> Have not tried to recreate situation yet

 

3. Sync problem when records made on iPad:

With everything fully new build with 6 tables to sync, I added records on the server side and synced .. > result: IPad received new data -> OK

I modified these records on iPad side and synced..> result Server was updated -> OK

 

With everything fully new build with 6 tables to sync, I added records on the iPad side and synced .. > result: Server received new data -> OK

I modified these records on the server and synced..> result Ipad was NOT updated -> 

 

Conclusion:

 

I agree with Tim when he states that most errors are human and support is mainly a reference to the documentation.

But I also find that: 

 

- it looks like renaming tables, fields and especially table occurrences is some how a possible breaking point;

- Field corruption (?) or larger tables (many fields) look like a possible breaking point;

- Am I still making a mistake, is it a bug or is it a logical choice that ipad added records are not update by the server?

 

ps. the 102 / 106 errors are gone since downgrading the 70 field table... there is something  in that table.

 

Looking forward to your thoughts..

 

Jeroen

[timdietrich]

Jeroen --

 

"it looks like renaming tables, fields and especially table occurrences is some how a possible breaking point;"

 

As long as the changes that are made are done consistently on both the hosted and mobile databases, then EasySync should work properly. The TO and field names have to match.

 

"Field corruption (?) or larger tables (many fields) look like a possible breaking point;"

 

Not sure what you mean by field corruption. However, when syncing large numbers of records, or records with large amounts of data (such as container fields), then there is always the possibility that FileMaker Go itself will run into issues - whether they are caused by the device itself (low amount of available memory, etc), iOS issues, etc. Unfortunately, we have no easy way of determining what those issues are, what the limitations are, etc. 

 

-- Tim