NetTalk Central

Author Topic: Must be in table validation and NetWebForm  (Read 2344 times)

Ubaidullah

  • Full Member
  • ***
  • Posts: 125
    • View Profile
Must be in table validation and NetWebForm
« on: November 14, 2023, 03:43:06 PM »
Hi,

When a field has validation set in the dictionary to "Must be in Table", the NetWebForm will display a message with the table name.

Is there a way to display the table description instead of the name?

So, instead of the user seeing this message:

Department: Must be in table DPT001

the message shows up like this:

Department: Must be in table Departments

where Departments is the description of the table DPT001.

This is an external system so I don't have control of the tables names.

One option I am thinking is to change the table label to a descriptive one and use the path name for the actual table name.

Regards,
Ubaidullah Nubar.


Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Must be in table validation and NetWebForm
« Reply #1 on: November 15, 2023, 12:00:17 AM »
>> When a field has validation set in the dictionary to "Must be in Table", the NetWebForm will display a message with the table name.

It's worth pointing out that "must be in table" validation is _strongly_ discouraged. It will slow down your writes (Inserts, updates, imports and so on) by a LOT. like 10x slower. Before you use this validation you want to be _very_ sure you need it. And setting it in the dictionary makes it "global" which means it's slow everywhere.

It also causes complications when you are batch adding records, and adding the children before the parent. This has impacts on invoice/lineitem patterns on forms, as well as API calls and Api Sync's.

So, in short, if you are using this validation _expect_ things to break...
That said;

>> Department: Must be in table Departments

The message might be friendlier, but honestly the solution is the same - click the lookup button and select a record. For a user the message may just as well return "invalid value".
To a developer the table label is likely more useful as it will avoid mistakes when checking the backend (when you think a value _does_ exist).

Equally, using a description is not universally useful because the description field is used in lots of ways.

Cheers
Bruce