Disconnected app fields?

[Jane]

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]

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. 

[Bruce]

no issue Jane.

Cheers
Bruce

[Jane]

Thanks, guys!

[Jane]

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]

>> 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]

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]

>> 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