Ugo's is better. Because he used a calculation in Line Items itself you don't have to set a global. A script is therefore no longer needed. You could put his portal directly on the main Customer layout and it would still work, even when flipping to the next record using the status area. This eliminates a navigation problem.

As far as the unstored calculation causing slowness, it might appear that my method was more direct. But there is another factor. I've read that because of the way Server 7 distributes the workload, using a global field in a calculation is going to be slower; something about having to pass the local global to Server for it to evaluate the calculation, whereas it doesn't have to do this for Ugo's calculation. Probably a small difference, but it tips the scale. I've thought of this also in regard to calendar and scheduling solutions, where a global is in many calculations and relationships, all on the same layout.

While I've used a self-relationship to mark either the first or the last record before pre-7, it was never like this; looking through it at another instance of the same table, to produce unique lines in a portal from Customers.

So, while going through an extra TO to filter records may have other uses, I was solving a problem that didn't need to exist (again).

BTW, you will want another plain Product TO off of plain Line Items, for adding products.

Good question,

First of all, there's one unstored calculation needed. The second was there for another purpose.

Setting a global on a served environment now may be slower with 7, and require to script a navigation process, while the solution involving a calculation would behave the same when looking to the next record.

Working with unstored data now isn't a very big problem with 7 compared to what it was with 6.

I'm not saying Fenton's approach isn't clever, which it is in fact. I won't be surprised to involved this new tunnelling approach in one of my files...

but then again, if you needed to display the count of items sold next to the product name, it won't work because the Product Table will still be displaying the last or first related record in LineItems and therefore mismatch the context of such a calc. That's my understanding, and he may prove me wrong.:

If it was possible to display the result in the Line Items, I'd think a Refresh Window would be necessary anyway.

For information, In mine, the Product Name if needed would come from the last Product Table joined in the graph.

There are many possible implementations of such a technique, even some involving a global actually. But then a refresh window step would be necessary, would it be a global or a fixed value stored in a Parameter/User Table.

See here another example..

As for what was possible with 6, I'd be curious to see Comment's approach to the case. IMO, the best would be a copy all records still based on the kind of unstored calculation I've been using here...

Good question,

First of all, there's one unstored calculation needed. The second was there for another purpose.

Setting a global on a served environment now may be slower with 7, and require to script a navigation process, while the solution involving a calculation would behave the same when looking to the next record.

Working with unstored data now isn't a very big problem with 7 compared to what it was with 6.

I'm not saying Fenton's approach isn't clever, which it is in fact. I won't be surprised to involved this new tunnelling approach in one of my files...

but then again, if you needed to display the count of items sold next to the product name, it won't work because the Product Table will still be displaying the last or first related record in LineItems and therefore mismatch the context of such a calc. That's my understanding, and he may prove me wrong.:

If it was possible to display the result in the Line Items, I'd think a Refresh Window would be necessary anyway.

For information, In mine, the Product Name if needed would come from the last Product Table joined in the graph.

There are many possible implementations of such a technique, even some involving a global actually. But then a refresh window step would be necessary, would it be a global or a fixed value stored in a Parameter/User Table.

See here another example..

As for what was possible with 6, I'd be curious to see Comment's approach to the case. IMO, the best would be a copy all records still based on the kind of unstored calculation I've been using here...

Good question,

First of all, there's one unstored calculation needed. The second was there for another purpose.

Setting a global on a served environment now may be slower with 7, and require to script a navigation process, while the solution involving a calculation would behave the same when looking to the next record.

Working with unstored data now isn't a very big problem with 7 compared to what it was with 6.

I'm not saying Fenton's approach isn't clever, which it is in fact. I won't be surprised to involved this new tunnelling approach in one of my files...

but then again, if you needed to display the count of items sold next to the product name, it won't work because the Product Table will still be displaying the last or first related record in LineItems and therefore mismatch the context of such a calc. That's my understanding, and he may prove me wrong.:

If it was possible to display the result in the Line Items, I'd think a Refresh Window would be necessary anyway.

For information, In mine, the Product Name if needed would come from the last Product Table joined in the graph.

There are many possible implementations of such a technique, even some involving a global actually. But then a refresh window step would be necessary, would it be a global or a fixed value stored in a Parameter/User Table.

See here another example..

As for what was possible with 6, I'd be curious to see Comment's approach to the case. IMO, the best would be a copy all records still based on the kind of unstored calculation I've been using here...

The only v.7 feature I used is a compound relationship, and that can easily be replaced by concatenated fields. Everything else should work just the same.

The only v.7 feature I used is a compound relationship, and that can easily be replaced by concatenated fields. Everything else should work just the same.

The only v.7 feature I used is a compound relationship, and that can easily be replaced by concatenated fields. Everything else should work just the same.