NetTalk Central

Author Topic: Disconnected app fields?  (Read 3090 times)

Jane

  • Sr. Member
  • ****
  • Posts: 347
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Disconnected app fields?
« on: December 10, 2018, 04:43:53 PM »
I'm starting to lay out a new dictionary for an app which will start out life as a desktop app accessing MS SQL, but which I hope to extend to a disconnected PWA a few months down the road.

Is there any problem with declaring the string fields in the dictionary as CSTRING rather than as STRING?  I would prefer the interaction with the SQL server be as varchars.

Thanks.

jf

DonRidley

  • Don Ridley
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 729
  • donaldridley2011@gmail.com
    • View Profile
    • Email
Re: Disconnected app fields?
« Reply #1 on: December 11, 2018, 02:41:55 AM »
I don't see an issue.  The sync of data between the server and the disconnected app is performed by JavaScript via POST's?GET's.  The data is displayed with simple HTML. 
"Eliminate the impossible, whatever remains, however unlikely, must be the truth."

NetTalk 12.55
Clarion 11

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11155
    • View Profile
Re: Disconnected app fields?
« Reply #2 on: December 11, 2018, 04:19:33 AM »
no issue Jane.

Cheers
Bruce

Jane

  • Sr. Member
  • ****
  • Posts: 347
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: Disconnected app fields?
« Reply #3 on: December 11, 2018, 08:44:22 AM »
Thanks, guys!

Jane

  • Sr. Member
  • ****
  • Posts: 347
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: Disconnected app fields?
« Reply #4 on: December 18, 2018, 12:50:58 PM »
Another question.

The NT docs say that each qualifying table needs to have a GUID field.

Is there a problem if that field has a more descriptive external name (such as locationId) ?

Thanks.

jf


Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11155
    • View Profile
Re: Disconnected app fields?
« Reply #5 on: December 19, 2018, 02:03:32 AM »
>> Is there a problem if that field has a more descriptive external name (such as locationId)?

If you change the name then I think there's a user option you can use so the templates can identify it as the "guid" field.
ie
GUID
set to 1

That said, I obviously do all my examples and testing where the name is set to guid. So while the theory says "any name will do" in practice you'll be the one discovering all the bugs in the template where it's not smart enough to figure out the field name.

So, in short, yes you can, but I wouldn't necessarily recommend it.
"up to you" <g>.

cheers
Bruce

Jane

  • Sr. Member
  • ****
  • Posts: 347
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: Disconnected app fields?
« Reply #6 on: December 19, 2018, 08:24:39 AM »
To be clear, I'm talking about the "external name" for the field, not the "column name".  The only reason I ask is to make the table relationships a bit more obvious.

That said, if the templates will look at the external name then I think my feet already have enough scars and shooting them gratuitously over this sounds like an inadvisable strategy.

Thanks, Bruce.

Jane

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11155
    • View Profile
Re: Disconnected app fields?
« Reply #7 on: December 20, 2018, 12:29:12 AM »
>> To be clear, I'm talking about the "external name" for the field, not the "column name". 

yeah, but in a PWA the "external name" is in database.js - (ie in JavaScript) and although I _think_ I've been super diligent there, you'd obviously be the one to find out <g>.

>> The only reason I ask is to make the table relationships a bit more obvious.

The technique I use and recommend seems to work well;

a) every table has a "guid" field - that's the primary key.
So cus:guid is obviously a reference to the primary key field in the cus table.

b) all the foreign keys have the full name. So for example in the Invoices table there's
Inv:CustomerGuid

So reading the tables you can very easily "see" the difference between the PK field for this table, and the Guid fields for other tables. If the PK field was called Inv:InvoiceGuid,then you'd have InvoiceGuid and CustomerGuid and you'd need to mentally "know" this is the Invoice table to spot the PK field.

So, I would argue, that keeping the PK field to a consistent name makes it easier to read the table layouts if viewing the db directly. But of course that is subjective.

cheers
Bruce