How to show all grandchild records linked to multiple child records related to parent

[SNusa]

Actually, once you know the programs limitations & pitfalls, you learn to "intuitively navigate around them." But even so: These "roadblocks" can be a "moving target." (which can change/vary from version to version......)

The biggest issue at present (IMHO) which debilitates a5 is the built in browse object and related scroll issues..... You cannot do some things you'd expect should/would be feasible here. Also, I find that the a5 set relationship structure makes it difficult to do one (related) thing in particular:

If you have a "Parent -> Child -> Grandchild" relationship, it can be very difficult to create a form that shows all the grandchildren in a browse at the same time. (with only the grandparent selected in the form's header) ~ Typically, you must also include the child browse on the form (and make a selection in the child browse) which results in displaying only a "subset" of the grandchildren (on the form) at any given time. ~ There are a few "tricks" getting around this limitation, but thus far I haven't found a "perfect solution." .....Without the use of extensive Xdialog, which 1.) I don't know, and 2.) have absolutely 0 interest in learning: I don't think there is a "perfect solution."

[CALocklin]

Re: If you have a "Parent -> Child -> Grandchild" relationship...

Just out of curiosity, why would you want to show only the Grandchild records without showing the Child record? I can't think of a situation that would call for this but obviously you've run into one.

[SNusa]

Re: If you have a "Parent -> Child -> Grandchild" relationship...

Just out of curiosity, why would you want to show only the Grandchild records without showing the Child record? I can't think of a situation that would call for this but obviously you've run into one.

Hi Cal;

It's a points/rewards system. (Customers have "key-fobs" which accumulate points from a POS barcode scanner.) Upon registering the fobs, multiple key-fobs can be tied into one master account. (Showing all the "grandchildren" together with the totals under the parent account is thus necessary here.) ~ I want/need to keep all the children fobs separate too for historical data.....

~The primary reason for this is the details are captured and then exported from a POS system. At the time the data is collected, the key-fobs are not tied into a parent account. Nor is there any any way to do so due to POS setup..... (All POS is capable of doing is capturing the bar code.) I wanted a way (using an interim table) to connect all this together without having to update the details/grand-child tables each time additional data is appended from POS.

~ I've found a solution/workaround. (But it would have been a heck of a lot easier had the scroll region worked properly when "parent records only" setting is unchecked)...... This is going to turn into a really neat finished product/tool!

[Ray in Capetown]

I wouldn't expect that to work in any way like that Robert. Not without designing a set for it.
How would it be predicatable what you intend by leaving off the linking table.

[SNusa]

I wouldn't expect that to work in any way like that Robert. Not without designing a set for it.
How would it be predicatable what you intend by leaving off the linking table.

That's the issue: including all 3 tables while both displaying & getting the grandchild totals regardless of which child (middle table) record is selected . I am using a 3-table set for the form. (Although you don't actually need one. I could have just used a form based on a single grandparent (top) table. (more "restricting" though) ~ Even so, in this instance, the linking table is there "in the middle." ~ it serves as "the link" between the parent and the grandchild..... And yes, it can be done. A little magic with calculated fields, reversing parent/child relationships ("one to first" via mapped tables)* etc...

*Note to self: Maybe I should try a set instead of mapped tables here..... I have to look into the ramifications here.....

~ I could have done more if I had the knowledge to display a mapped table using Xdialog, But I don't know Xdialog, so I resorted to using a "Record List List Box" instead for the grand-children.... (Tim Keibert "whipped up" an awesome Xdialog based solution ~ see link below.) However, being afraid to implement something I didn't inherently understand completely I am not using it (yet anyways.)

http://msgboard.alphasoftware.com/alphaforum/showthread.php?100411-Embedded-browse-problem&p=632932&viewfull=1#post632932

Also, a little magic with the generation/usage of indexes based on multiple fields (along with dbsum() allows me to generate additional subtotaling. (for instance, sub-totals by year)

This is the culmination of a lot of learning/legwork (and dealing with all the shortcomings/bugs in a5 which I've been "bitchin" about!) ~ And ALSO from a few "great tips" from others here on the forum (For which I am grateful!)

PS: Having the "ideal" data layout structure sure helps too!

[Al Buchholz]

This thread has gone into new territory that isn't related to backup...

Maybe the last few posts should go into their own thread.

Suggest a title and what posts should move and I'll move them.

[Ray in Capetown]

Al - I suggest "How to show all grandchild records attached to multiple child records related to parent"
Would that describe it Robert?
From post 44

[Al Buchholz]

Al - I suggest "How to show all grandchild records attached to multiple child records related to parent"
Would that describe it Robert?
From post 44

Ok with me... We'll see what Robert has to say......

[SNusa]

Ok with me... We'll see what Robert has to say......

Sounds good guys....
I'd really love to understand exactly how Tim's Xdialog example was accomplished/created!
http://msgboard.alphasoftware.com/alphaforum/showthread.php?100411-Embedded-browse-problem&p=632932&viewfull=1#post632932

[Al Buchholz]

Sounds good guys....
I'd really love to understand exactly how this Xdialog example was accomplished/created!
http://msgboard.alphasoftware.com/alphaforum/showthread.php?100411-Embedded-browse-problem&p=632932&viewfull=1#post632932

Robert

Start a new thread (then it's still your thread..) and I'll move the posts.

[SNusa]

When you have 3 tables linked together (parent -> child -> grandchild) it is difficult to display all grandchildren (along with the parent record) on the same form using a form based on a standard "one to many" set. ~ As I am finding out, there are ways to accomplish this.

Notes: These problems exist using conventional methods because of browse related scroll issues which inhibits the ability to view all the records when "parent record only" browse setting is deselected. ~ Also, the actual problem (when using the middle/hild table on a form is that in order to see the grandchildren records, you have to make a selection in the child. (Doing this returns only a subset of the grandchildren records associated with the parent.)

[SNusa]

Here's the link: http://msgboard.alphasoftware.com/al...063#post640063

Note: Additional relative information here: http://msgboard.alphasoftware.com/al...l=1#post632932

[Tom Cone Jr]

Robert,

Have you considered the use of an inverted set arrangement? That's what I'd do. The grandchild become parent. It's linked one to one to the child. The child is linked one to one to the original parent which is now in grandchild position. Piece of cake. Now you essentially have a large flat table. Put what fields you want in your browse or on your form. Query the form based on a single parent and see all the grandchildren.

[G Gabriel]

You lost me at "FOB"..but I think I get the gist of what you are trying to do in generic terms and the answer is so simple and you don't have to xdlg anything:
Link the parent to the child with a dummy expression which will evaluate to true at all times, which in turn will show all children and therefore all grandchildren..
This should answer your question but won't answer mine: something wrong with the grand design..the concept itself..
The logic still escapes me...but as I said.. you lost me at FOB and I just had a couple drinks and a dinner at the Royal Sonista. a la French Quarter...so I am not in the mood of even trying to know who is FOB..sounds like a foreign object you don't want to see in your meal..

Sorry, forgot one little item..you will most likely ask what is a "dummy expression".
Something like: 1=1

And the other little point..if you don't want to see the children..and most parents don't...place a children browse on the form and hide it..

[SNusa]

Robert,

Have you considered the use of an inverted set arrangement? That's what I'd do. The grandchild become parent. It's linked one to one to the child. The child is linked one to one to the original parent which is now in grandchild position. Piece of cake. Now you essentially have a large flat table. Put what fields you want in your browse or on your form. Query the form based on a single parent and see all the grandchildren.

~Yes, that is essentially what I have done. Works nicely. Right now, i'm trying to establish the benefits/costs of using a mapped table as opposed to a regular table under different table/set scenarios...

You lost me at "FOB"..but I think I get the gist of what you are trying to do in generic terms and the answer is so simple and you don't have to xdlg anything:
Link the parent to the child with a dummy expression which will evaluate to true at all times, which in turn will show all children and therefore all grandchildren..
This should answer your question but won't answer mine: something wrong with the grand design..the concept itself..
The logic still escapes me...but as I said.. you lost me at FOB and I just had a couple drinks and a dinner at the Royal Sonista. a la French Quarter...so I am not in the mood of even trying to know who is FOB..sounds like a foreign object you don't want to see in your meal..

Sorry, forgot one little item..you will most likely ask what is a "dummy expression".
Something like: 1=1

And the other little point..if you don't want to see the children..and most parents don't...place a children browse on the form and hide it..

Thank you. This would work, but what I need to do is keep the tables linked, without needing to update a "dummy field" in the grandchild table. It's the interim table that is doing all the linking. (They way I am accomplishing this, I can always regenerate the data from the POS system without worrying about "reconnecting" it to the customer account.)

Also, Tim Kiebert's solution is "intriguing", but I'm having problems duplicating his example. ~ I keep running into errors when I try to insert the Xdialog (that is created from the browse while editing it via advanced -> create Xdialog in the a5 menu.) ~ http://msgboard.alphasoftware.com/al...l=1#post632932

I have to catch some z's......

[Ray in Capetown]

You lost me at "FOB"..but I think I get the gist of what you are trying to do in generic terms and the answer is so simple and you don't have to xdlg anything:
Link the parent to the child with a dummy expression which will evaluate to true at all times, which in turn will show all children and therefore all grandchildren..
This should answer your question

I don't think the intention is to see ALL grandchildren of ALL children - that just means the whole grand table (not in the French Quarter)
But all grandchildren of selected children - linked by a parent

[Ray in Capetown]

Maybe I'm overlooking something, but this is still the obvious simplicity.
Run a procedure to put the parent linking key (to child) also into a field in grandchild.
A simple one==link from parent to grandchild.??

Just once, then maintain (or update it periodically)

[G Gabriel]

This would work, but what I need to do is keep the tables linked, without needing to update a "dummy field" in the grandchild table.

We got our dummies confused here..
I am not talking about adding a dummy field..no need to add anymore dummies..God knows we have plenty of those as it is..
I am talking about linking with a dummy EXPRESSION..
I didn't delve too much into your scenario as I am not quite clear on what you are trying to do and I am attributing that to chemical imbalances inside my head for the time being..
Ray:
Yes he can add another link to the grandchildren..but, as you know, the fewer the links in the set the better.

[SNusa]

...Yes he can add another link to the grandchildren..but, as you know, the fewer the links in the set the better.

Maybe I'm overlooking something, but this is still the obvious simplicity.
Run a procedure to put the parent linking key (to child) also into a field in grandchild.
A simple one==link from parent to grandchild.??

Just once, then maintain (or update it periodically)

Hi everyone;

That's exactly what I am avoiding "needing to do", by doing it another way(s): I do not want to have to run ANY routines (other than a direct import) on the grandchild table (periodically to update a direct link to the top table in order to sync the table to the account holders.) Using the "middle" table allows me to create an indirect "pointer" to the child table. (So at any point, I can export all the data from the POS, and even replace that child table completely without loosing any previously established "links" from parent to grandchild. ~ Doing so overcomes/addresses the following scenario: This POS solution is a "cash based system" and in most instances there is no account holder data collected at time of sale. (Registering the customer fobs & creating an account is optional for the time being.) ~ And sometimes the key fobs are handed out to new "members" just prior to their first transaction.

Hope that explains the reasoning better. I was trying to work & "entertain" (my parents were visiting) during the past few posts.... I'm sure my prior explanations were "sketchy" at best.

Anyways, here are the ways I have come across thus far:

• Deselecting "parent record only" on the browse. (This would work great, but you can't scroll down to see all the records as the browse won't scroll properly.)
• Add a "dummy" direct link from parent to grandchild. (Necessitates updating and maintaining the grandchild table.)
• Only display parent & child on main form. (Link to grandchild data on separate form that opens, built on an inverted set.)
• Create an "inverted mapped table" and use this in place of the grandchild table using either Xdialog or the "Record List List Box." (Unless you're familiar with coding native Xdialog, you have to use the "list box method", which has some presentation limitations.)

I listed these methods above hoping that someone might offer another possibility I am overlooking... The first scenario would have been "perfect." ~ But due to browse related scroll bugs, you can't scroll down (as necessary) to see all the records. ~ At present, #4 is the second best. (Although I wish I knew Xdialog, so that I could correctly create and embed a browse into a form Xdialog cotrol.)

On a related/side note: I'm a little "distraught" knowing that Alpha can't/won't/hasn't provided a solution to AT LEAST scroll through the entire browse when the "parent records only" browse property is unchecked! The browse sees all the data, the "scroll navigation" just doesn't work... ~ If you open just the "stand-alone" (named browse) outside a form (although you can't scroll), you can vertically expand the window to see all the data!

~Seems to me that the browse object could be "tweaked" so that if it "knows" there is more data displaying outside the visible area (regardless of the vertical cursor location/index being reported back)... Then it needs to "keep on scrolling."

Also: Just uncovered another annoyance (bug).... You can't duplicate mapped tables (based on .dbf's anyways.) I had seen this before, but forgotten about it. When you attempt to duplicate them, you end up with an empty dbf, and not a map. ~ "Swiss Cheese."

[Ray in Capetown]

Ray:
Yes he can add another link to the grandchildren..but, as you know, the fewer the links in the set the better.

not adding one, removing the middle one, adding one field. Obtained from the parent, so it can therafter be dispensed for this purpose

[SNusa]

not adding one, removing the middle one, adding one field. Obtained from the parent, so it can therafter be dispensed for this purpose

Understood. But that would require additional maintenance on the import (grandchild) table. (to link the grandchildren to pre-existing registered accounts) ~ Not to mention that the grandchild table is (by far) the largest table, particularly since keyfob registration is optional.

The linking (middle/child) table facilitates adding new data at any time..... Any any re-usage of a pre-registered & pre-issued keyfob (at POS) will automatically "be linked" to the parent table! ~ The only time an extra step is necessary (during import) is when during POS data import, where any "newly issued" keyfobs get added to the middle (child/connecting table) with the parent/child linking field set to "uncommitted" during import. (So that they may be tied into/added to a parent account at any/later point in time.) This method also keeps the grandchild table much more "independent."

I should have mentioned this earlier: The reason this method "makes sense" (in this scenario) is that keyfob registration capability is an enhancement to an existing project. (Hence, keyfob registration is completely optional.) ~ Way back, I could have likely avoided "data normalization" and only kept a flat table. ~ Had I built it that way, I might have avoided the parent->child->grandchild set layout.