In the online course of Using prodatasets there is a part explained where you can set the NOT-ACTIVE attribute on a data-relation.
Example :
define dataset dsOrderOrderLineItem for ttOrder, ttOrderLine, ttItem
data-relation drOrderOrderLine for ttOrder, ttOrderLine
relation-fields (Ordernum, Ordernum)
data-relation drOrderLineItem for ttOrderLine, ttItem
relation-fields (Itemnum, Itemnum)
data-relation drItemOrderLine for ttItem, ttOrderline
relation-fields (Itemnum, Itemnum) NOT-ACTIVE.
In the joining text, there is following comment :
drOrderLineItem is used for FILL operation (OK, I get that)
drItemOrderLine could be used for navigating the prodatasets.
What is meant with the latter ?
How this is used in an example ?
Kind regards
Gerd
The default version of that dataset allows you to add three browsers, one on each table. As the user scroll the primary browser (the one on ttOrder) the others will sync to it. As the user scroll the secondary (order line) browser, the tertiary (item) browser will sync to the order line selected. Of course, you will always see only one item, as an order line can have only one item.
But by switching the relations, you can turn this around.
You can only have one relation active at a time, so you need to disable the one before you can enable the other.
DATASET dsOderOrderLineItem:GET-RELATION("drOrderLineItem"):ACTIVE = FALSE.
DATASET dsOderOrderLineItem:GET-RELATION("drItemOrderLine"):ACTIVE = TRUE.
Now you can browse all the items in a primary browser and have a secondary browser with order lines displaying all order lines for the order.
The example is however not a a good one in my opinion. If you fill the browser and multiple order lines referencing the same item is encountered, the item will be copied to ttItem each time. Given that ttItem most likely will mirror the db table and have a unique index on itemNum, attempting to copy duplicates into the temp-table will cause runtime errors.
The solution would be to make the relation drOrderItem a scrolling relation. This will cause ttItem to be filled with all items, which could be a problem of its own if you have a large item master, but works well in Sports2000. Essentially ttItem will be regarded as a top level table with no filter and no relations during the FILL opretation, but when navigating the default setup, ttItem will always reposition to be in sync with ttOrderLine. The upside comes when you flip it around and look at the items to see their order lines (i.e. get the sales history of the item). You will have all items only once, regardless of the number of order lines there are for the item and as you scroll through the items, the seconday browser will show the order lines that are present for the order.
The default version of that dataset allows you to add three browsers, one on each table. As the user scroll the primary browser (the one on ttOrder) the others will sync to it. As the user scroll the secondary (order line) browser, the tertiary (item) browser will sync to the order line selected. Of course, you will always see only one item, as an order line can have only one item.
But by switching the relations, you can turn this around.
You can only have one relation active at a time, so you need to disable the one before you can enable the other.
DATASET dsOderOrderLineItem:GET-RELATION("drOrderLineItem"):ACTIVE = FALSE.
DATASET dsOderOrderLineItem:GET-RELATION("drItemOrderLine"):ACTIVE = TRUE.
Now you can browse all the items in a primary browser and have a secondary browser with order lines displaying all order lines for the order.
The example is however not a a good one in my opinion. If you fill the browser and multiple order lines referencing the same item is encountered, the item will be copied to ttItem each time. Given that ttItem most likely will mirror the db table and have a unique index on itemNum, attempting to copy duplicates into the temp-table will cause runtime errors.
The solution would be to make the relation drOrderItem a scrolling relation. This will cause ttItem to be filled with all items, which could be a problem of its own if you have a large item master, but works well in Sports2000. Essentially ttItem will be regarded as a top level table with no filter and no relations during the FILL opretation, but when navigating the default setup, ttItem will always reposition to be in sync with ttOrderLine. The upside comes when you flip it around and look at the items to see their order lines (i.e. get the sales history of the item). You will have all items only once, regardless of the number of order lines there are for the item and as you scroll through the items, the seconday browser will show the order lines that are present for the order.
Thanks Simon !