ACCESS FEED: Re: [MS_AccessPros] Summing from a hierarchy

Kamis, 26 Maret 2015

Re: [MS_AccessPros] Summing from a hierarchy

John,

No. It links to a ParentID in tblParents. In tblParents you have a company (made up) Giant Bank (GB). GB has a number of subsidiaries, See a sample hierarchy below

>GB - ID1

Acct#ABC001

Acct#ABC002

>GB Mortgage - ID2

Acct#ABC123

Acct#ABC345

>GB Auto Finance - ID3

Acct#DEF123

>GB Collections - ID4

Acct#GHI123

>Medium Bank 1 - ID5

Acct#ABD345

>MB1 Mortgage - ID6

Acct#ABD678

>MB1 Loan Servicing - ID7

Acct#ABD999

>Medium Bank 2 (industry M&As) - ID8

...

> represents a Parent with a ParentID autonumber. ParentID would be unique/primary in tblParents. The field I called Parent (which I now realize I can't use in Access/SQL, so I now call ParentParent) is a long that points to another ParentID. For example,:

ParentID; Name; ParentParent

1; GB; null

2; GB Mortgage; 1

3; GB Auto Finance; 1

4; GB Collections; 1

5; Medium Bank 1; 1

6; MB1 Mortgage; 5

7; MB1 Loan Servicing; 6

8; Medium Bank 2; 1

tblNodes would have the following records:

ParentID; AcctNo

5; ABD345

5; ABD678

5; ABD999

6; ABD678

6; ABD999

7; ABD999

1; ABC001

etc.

Some Parents would only have a single AcctNo.

Regardless of the details of the setup, is this a good approach, to build (VBA) tblNodes via loops through recordsets? Is there a better/easier way?

Currently, there are about 6,000 records in tblAccounts, 4,500 records in tblParents, only a couple of hundred of which are children of other parents. I'm guessing tblNodes would end up with about 8,000 records.

P.S. Your adopted country need some serious PR.

---In MS_Access_Professionals@yahoogroups.com, <JohnV@...> wrote :

Adam-

I don't get what tblParents is doing. That looks the same to me as your proposed tblNodes. Doesn't the ParentID in tblClients link to another client? That's the chain I would think you would follow.

John Viescas, Author

Microsoft Access 2010 Inside Out

Microsoft Access 2007 Inside Out

Microsoft Access 2003 Inside Out

Building Microsoft Access Applications

SQL Queries for Mere Mortals

http://www.viescas.com/

(Paris, France)

On Mar 26, 2015, at 9:09 PM, runuphillracing@... [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:

John,

Think of it is somewhat like a BoM.

One problem with changing it on the fly, I think, is how do I write that SQL if there can be 0 to infinite (theoretically) levels of children - an unknown number of "In (SELECT" nests.

Another is that, in addition to viewing each Parent individually, I also want to view them as a list, ranked by revenue (descending).

What do you think of the idea of creating an additional table, let's call it tblNodes?
tblNodes
   *ParentID (long, link to tblParents)
   *AcctNo(text, link to tblAccounts)
*Combined make the primary key

This would contain a list of all parents (nodes), and all AcctNos under that node. I would create this table by looping through the tblParents, tblClients, and tblAccounts. I would have to recreate this table each time a new account or client is added/deleted or hierarchy changed, but that's much less frequent than every time my forms are current. The forms (list and individual Parent view) would be based on a query combining tblNodes, tblAccounts^, and tblRevenue.

^I realize that tblAccounts and tblClients should be combined into a single table:
   *ClientID (auto)
ClientName (text)
   ParentID (long)
   *AcctNo (text, alphanumeric)
AcctName
   ProductType (text)
*ClientID and AcctNo make the primary key.

What do you think of this approach? Is there a better way? What else can I do to explain this better?

Thanks
Adam

---In MS_Access_Professionals@yahoogroups.com, <JohnV@...> wrote :

Adam-

It's not clear what you're trying to do.

Yes, you can change the Record Source of a Form on the fly by assigning the appropriate SQL to the RecordSource property.

John Viescas, Author
Microsoft Access 2010 Inside Out
Microsoft Access 2007 Inside Out
Microsoft Access 2003 Inside Out
Building Microsoft Access Applications
SQL Queries for Mere Mortals
http://www.viescas.com/
(Paris, France)

On Mar 26, 2015, at 4:40 PM, runuphillracing@... [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:

Repost. I'm looking for help in summing from children, grandchildren, etc., in a hierarchical relationship. See original post below.

I know how to create a recordset with this data, but I don't know how to have a form's recordsource be based on a recordset created at that time. I suppose I could make a table each time, but that seems inefficient. Is that how I should go? Is there another way?

---In MS_Access_Professionals@yahoogroups.com, <runuphillracing@...> wrote :

I have clients set up in a hierarchical relationship. I want to be able to move (on a form) up and down the tree levels showing totals at each node for all the children, grandchildren, etc., under that node.

The key tables and fields (not all fields listed, just enough to explain, I hope) I have (so far) are:

tblClients:
ClientID (auto)
ClientName (text)
ParentID (long)

tblAccounts (a client may have multiple accts)
AcctNo (text, alphanumeric)
AcctName
ProductType (text)

tblParents
ParentID (auto)
ParentName (text)
Parent (long, ParentID of this parent, if there is one)
SalesRep

tblRevenue
AcctNo (text)
Revenue (currency)

I know how to sum from one level below, but not sure how to get beyond that.

Thanks
Adam Feerst
Denver, CO