Inconsistency in how records of type Field work

Business Central/NAV Developers Forum
1

Hi,

I noticed that the property RelationTableNo in the record of type field behaves in an inconsistent way (supposedly)

The JobTask.JobNo field has a RelationTableNo of 167 which is the Job table as expected

The SalesLine.DocumentNo field has a RelationTableNo of 0 but I expected a 36 since the field has a relation with table sales header

My question is: can anyone explain to me why? What am I missing here?

Thank you in advance

2

You never enter a sales line independently, so there is no need to define the tablerelationship. Lines are always entered from the subpage in the document page, and the document type and document number is populated because of the pagelink between the header part of the document page, and the subform control that holds the lines.

3

Hi Daniel,

Thanks for your answer

You don’t enter a job task independently either (as far as i know) and JobTask.“JobNo.” field is populated by the subpagelink in its page part as well, no differences so far

The only difference i noticed between the two couples of tables is that in the Sales Line table the related field is explicitly declared, in the Job Task its not:

Sales line:

pastedimage1616753314689v3.png
pastedimage1616753314689v3.png696×99 3.82 KB

Job Task:

pastedimage1616753294667v2.png

Also:

Could you clarify what do you mean by “there is no need to define the tablerelationship”?

As you can see in the pics above the tablerelationship is defined

Thank you once again

4

I guess you refer to table virtual 2000000041:Field.

When there is a “conditional relation”, the relation is not shown in table Field. I don’t know why, it has allways been like that.
The relation on that particular field (table 36, field 6) is defined as: »"Sales Header".No. WHERE (Document Type=FIELD(Document Type))«

Only direct relations are shown in table Field.

5

I see,

So the where clause is preventing the field from setting RelationTableNo not the explicit field relationship like shown in my reply to Daniel

Thank you very much

6

If the table that you are linking to has a single field as the PK, you can leave the field out and BC will automatically use the PK field for the relationship. For instance, you can have a tablerelationship to the Customer table without specifying the No field, and BC will use the PK field to validate field values. If you have a compound PK, you need to specify which one you’re linking to, and how the other PK fields relate to your table. In the case of the Sales Line, the Document Type has to be the same, and the Document No field links to the No field in the Sales Header table.

The field table is a virtual table. It shows the properties as they are specified at the table level. If it doesn’t show the field, then that is because it has not been specified at the table level. in the Tablerelationship property.

I’ve made it a habit to ALWAYS specify the field, that way there is never any doubt.

By the way, the table relationship is not necessary in the Sales Line because those fields are always set by the page link, and the Line No is set by AutoSplitKey. You could say that the table relationship helps keep the data honest, but in this case it’s not really necessary because there is no way to manually set those fields anywhere. If you do provide the field in a page, then obviously you want to have the tablerelationship so the user is not allowed to enter a value that does not exist in the other table.