I am considering upgrading to GoZync 4, but I wanted to verify how goZync 4 handles syncing calculations before I begin.

In my current setup, there are a few calculations in the hosted file that need to be synced to the mobile file. This is controlled in that setup by making the adjustment in the GoZync scripting not exclude calculation fields; and then including the calc fields on the zync layout in the hosted file, but not including them on the zync layout in the mobile file. This allows the values to get updated in the mobile file, but prevents the mobile file from trying to push the values back to the hosted file, which obviously won't work.

From what I'm reading, version 4 doesn't require the zync layouts in the hosted and mobile file, and that you can delete them. My question is then, how do you control for syncing calculations from the hosted file to the mobile file, but not from the mobile file to the hosted file in version 4?

Hi Dale. To synch a calc field in your mobile file to a non-calc field (e.g., text or number) in your hosted file (or vice-versa), simply place them on the Zync layouts in GoZyncMobile (in GoZync 4, the zync layouts are in GoZyncMobile, not in your files). As long as their names are identical and only one of them is a calc field (not both), GoZync will know what to do. There is no scripting involved. HTH -Jeff

jeffalmquist wrote:Hi Dale. To synch a calc field in your mobile file to a non-calc field (e.g., text or number) in your hosted file (or vice-versa), simply place them on the Zync layouts in GoZyncMobile (in GoZync 4, the zync layouts are in GoZyncMobile, not in your files). As long as their names are identical and only one of them is a calc field (not both), GoZync will know what to do. There is no scripting involved. HTH -Jeff

Thanks Jeff. Let me make sure I properly understand this, sorry if I'm being dense.

Zync layouts only exist in the GoZync files in v4. You do away with the Zync layouts in the hosted and mobile files.

For calculations, you would put the actual calculated field on the zync layout in the GoZync files (its non-calculated counterpart in the other file would not have these fields placed on the relevant zync layout).

Does this apply to all fields beyond calculations, that you now need to place them on the Zync layouts in the GoZync files? In v3 these layouts are empty, I just want to make sure this is the correct way to set things up. In the instructions for converting from v3 to v4, it states that v4 only uses the zync layouts in the zync files now, but it doesn't seem to specify that these layouts need to be populated with relevant fields. Perhaps this is implied, but I'd rather be certain than make assumptions before I go adding fields to all these layouts in v4.

Hi Dale,

No problem. Things are quite different in GoZync 4. In fact before I forget, here's a link to an article that will help guide you throught the migration:
http://www.seedcode.com/pmwiki/pmwiki.p ... romGoZync3

I'll try to answer your questions...

Zync layouts only exist in the GoZync files in v4. You do away with the Zync layouts in the hosted and mobile files.

Correct. Specifically, the Zync layouts are all in GoZyncMobile. That is, you set up "gzh_MyTable" and "gzm_MyTable" layouts in GoZyncMobile for each table you want to sync. All of the fields you want to include in the sync go on these "gzh_..." and "gzm_..." layouts. You don't add any Zync layouts to GoZyncHosted or to either of your files.

For calculations, you would put the actual calculated field on the zync layout in the GoZync files (its non-calculated counterpart in the other file would not have these fields placed on the relevant zync layout).

No. To sync a calc field to a non-calc field, place the calc field on the "gzh_MyTable" and its non-calc counterpart (with identical field name) on the "gzm_MyTable", or vice-versa.

Let me know if any of that doesn't make sense.

Jeff

Thanks again Jeff, I think I got it this time. Essentially v4 doesn't have any particular differential treatment of calc fields compared to regular fields like v3 did, you just slap any synced fields into the zync layouts in the zync files and you're done. Sounds easier, thanks!

That's right - as long as it's a calc field on one side and a "regular" field on the other (they can't both be calc fields). Enjoy!

I'm afraid I need to revisit this issue once more.

I moved forward with the upgrade to v4. However, after doing this, I am now experiencing problems with these calc fields already.

In the hosted file, there are 4 calc fields.

In the mobile file, there are 4 corresponding text fields to these calc fields.

One of the work flows is that records get created in the mobile file. When created, the fields corresponding to the calculations would be empty. However, when I attempt to sync these records back to the host file, which should be doing the calcs for these fields, I get:

0:00:00 - 0:00:06 - ERROR: 201 (Field cannot be modified) We couldn't set the field, "gzh_LineItem::field_concentration"
0:00:00 - 0:00:06 - Sync halted at record # 1 due to error. Incomplete changes were rolled back.

So this is a bit of a problem, it appears these calc fields aren't working as smoothly as initially thought.

I turned on field level merge, and this allowed the sync to go on through. However, I don't know that is the best solution here, since field level merge can be quite a bit slower.

Any other options here? Have I done something wrong? Or is allowing field merge the only solution here?

Hi Dale,

If I'm following correctly, then you don't want to have the text fields on the GZM layout. the GZM layout defines the push so it's trying to write the text fields to the calc fields in the host. The fields on GZH define the Pull, so having them there is correct.

Since you can't use the mobile layout to define those 4 fields you'll want to add them as script steps to the Custom Field Mapping: Transformation and Hooks script as we have here:

http://www.seedcode.com/pmwiki/index.ph ... eldMapping

Let me know if that helps,
Jason

JasonYoung wrote:Hi Dale,

If I'm following correctly, then you don't want to have the text fields on the GZM layout. the GZM layout defines the push so it's trying to write the text fields to the calc fields in the host. The fields on GZH define the Pull, so having them there is correct.

Since you can't use the mobile layout to define those 4 fields you'll want to add them as script steps to the Custom Field Mapping: Transformation and Hooks script as we have here:

http://www.seedcode.com/pmwiki/index.ph ... eldMapping

Let me know if that helps,
Jason

Thanks for the advice. Having actually used the field level merge a bit, I have found it to be far faster than even the non-field mapping sync on this particular table from version 3 of GoZync! So for the time being, I am content leaving the field level merge turned on. Should my needs change, I will revisit this thread again. Thanks so much for your time!

Hi Dale,

Right, depending on the table configuration and what you're syncing, FLM can be faster, but it's really a sweet spot situation that's different for every case. Glad it's giving you a pick-up!

However, the FLM is based on just the fields that have been modified to get pulled, and I know I haven't tested that with calc fields, so you may want to double check that those changes are getting picked up when you pull.

Thanks!

JasonYoung wrote:Hi Dale,

Right, depending on the table configuration and what you're syncing, FLM can be faster, but it's really a sweet spot situation that's different for every case. Glad it's giving you a pick-up!

However, the FLM is based on just the fields that have been modified to get pulled, and I know I haven't tested that with calc fields, so you may want to double check that those changes are getting picked up when you pull.

Thanks!

Thanks Jason, I can verify that FLM does indeed pick up the calc fields and syncs them to the text fields; I also changed the values in the calcs several times, and each time I ran the sync the changes appeared to come through. So it looks like I'm in good shape for the time being!