Display only last in portal

Fenton · March 17, 2005

Well, it does NOT use the relationships to pass the CustomerID; it still uses has to set the CustomerID global in Products, as Comment set up. The Line Items 2 TO I slipped in could not be used to filter by Customer "through" the Products; because there is no customer in Products. It's purpose was only to "filter" the products to only those for the customer.

Otherwise you lose the customer looking further, into the last Line Items table; because there is no customer field in Products.

The portal is in the Customer file, but you still have to set the customer ID into that related global. The global is then used to look further, into the Line Items 3 TO, to get the "last date" for that product & global customer.

It is the "last" date because that relationship (not the portal's, just the date's) is sorted descending by date. So, the date is not of the same relationship as the portal, but is looking one further down the line; much like putting a related field on a layout.

Because the relationship for that field is logically valid, the date makes sense. The portal is looking at each product belonging to a Customer (because its target is the Products table, filtered through the Line Items 2 TO by CustomerID).

The global relationship for the date is looking on to the Line Items 3 TO, based on that customer's ID (set into a global field) AND the product ID. So it's continuing the same logical connection.

Fenton · March 17, 2005

I didn't know how to do it at first, I wasn't thinking in 7 terms. Your setting the CustomerID global in Products solved much of the problem. But I thought "why not use the Line Items to filter the products to only the customer line items?" This is similar logically to using ValueListItems of a filtered relationship. So we solved it step by step, which I'm pretty good at. I wouldn't have come up with the whole thing on my own, as I would have been stuck on not being able to get the customer to go clear through.

Yes, it could be combined into one line relational line. No real reason not to.

Fenton · March 17, 2005

I didn't know how to do it at first, I wasn't thinking in 7 terms. Your setting the CustomerID global in Products solved much of the problem. But I thought "why not use the Line Items to filter the products to only the customer line items?" This is similar logically to using ValueListItems of a filtered relationship. So we solved it step by step, which I'm pretty good at. I wouldn't have come up with the whole thing on my own, as I would have been stuck on not being able to get the customer to go clear through.

Yes, it could be combined into one line relational line. No real reason not to.

Fenton · March 17, 2005

I didn't know how to do it at first, I wasn't thinking in 7 terms. Your setting the CustomerID global in Products solved much of the problem. But I thought "why not use the Line Items to filter the products to only the customer line items?" This is similar logically to using ValueListItems of a filtered relationship. So we solved it step by step, which I'm pretty good at. I wouldn't have come up with the whole thing on my own, as I would have been stuck on not being able to get the customer to go clear through.

Yes, it could be combined into one line relational line. No real reason not to.

LastPurchases2.zip

comment · March 17, 2005

Thanks.

The funny thing about your remark "wasn't thinking in 7 terms"? If you concatenate CustomerID & Product ID in LineItems, and gCustomerID & Product ID in Products, my idea will work in any version from 3 up. So it's debatable who was thinking in what terms...

comment · March 17, 2005

Thanks.

The funny thing about your remark "wasn't thinking in 7 terms"? If you concatenate CustomerID & Product ID in LineItems, and gCustomerID & Product ID in Products, my idea will work in any version from 3 up. So it's debatable who was thinking in what terms...

comment · March 17, 2005

Thanks.

The funny thing about your remark "wasn't thinking in 7 terms"? If you concatenate CustomerID & Product ID in LineItems, and gCustomerID & Product ID in Products, my idea will work in any version from 3 up. So it's debatable who was thinking in what terms...

Ugo DI LUCA · March 17, 2005

Hi,

Yes 7 solved this old problem of displaying only one line of the same. The only problem then is having any count running on the item "group" displayed in the Product Portal...

I personnally use an unstored calculation in the LineItems and both displays would happen in the LineItems itself.

Attached an example.

Ugo DI LUCA · March 17, 2005

Hi,

Yes 7 solved this old problem of displaying only one line of the same. The only problem then is having any count running on the item "group" displayed in the Product Portal...

I personnally use an unstored calculation in the LineItems and both displays would happen in the LineItems itself.

Attached an example.

Ugo DI LUCA · March 17, 2005

Hi,

Yes 7 solved this old problem of displaying only one line of the same. The only problem then is having any count running on the item "group" displayed in the Product Portal...

I personnally use an unstored calculation in the LineItems and both displays would happen in the LineItems itself.

Attached an example.

LastPurchases_altern.fp7.zip

PiedPiper · March 17, 2005

Fenton thank you, your explanation makes sense but the concept is elusive to me (but it'll sink in if I stick with it and I will). Comment, you say this can be done in prior version using concentrated keys? I read (I swear) 200 posts here they all said it couldn't (prior versions) without writing lines with script or export! I swear it!! Ugo, you now say, "With 7, it's possible now."

Thank you all for demos. I will keep this thread and each demo as a demonstration of the progression of thinking. Quite valuable to me - more than you'll know. For prior versions, is this like noone believing the 3-minute mile was physically possible until someone did it? Then within one year (after it had been proved possible), several people did it? It had to be proven first?

I can't even go to sleep on this one and I keep trying things. It should then be possible to adjust it so that all products show, so the 'holes' (unpurchased puroducts) also show but I guess I haven't grasped it enough to adjust it because I can't make it do it. Products must slide before LineItems, right? Wow, to have both methods at my control ... and I assume additional filters can be added easily also by passing additional globals? I know our guys ... they'll want to filter by other things like Customer Type or Territory. Either of these two ideas possible in this situation (all products showing holes and/or filtering further)?

Hey! isn't this an example of why/when globals are wonderful? That thread about 'why I use globals?'

Ugo, I thought unstored was bad and yours uses two unstored and theyll be in a big file. Can you explain which would be best then yours or Fenton's (since both give me Unique listing)? Not sure which to use. Fenton's looks clearer but I don't understand either enough yet.

Forums is best thing existing for help ever. Can't tell you how much I appreciate you all.

PiedPiper · March 17, 2005

Fenton thank you, your explanation makes sense but the concept is elusive to me (but it'll sink in if I stick with it and I will). Comment, you say this can be done in prior version using concentrated keys? I read (I swear) 200 posts here they all said it couldn't (prior versions) without writing lines with script or export! I swear it!! Ugo, you now say, "With 7, it's possible now."

Thank you all for demos. I will keep this thread and each demo as a demonstration of the progression of thinking. Quite valuable to me - more than you'll know. For prior versions, is this like noone believing the 3-minute mile was physically possible until someone did it? Then within one year (after it had been proved possible), several people did it? It had to be proven first?

I can't even go to sleep on this one and I keep trying things. It should then be possible to adjust it so that all products show, so the 'holes' (unpurchased puroducts) also show but I guess I haven't grasped it enough to adjust it because I can't make it do it. Products must slide before LineItems, right? Wow, to have both methods at my control ... and I assume additional filters can be added easily also by passing additional globals? I know our guys ... they'll want to filter by other things like Customer Type or Territory. Either of these two ideas possible in this situation (all products showing holes and/or filtering further)?

Hey! isn't this an example of why/when globals are wonderful? That thread about 'why I use globals?'

Ugo, I thought unstored was bad and yours uses two unstored and theyll be in a big file. Can you explain which would be best then yours or Fenton's (since both give me Unique listing)? Not sure which to use. Fenton's looks clearer but I don't understand either enough yet.

Forums is best thing existing for help ever. Can't tell you how much I appreciate you all.

PiedPiper · March 17, 2005

Fenton thank you, your explanation makes sense but the concept is elusive to me (but it'll sink in if I stick with it and I will). Comment, you say this can be done in prior version using concentrated keys? I read (I swear) 200 posts here they all said it couldn't (prior versions) without writing lines with script or export! I swear it!! Ugo, you now say, "With 7, it's possible now."

Thank you all for demos. I will keep this thread and each demo as a demonstration of the progression of thinking. Quite valuable to me - more than you'll know. For prior versions, is this like noone believing the 3-minute mile was physically possible until someone did it? Then within one year (after it had been proved possible), several people did it? It had to be proven first?

I can't even go to sleep on this one and I keep trying things. It should then be possible to adjust it so that all products show, so the 'holes' (unpurchased puroducts) also show but I guess I haven't grasped it enough to adjust it because I can't make it do it. Products must slide before LineItems, right? Wow, to have both methods at my control ... and I assume additional filters can be added easily also by passing additional globals? I know our guys ... they'll want to filter by other things like Customer Type or Territory. Either of these two ideas possible in this situation (all products showing holes and/or filtering further)?

Hey! isn't this an example of why/when globals are wonderful? That thread about 'why I use globals?'

Ugo, I thought unstored was bad and yours uses two unstored and theyll be in a big file. Can you explain which would be best then yours or Fenton's (since both give me Unique listing)? Not sure which to use. Fenton's looks clearer but I don't understand either enough yet.

Forums is best thing existing for help ever. Can't tell you how much I appreciate you all.

Fenton · March 17, 2005

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.

Fenton · March 17, 2005

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.

Fenton · March 17, 2005

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.

Ugo DI LUCA · March 17, 2005

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...

Ugo DI LUCA · March 17, 2005