Why is Table 6508 [Val. Entry Relation] so strange

I am just looking at the data that is in the Value Entry Relation (Table 6508) of Navision Attain 3.60. There is a field, ‘Source RowId’, that looks a lot like it should be multiple fields. For example, a record of this table could look like this: 1158 “113”;“0”;“SI-10001”;"";“0”;“10000” I have determined what each of the values is, my question: Was I gone the day that Navision decided to abandon the relational database and go back to flat files? I would think that fields named “Source Table No.”,“Source Document No.”, etc. would be a lot better. Can anyone answer why Navision would have done this? - Dave Hutchinson

quote:


Originally posted by dhutch
I am just looking at the data that is in the Value Entry Relation (Table 6508) of Navision Attain 3.60. There is a field, ‘Source RowId’, that looks a lot like it should be multiple fields. For example, a record of this table could look like this: 1158 “113”;“0”;“SI-10001”;"";“0”;“10000” I have determined what each of the values is, my question: Was I gone the day that Navision decided to abandon the relational database and go back to flat files? I would think that fields named “Source Table No.”,“Source Document No.”, etc. would be a lot better. Can anyone answer why Navision would have done this? - Dave Hutchinson


A junior programmer with badly laid down programming specifics? [}:)] Anna

This is not a question of beeing relational or not. It’s simply a choice between identifying with on unique value in one field or a combination of fields. Sometimes it can be more efficient to identify with one value in one field (shorter keyes). RowID used to identify a sales invoice line or a sales credit line and is used in Item Trackning Management. In You example below the RowID identifies the sales invoice SI-10001 and line 10000. You can look in cu65000 “Item Tracking Management”. there’s some code that’s called from table 113 and 115 when the user want’s to se the associated item tracking entries. The code is as below: ****** Begin Code CallPostedItemTrackingForm3(InvoiceRowID : Text[100]) : OK : Boolean Procedure 12 // Used when calling Item Tracking from invoiced documents: ValueEntryRelation.SETCURRENTKEY(“Source RowId”); ValueEntryRelation.SETRANGE(“Source RowId”,InvoiceRowID); IF ValueEntryRelation.FIND(’-’) THEN BEGIN --SignFactor := TableSignFactor2(InvoiceRowID); --REPEAT ----ValueEntry.GET(ValueEntryRelation.“Value Entry No.”); ----ItemLedgEntry.GET(ValueEntry.“Item Ledger Entry No.”); ----TempItemLedgEntry := ItemLedgEntry; ----TempItemLedgEntry.Quantity := ValueEntry.“Invoiced Quantity”; ----AddTempRecordToSet(TempItemLedgEntry,SignFactor); --UNTIL ValueEntryRelation.NEXT = 0; --FORM.RUNMODAL(FORM::“Posted Item Tracking Lines”,TempItemLedgEntry); --EXIT(TRUE); END ELSE ********* End Code As You can see it uses the row id to find the value entry and the ledger entry and finally the tracking entries. The row-id might look ugly, but it’s more efficient than having a long key with document no and so on. Hope that explains some

Lars - you are proberbly right! However it is NOT, and I repeat NOT the way one does development in a relational database. Also - take a look into the Item Entry Relation table - there they did it the “Navision Way”. just my 2 cents

OK. It’s not a relational design. That’s right. I think the reason must be to reduce size of the secondary key. If RowID was the primary key it shouldn’t be any problem to have it as a combined key, but now it’s a secondary key and it should save space and performance like this.