NetTalk 11.10 Disconnected App--External Name Prefix

[ljwilson]

I've got the latest NetTalk/JFiles as of today (2019-05-06) (C10.12799).

I'm working with an existing dictionary to make a new disconnected app. The dictionary has external names with prefixes in the dictionary (as in CUS:LastName would have an external name of cus_lastname). Server side is PostgreSQL 9.5; Disconnected Clarion App client side is SqlLite.

I've found if I drop the prefix in the external names (so instead of cus_lastname it would just be lastname) then all syncs as it should. But if I leave the cus_ prefix in for the external names then only the fields without the cus_prefix will sync (guid/ts/sts/dts sync fine--since they are new fields I left them as recommended without the cus_ prefix).

I see the json coming over from both sides correctly with the prefixes, but the server side fails to pull out the actual data from those fields, so it sends back to the client empty field data for any of the fields with the cus_ prefix in the external name.

What is the easiest way to fix this? Renaming external names for existing fields is not an option.

Edit: I've found that on the server side, I can work around the template generated code in a table's Sync Procedure by adding

jsonParameter.SetRemovePrefix(false)

right before

jsonParameter.Load(q:MyQueueName)

This overrides the jsonParameter.SetRemovePrefix(true) that precedes it. I tried unchecking the Remove Prefix for JFiles Global Extension, but that had no effect.

Not sure if this is a template bug or I'm missing a setting I should be changing somewhere.

Thanks...jack

[Bruce]

Hi Jack,

Indeed it's the "remove prefix" which is the issue, and your fix is likely the correct one.
The Sync stuff (out the box) always "removes prefixes" but it seems like the two ends are not agreeing on what the "prefix is". On the one side cus_ is treated as a prefix, on the other not.

I wish the whole "prefix" notation didn't exist, but alas it's something we have to live with. It does get complicated though when external names are used which themselves contain "prefixes" of a sort. 

There are other approaches to fixing this (changing the prefix char on the client side, and so on) but your fix is as good as any of them, and better than some other approaches.

Cheers
Bruce

[ljwilson]

Bruce,

Thanks for the explanation. I'll stay on this path then.

...jack