User option GUID

[peterH]

I'm trying to assess the amount of work involved in making an existing app qualify for becoming 'disconnected'.
It's a fairly large app with many tables and they've all got a guid field already - problem is that these fields are named customer_id, item_id etc. (and fk_customer_id, fk_item_id when used as foreign keys). Changing the dictionary/database is not the big problem, it's all the hand code refering to these fields!

In a thread started by Jane ("Disconnected app fields?") on Dec 10 2018 I read about a user option called 'GUID' that can be set to 1 in order to identify the guid column in a table. However, Bruce wasn't sure if it's fully implemented.

So my question is this: has anybody used this option and does it work?

Peter

[DonRidley]

I don't know if you're using TPS or SQL but...

From the FM3 docs:

To prime a GUID field

AutoUP will automatically prime each empty GUID field it finds during upgrade. The field must be named GUID, or PRE:GUID and must be a STRING(16). NOTE: Not available for SQL files at the time of writing this doc.

Requirements for disconnected apps:  (From the NT Docs)

The logic behind these requirements are discussed below, but this is the checklist of requirements (for a Clarion app):

    Each table needs a GUID field - type String(16)
    Each table needs a GuidKey, marked as unique, on the GUID field.
    Each table needs three TimeStamp fields, all of type Real, TimeStamp, ServerTimeStamp and DeletedTimeStamp. These should have external names of ts, sts and dts respectively.
    Each table needs a ServerTimeStampKey key on the ServerTimeStamp field. The key is not unique.
    Each table needs a TimeStampKey on the TimeStamp field. The key is not unique.
    Whenever a record is updated, TimeStamp must be set to the current time stamp. In Clarion apps this is usually done with the NetTalkClientSync global extension template.
    Whenever a record is updated on the parent server, ServerTimeStamp must be set to the current time stamp.

Remember the GUID field has two strict rules.

    The contents of the field must NEVER be changed.
    Any attempt to populate it using other data should be avoided. It should contain pure randomized characters.

I hope this helps you,

Don

[peterH]

Hi Don,
Thanks for your reply. Unfortunately it doesn?t really address or answer my question.

Peter

[Bruce]

Hi Peter,

In theory the option is supported, but I'm not aware of anyone making use of it, and I'm not sure I'd recommend anyone be "the first" (although obviously you're welcome to be the first.) If there are issues I will try and rectify them as soon as possible, but I can't guarantee that you won't run into hassles. And there _may_ be a problem we can't fix - I don't know.

You say you have these fields already - are they String values or LONG values? and what backend are you using?

cheers
Bruce

[peterH]

Hi Bruce,

I understand what you're saying.

The fields are all true guids, string(16) and I'm using SQLServer.

A thought: could external name be used to ease the pain (setting external name to GUID)?

Otherwise, I may just have to "work harder, not smarter" :-)

Peter

[Bruce]

Hi Peter,

"true guids" meaning client-side guids right? Not the Ms SQL Specific server-side GUID data type?

>> A thought: could external name be used to ease the pain (setting external name to GUID)?

It would be the other way around. You'd use Guid internally and the other name externally.

Or maybe, be brave, try it out and let me know where it's not supported. Someone has to be first...

cheers
Bruce