S
Steve
Hello All,
I am working with a set of data for which I need to produce a sorted
hierarchy (1.1.1.1.1.1. ...) list. There seems to be no limit to the
number of levels, though I am using 12 levels as a practical limit.
Each record has 3 fields to define its position in the hierarchy: ID,
Parent, Position. The ID is a unique identifier that has no relevance
to that record's position in the hierarchy. The Parent is the ID for
the record that that item is subordinate to and the position is the
order where that item falls relative to all of the other IDs with the
same Parent. All level 1 IDs have a common Parent with a very high ID
number.
What I did, and it works fine, is to create an inquiry that lists the
children of the root node Parent and assign a hierarchy number using
that IDs position with a 0 for all subordinate hierarchy levels. So
the first element would be ID and the position would be
1.0.0.0.0.0.0.0.0.0.0.0. Each subsequent inquiry uses that result to
identify records with those IDs as parents and appends their position
number to their hierarchy, so I would now have a list of
1.1.0.0.0.0.0.0.0.0.0.0, 1.2. . . . and so on through a series of 12
such inquiries. I then join the lists with a union query and sort at
each level, ending up with a sorted list of IDs in their correct
hierarchy order.
My problem is that this approach is slow and messy. I have a pretty
fast machine, but some of the users of this tool will not. I also need
2 instances of the set of queries, since I am doing this to produce a
report of hierarchy position changes for sequential instances of this
data.
I am using Access 2003, but imagine I will need to test and provide it
in earlier versions for some of the users. The data resides in 3rd
party commercial software (paradox based) and I can only read the
source data and cannot add to it or modify it at its source in any
way. The users may want to run it dynamically, that is to iteratively
make changes in the source then view the report, so latency is
important.
If anyone has any suggestions for a better way to do this, thanks in
advance.
Steve
I am working with a set of data for which I need to produce a sorted
hierarchy (1.1.1.1.1.1. ...) list. There seems to be no limit to the
number of levels, though I am using 12 levels as a practical limit.
Each record has 3 fields to define its position in the hierarchy: ID,
Parent, Position. The ID is a unique identifier that has no relevance
to that record's position in the hierarchy. The Parent is the ID for
the record that that item is subordinate to and the position is the
order where that item falls relative to all of the other IDs with the
same Parent. All level 1 IDs have a common Parent with a very high ID
number.
What I did, and it works fine, is to create an inquiry that lists the
children of the root node Parent and assign a hierarchy number using
that IDs position with a 0 for all subordinate hierarchy levels. So
the first element would be ID and the position would be
1.0.0.0.0.0.0.0.0.0.0.0. Each subsequent inquiry uses that result to
identify records with those IDs as parents and appends their position
number to their hierarchy, so I would now have a list of
1.1.0.0.0.0.0.0.0.0.0.0, 1.2. . . . and so on through a series of 12
such inquiries. I then join the lists with a union query and sort at
each level, ending up with a sorted list of IDs in their correct
hierarchy order.
My problem is that this approach is slow and messy. I have a pretty
fast machine, but some of the users of this tool will not. I also need
2 instances of the set of queries, since I am doing this to produce a
report of hierarchy position changes for sequential instances of this
data.
I am using Access 2003, but imagine I will need to test and provide it
in earlier versions for some of the users. The data resides in 3rd
party commercial software (paradox based) and I can only read the
source data and cannot add to it or modify it at its source in any
way. The users may want to run it dynamically, that is to iteratively
make changes in the source then view the report, so latency is
important.
If anyone has any suggestions for a better way to do this, thanks in
advance.
Steve