ExplodedKeys for filtering

[LaRetta]

Hi everyone,

I'm trying to provide a match filtered on Product Description. I've implemented Mike Hackett's (Ender) ExplodedPermutations and the other Custom Functions from Attachment here posted 2/26/2005. It's the second attachment (with ExplodedPermutations).

But I placed it in my LineItems and it's STILL updating after an hour and only a quarter updated!! Yikes!! If it takes this long to update does that mean it'll slow my solution down (or bloat the size)? I think there may be an easier way to get what I want (in this instance).

Structure and pertinent fields:

Pickup table: PickupID, ContactID, gProductName

LineItems table: ContactID, ProductID, ProductName

The reason I insert ProductName as static data in LineItems is that the wording of our products can change over time.

I want a filtered portal in Pickup which shows matching Contact LineItems so that when User types 'gink' in the global gProductName, it fills the portal with the results for this Contact (which could be ElethGinkgo or BilobaGinkgo, etc. I joined Pickup::ContactID to LineItems::ContactID on = and then (would have) joined gProductName to cExplodedProductName (if it ever finishes).

But I have a Product table! It contains the ProductID and ProductName! It seems I should be able to slide that puppy in here somehow so the Exploded CFs apply in the Products table

[LaRetta]

Hi everyone,

I'm trying to provide a match filtered on Product Description. I've implemented Mike Hackett's (Ender) ExplodedPermutations and the other Custom Functions from Attachment here posted 2/26/2005. It's the second attachment (with ExplodedPermutations).

But I placed it in my LineItems and it's STILL updating after an hour and only a quarter updated!! Yikes!! If it takes this long to update does that mean it'll slow my solution down (or bloat the size)? I think there may be an easier way to get what I want (in this instance).

Structure and pertinent fields:

Pickup table: PickupID, ContactID, gProductName

LineItems table: ContactID, ProductID, ProductName

The reason I insert ProductName as static data in LineItems is that the wording of our products can change over time.

I want a filtered portal in Pickup which shows matching Contact LineItems so that when User types 'gink' in the global gProductName, it fills the portal with the results for this Contact (which could be ElethGinkgo or BilobaGinkgo, etc. I joined Pickup::ContactID to LineItems::ContactID on = and then (would have) joined gProductName to cExplodedProductName (if it ever finishes).

But I have a Product table! It contains the ProductID and ProductName! It seems I should be able to slide that puppy in here somehow so the Exploded CFs apply in the Products table

[LaRetta]

Hi everyone,

I'm trying to provide a match filtered on Product Description. I've implemented Mike Hackett's (Ender) ExplodedPermutations and the other Custom Functions from Attachment here posted 2/26/2005. It's the second attachment (with ExplodedPermutations).

But I placed it in my LineItems and it's STILL updating after an hour and only a quarter updated!! Yikes!! If it takes this long to update does that mean it'll slow my solution down (or bloat the size)? I think there may be an easier way to get what I want (in this instance).

Structure and pertinent fields:

Pickup table: PickupID, ContactID, gProductName

LineItems table: ContactID, ProductID, ProductName

The reason I insert ProductName as static data in LineItems is that the wording of our products can change over time.

I want a filtered portal in Pickup which shows matching Contact LineItems so that when User types 'gink' in the global gProductName, it fills the portal with the results for this Contact (which could be ElethGinkgo or BilobaGinkgo, etc. I joined Pickup::ContactID to LineItems::ContactID on = and then (would have) joined gProductName to cExplodedProductName (if it ever finishes).

But I have a Product table! It contains the ProductID and ProductName! It seems I should be able to slide that puppy in here somehow so the Exploded CFs apply in the Products table

[LaRetta]

It finally finished updating. When I then attached the relationship (while viewing the Pickup form with the portal, it then took 15 minutes to display the portal. But I hadn't put anything in the global yet. It said it needed to index cExplodedProductName.

It also zoomed my file size from 400MB to 852MB!!

Okay, I won't use this type of Exploded Key on huge files.

I will have to figure something else out. I considered placing a portal or popup of products (based upon the Product table) but I didn't want Users to have to do additional work.

Their purpose in viewing the portal is to simply click a LineItem Product which will grab the ProductID, Quantity, LineItemID and Price paid for creating a new record in their Returns table (also a portal). The point-and-click (on LineItem) theory seemed to work easiest for them while allowing me to tag the LineItem as partially/totally returned.

Script would have inserted in the LineItem Product line ("3 returned PickupID ___). Well ... I will certainly need to figure something else out. And I'm glad this has happened; I now see some drawbacks to Exploded Keys with HUGE tables.

LaRetta

[LaRetta]

It finally finished updating. When I then attached the relationship (while viewing the Pickup form with the portal, it then took 15 minutes to display the portal. But I hadn't put anything in the global yet. It said it needed to index cExplodedProductName.

It also zoomed my file size from 400MB to 852MB!!

Okay, I won't use this type of Exploded Key on huge files.

I will have to figure something else out. I considered placing a portal or popup of products (based upon the Product table) but I didn't want Users to have to do additional work.

Their purpose in viewing the portal is to simply click a LineItem Product which will grab the ProductID, Quantity, LineItemID and Price paid for creating a new record in their Returns table (also a portal). The point-and-click (on LineItem) theory seemed to work easiest for them while allowing me to tag the LineItem as partially/totally returned.

Script would have inserted in the LineItem Product line ("3 returned PickupID ___). Well ... I will certainly need to figure something else out. And I'm glad this has happened; I now see some drawbacks to Exploded Keys with HUGE tables.

LaRetta

[LaRetta]

It finally finished updating. When I then attached the relationship (while viewing the Pickup form with the portal, it then took 15 minutes to display the portal. But I hadn't put anything in the global yet. It said it needed to index cExplodedProductName.

It also zoomed my file size from 400MB to 852MB!!

Okay, I won't use this type of Exploded Key on huge files.

I will have to figure something else out. I considered placing a portal or popup of products (based upon the Product table) but I didn't want Users to have to do additional work.

Their purpose in viewing the portal is to simply click a LineItem Product which will grab the ProductID, Quantity, LineItemID and Price paid for creating a new record in their Returns table (also a portal). The point-and-click (on LineItem) theory seemed to work easiest for them while allowing me to tag the LineItem as partially/totally returned.

Script would have inserted in the LineItem Product line ("3 returned PickupID ___). Well ... I will certainly need to figure something else out. And I'm glad this has happened; I now see some drawbacks to Exploded Keys with HUGE tables.

LaRetta

[Ugo DI LUCA]

Hi LaRetta,

It seems that your trying to find out if a product has been picked by a filtered set of your Contact Table.

Although I'm not clear why you'd want to do the search on the occurrence of the gProductName in any lines related to that Contact in your Line Items, the result should be quicker if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Therefore, from Contacts, you'd use a first relation to LineItems by ContactID.

Then a relation from LineItems to LineItems_Filtered by c_NewKey = LineItemID lead you to the subset of records matching your ContactID and your ProductName key.

All you need is a refresh window step to get the global into the Line Items...

[Ugo DI LUCA]

Hi LaRetta,

It seems that your trying to find out if a product has been picked by a filtered set of your Contact Table.

Although I'm not clear why you'd want to do the search on the occurrence of the gProductName in any lines related to that Contact in your Line Items, the result should be quicker if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Therefore, from Contacts, you'd use a first relation to LineItems by ContactID.

Then a relation from LineItems to LineItems_Filtered by c_NewKey = LineItemID lead you to the subset of records matching your ContactID and your ProductName key.

All you need is a refresh window step to get the global into the Line Items...

[Ugo DI LUCA]

Hi LaRetta,

It seems that your trying to find out if a product has been picked by a filtered set of your Contact Table.

Although I'm not clear why you'd want to do the search on the occurrence of the gProductName in any lines related to that Contact in your Line Items, the result should be quicker if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Therefore, from Contacts, you'd use a first relation to LineItems by ContactID.

Then a relation from LineItems to LineItems_Filtered by c_NewKey = LineItemID lead you to the subset of records matching your ContactID and your ProductName key.

All you need is a refresh window step to get the global into the Line Items...

[Ender]

Hi LaRetta,

Yes, that ExplodedPermutations() function creates some overhead. If you just use this function for your match field with n letters, you'll end up with some (n^2)/2 lines for the record. This is why I used the ExplodedString() function too. This breaks up multi-word strings, and builds the exploded permutations for each word separately. By doing this, strings with m words will result in something on the order of (n^2)/(1+m) lines.

You might also adjust that exploding permutation function so one, two, and three letter lines are not generated in the multi-key, since these probably won't be very useful with a large set of records.

[Ender]

Hi LaRetta,

Yes, that ExplodedPermutations() function creates some overhead. If you just use this function for your match field with n letters, you'll end up with some (n^2)/2 lines for the record. This is why I used the ExplodedString() function too. This breaks up multi-word strings, and builds the exploded permutations for each word separately. By doing this, strings with m words will result in something on the order of (n^2)/(1+m) lines.

You might also adjust that exploding permutation function so one, two, and three letter lines are not generated in the multi-key, since these probably won't be very useful with a large set of records.

[Ender]

Hi LaRetta,

Yes, that ExplodedPermutations() function creates some overhead. If you just use this function for your match field with n letters, you'll end up with some (n^2)/2 lines for the record. This is why I used the ExplodedString() function too. This breaks up multi-word strings, and builds the exploded permutations for each word separately. By doing this, strings with m words will result in something on the order of (n^2)/(1+m) lines.

You might also adjust that exploding permutation function so one, two, and three letter lines are not generated in the multi-key, since these probably won't be very useful with a large set of records.

[LaRetta]

Hi Ugo

Well, per usual, your advice leaves me feeling a bit befuddled but I'm sure that's just me.

It seems that your trying to find out if a product has been picked by a filtered set of your Contact Table.

My Contact table? Yes, there is a Contact TO attached to my Pickup table but this will be in my Pickup table. Am I missing something here?

... why you'd want to do the search on the occurrence of the gProductName in any lines related to that Contact in your Line Items

Because we need to display every time that Contact ordered that product so they can pick the one the Contact wants to return. They can ONLY return Products they have previously purchased and the Lot# and Exp Dates of the products we receive back must match perfectly (it's stored within the LineItem file).

... if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Okay, I'll try that. But that puts a global in the middle of a key?: Is that possible now in 7?

Well, if nothing else, I may insist Users select a product from a filtered popup or portal. But they have asked for the ability to type just part of the name and I always hate to disappoint. I may have to say NO for once. I will keep playing with it and see what I can come up with. Thank you!!!

LaRetta

[LaRetta]

Hi Ugo

Well, per usual, your advice leaves me feeling a bit befuddled but I'm sure that's just me.

It seems that your trying to find out if a product has been picked by a filtered set of your Contact Table.

My Contact table? Yes, there is a Contact TO attached to my Pickup table but this will be in my Pickup table. Am I missing something here?

... why you'd want to do the search on the occurrence of the gProductName in any lines related to that Contact in your Line Items

Because we need to display every time that Contact ordered that product so they can pick the one the Contact wants to return. They can ONLY return Products they have previously purchased and the Lot# and Exp Dates of the products we receive back must match perfectly (it's stored within the LineItem file).

... if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Okay, I'll try that. But that puts a global in the middle of a key?: Is that possible now in 7?

Well, if nothing else, I may insist Users select a product from a filtered popup or portal. But they have asked for the ability to type just part of the name and I always hate to disappoint. I may have to say NO for once. I will keep playing with it and see what I can come up with. Thank you!!!

LaRetta

[LaRetta]

Hi Ugo

Well, per usual, your advice leaves me feeling a bit befuddled but I'm sure that's just me.

It seems that your trying to find out if a product has been picked by a filtered set of your Contact Table.

My Contact table? Yes, there is a Contact TO attached to my Pickup table but this will be in my Pickup table. Am I missing something here?

... why you'd want to do the search on the occurrence of the gProductName in any lines related to that Contact in your Line Items

Because we need to display every time that Contact ordered that product so they can pick the one the Contact wants to return. They can ONLY return Products they have previously purchased and the Lot# and Exp Dates of the products we receive back must match perfectly (it's stored within the LineItem file).

... if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Okay, I'll try that. But that puts a global in the middle of a key?: Is that possible now in 7?

Well, if nothing else, I may insist Users select a product from a filtered popup or portal. But they have asked for the ability to type just part of the name and I always hate to disappoint. I may have to say NO for once. I will keep playing with it and see what I can come up with. Thank you!!!

LaRetta

[LaRetta]

Hi Mike!!!

...adjust that exploding permutation function so one, two, and three letter lines are not generated in the multi-key,

I copied all three functions and use them together just as your demo had them. So I should be wrapping my ProductDescription field with ExplodedStrings instead of ExplodedPermutations??

Ummm, I will try adjusting your Custom Function to ignore gProductName if less than 4 (it will be a good text-function learning exercise for me) but I wonder if I misinterpreted using your demo.

In truth ... Users search for products continually all through my solution. They constantly ask for entering part-text only. It's too bad I can't explode the Products table ProductDescription only and then use those Product IDs as a go-between table.

My Products table is exactly how I originally forsaw using your demo file because the Products db is fairly small (150 records). If I could find a way of incorporating this, I'd be one happy camper (because they'd love me even more than they do now)!!

LaRetta

[LaRetta]

Hi Mike!!!

...adjust that exploding permutation function so one, two, and three letter lines are not generated in the multi-key,

I copied all three functions and use them together just as your demo had them. So I should be wrapping my ProductDescription field with ExplodedStrings instead of ExplodedPermutations??

Ummm, I will try adjusting your Custom Function to ignore gProductName if less than 4 (it will be a good text-function learning exercise for me) but I wonder if I misinterpreted using your demo.

In truth ... Users search for products continually all through my solution. They constantly ask for entering part-text only. It's too bad I can't explode the Products table ProductDescription only and then use those Product IDs as a go-between table.

My Products table is exactly how I originally forsaw using your demo file because the Products db is fairly small (150 records). If I could find a way of incorporating this, I'd be one happy camper (because they'd love me even more than they do now)!!

LaRetta

[LaRetta]

Hi Mike!!!

...adjust that exploding permutation function so one, two, and three letter lines are not generated in the multi-key,

I copied all three functions and use them together just as your demo had them. So I should be wrapping my ProductDescription field with ExplodedStrings instead of ExplodedPermutations??

Ummm, I will try adjusting your Custom Function to ignore gProductName if less than 4 (it will be a good text-function learning exercise for me) but I wonder if I misinterpreted using your demo.

In truth ... Users search for products continually all through my solution. They constantly ask for entering part-text only. It's too bad I can't explode the Products table ProductDescription only and then use those Product IDs as a go-between table.

My Products table is exactly how I originally forsaw using your demo file because the Products db is fairly small (150 records). If I could find a way of incorporating this, I'd be one happy camper (because they'd love me even more than they do now)!!

LaRetta

[Ugo DI LUCA]

... if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Okay, I'll try that. But that puts a global in the middle of a key?: Is that possible now in 7?

[Ugo DI LUCA]

... if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Okay, I'll try that. But that puts a global in the middle of a key?: Is that possible now in 7?

[Ugo DI LUCA]

... if you introduced the filter key into the line items and used this key as the new key to a new occurrence of your LineItems Table.

c_NewKey = Case(PatternCount(ProductName;ContactsTable::gProductName));LineItemID)

Okay, I'll try that. But that puts a global in the middle of a key?: Is that possible now in 7?

[Ugo DI LUCA]

Hi again,

I've been testing this scenario with a 50,000 prroduct file of mine, and it even defeats the Copy All Records idea I had implemented at first, grabbing all LineItems Ids returned by the calc, and using it for another relation.

Let me know if you have problems with it.

In my situation, the calc was slightly different as it should have returned the line itemID in case this line was the first where the Client had purchased this Product (using a SelfJoin and Case(serial=SelfJoin::serial) approach.

This gave me a list of all Products purchased by the Customer, together with a Count of these sales.

Attaching a new TO of the Product Table could have shown me one product per line for sure, but the Count calc would have always referenced the first item rather than all. Involving this filtered technique solved the case.

[Ugo DI LUCA]

Hi again,

I've been testing this scenario with a 50,000 prroduct file of mine, and it even defeats the Copy All Records idea I had implemented at first, grabbing all LineItems Ids returned by the calc, and using it for another relation.

Let me know if you have problems with it.

In my situation, the calc was slightly different as it should have returned the line itemID in case this line was the first where the Client had purchased this Product (using a SelfJoin and Case(serial=SelfJoin::serial) approach.

This gave me a list of all Products purchased by the Customer, together with a Count of these sales.

Attaching a new TO of the Product Table could have shown me one product per line for sure, but the Count calc would have always referenced the first item rather than all. Involving this filtered technique solved the case.

[Ugo DI LUCA]

Hi again,

I've been testing this scenario with a 50,000 prroduct file of mine, and it even defeats the Copy All Records idea I had implemented at first, grabbing all LineItems Ids returned by the calc, and using it for another relation.

Let me know if you have problems with it.

In my situation, the calc was slightly different as it should have returned the line itemID in case this line was the first where the Client had purchased this Product (using a SelfJoin and Case(serial=SelfJoin::serial) approach.

This gave me a list of all Products purchased by the Customer, together with a Count of these sales.

Attaching a new TO of the Product Table could have shown me one product per line for sure, but the Count calc would have always referenced the first item rather than all. Involving this filtered technique solved the case.

[LaRetta]

I will try this! I had originally considered Copy All Records (as in my SearchNGo demo) but LineItems is HUGE and I had always wanted to incorate clairvoyance in it! I decided I was going to figure a way to break this puppy (LineItems) down in size because I need its data constantly; always filtered by gProductName.

I recognize (after reviewing your graph, thank you very much for it) that cMatch (which contains the global) is on the 'old-thinking left' side so it can contain a global. Strange that the forks on that graph show data will flow through the original LineItems!? I thought the end should be | inidicating it stopped there. This all goes against my anal thinking and I'll have to just do it, I guess.

So, I'd put LineItems 2 portal on my Pickup form, right?

Hmmm, if LineItems can be an additional filter for LineItems, then why can't Products be an additional filter for LineItems. God, so much to play with!

Thank you!

LaRetta

[LaRetta]

I will try this! I had originally considered Copy All Records (as in my SearchNGo demo) but LineItems is HUGE and I had always wanted to incorate clairvoyance in it! I decided I was going to figure a way to break this puppy (LineItems) down in size because I need its data constantly; always filtered by gProductName.

I recognize (after reviewing your graph, thank you very much for it) that cMatch (which contains the global) is on the 'old-thinking left' side so it can contain a global. Strange that the forks on that graph show data will flow through the original LineItems!? I thought the end should be | inidicating it stopped there. This all goes against my anal thinking and I'll have to just do it, I guess.

So, I'd put LineItems 2 portal on my Pickup form, right?

Hmmm, if LineItems can be an additional filter for LineItems, then why can't Products be an additional filter for LineItems. God, so much to play with!

Thank you!

LaRetta

[LaRetta]

I will try this! I had originally considered Copy All Records (as in my SearchNGo demo) but LineItems is HUGE and I had always wanted to incorate clairvoyance in it! I decided I was going to figure a way to break this puppy (LineItems) down in size because I need its data constantly; always filtered by gProductName.

I recognize (after reviewing your graph, thank you very much for it) that cMatch (which contains the global) is on the 'old-thinking left' side so it can contain a global. Strange that the forks on that graph show data will flow through the original LineItems!? I thought the end should be | inidicating it stopped there. This all goes against my anal thinking and I'll have to just do it, I guess.

So, I'd put LineItems 2 portal on my Pickup form, right?

Hmmm, if LineItems can be an additional filter for LineItems, then why can't Products be an additional filter for LineItems. God, so much to play with!

Thank you!

LaRetta

[Ugo DI LUCA]

Hi,

The Graph itself only shows the flaws from one point to the end. I've done it with no calcs just for representating it so the c_Match was a text field.

And yes you'd use the LineItems2 as the Filtering Table to see the end results.

[Ugo DI LUCA]

Hi,

The Graph itself only shows the flaws from one point to the end. I've done it with no calcs just for representating it so the c_Match was a text field.

And yes you'd use the LineItems2 as the Filtering Table to see the end results.

[Ugo DI LUCA]

Hi,

The Graph itself only shows the flaws from one point to the end. I've done it with no calcs just for representating it so the c_Match was a text field.

And yes you'd use the LineItems2 as the Filtering Table to see the end results.

[Ugo DI LUCA]

Hmmm, if LineItems can be an additional filter for LineItems, then why can't Products be an additional filter for LineItems. God, so much to play with!

It can with a double key gProductName and ContactID matching ProductName and ContactID of course.

As your gProductKey only holds part of the ProductName, you need either :

- this exploding key in the LineItems and a relation to this LineItems

or

- a way to jump one relation away to the filtered list in LineItems2.

Relating upon an index isn't really necessary and is more involved than an unstored calculation. The only added part is the Refresh Window (cache) step.

Also, you could do it through the Product Table as well, by using Mike Exploding key there and by setting an unstored calculation there as your filter key. See attached both graphs...

Edited : There is a missing ending parens in the calc attached as the title of the graph on left...

[Ugo DI LUCA]

Hmmm, if LineItems can be an additional filter for LineItems, then why can't Products be an additional filter for LineItems. God, so much to play with!

It can with a double key gProductName and ContactID matching ProductName and ContactID of course.

As your gProductKey only holds part of the ProductName, you need either :

- this exploding key in the LineItems and a relation to this LineItems

or

- a way to jump one relation away to the filtered list in LineItems2.

Relating upon an index isn't really necessary and is more involved than an unstored calculation. The only added part is the Refresh Window (cache) step.

Also, you could do it through the Product Table as well, by using Mike Exploding key there and by setting an unstored calculation there as your filter key. See attached both graphs...

Edited : There is a missing ending parens in the calc attached as the title of the graph on left...

[Ugo DI LUCA]

Hmmm, if LineItems can be an additional filter for LineItems, then why can't Products be an additional filter for LineItems. God, so much to play with!

It can with a double key gProductName and ContactID matching ProductName and ContactID of course.

As your gProductKey only holds part of the ProductName, you need either :

- this exploding key in the LineItems and a relation to this LineItems

or

- a way to jump one relation away to the filtered list in LineItems2.

Relating upon an index isn't really necessary and is more involved than an unstored calculation. The only added part is the Refresh Window (cache) step.

Also, you could do it through the Product Table as well, by using Mike Exploding key there and by setting an unstored calculation there as your filter key. See attached both graphs...

Edited : There is a missing ending parens in the calc attached as the title of the graph on left...

[LaRetta]

Hi Ugo,

My mind is in a swirl. It works (LineItems to LineItems2) using a global in the middle!! Well there goes everything I THOUGHT I was learning about 7. My understanding was that if the line ended in | then data (thus the relationship) would not flow back that direction. Every line end - backwards towards Pickup on my graph - displays a | but yet the portal displays (sort of).

Thanks for teaching me this! It won't refresh properly (I'm using 7.02 still). Entering Preview or Find won't even fix it (and that usually fixes all my portal refresh issues). It's only when I change data in a record that it changes the portal display. Even changing to the next Pickup record (different Contact) won't change it - it stays on the original gProductName. A very stubborn relationship it is!

I also plan to take full advantage of Mike's Exploded Keys. After I added that CF calculation to LineItems, my file size jumped from 400 to 852 so I was concerned. However after it refreshed for display in the Pickup portal (indexed it?), it dropped to 638 (but still too much).

I had used: ExplodedKey(ProductDescription) &

[LaRetta]

Hi Ugo,

My mind is in a swirl. It works (LineItems to LineItems2) using a global in the middle!! Well there goes everything I THOUGHT I was learning about 7. My understanding was that if the line ended in | then data (thus the relationship) would not flow back that direction. Every line end - backwards towards Pickup on my graph - displays a | but yet the portal displays (sort of).

Thanks for teaching me this! It won't refresh properly (I'm using 7.02 still). Entering Preview or Find won't even fix it (and that usually fixes all my portal refresh issues). It's only when I change data in a record that it changes the portal display. Even changing to the next Pickup record (different Contact) won't change it - it stays on the original gProductName. A very stubborn relationship it is!

I also plan to take full advantage of Mike's Exploded Keys. After I added that CF calculation to LineItems, my file size jumped from 400 to 852 so I was concerned. However after it refreshed for display in the Pickup portal (indexed it?), it dropped to 638 (but still too much).

I had used: ExplodedKey(ProductDescription) &