Sequential record numbering within "parent" group
Greetings all...
I'm setting up a hierarchy of three related datasets. The governing entity is a PROJECT. A PROJECT may in turn contain multiple ZONES, and each ZONE may in turn contain multiple OBJECTS.
I'm experiencing a brain cramp. Typically I would let Access assign unique ID numbers (autonumbering) for each new ZONE that is created within a PROJECT, but in this case, it will be important for the users to have a "handle" for each ZONE which they can use in referencing any ZONE. This kind of easily identifiable "handle" would not really exist (unless of course the user was asked to assign the ID for each new ZONE), because with autonumbering, the assignment of new ZONES won't have any discernible pattern: the first ZONE for any PROJECT may be assigned ID #345, the second may be assigned #962, and so on.
Maybe I'm just worrying about aesthetics, but it would be nice to have the first ZONE assigned to any PROJECT receive ID #1, the second #2, and so on. So the "Big River" PROJECT has ZONES 1 - 15, the "Little River" PROJECT has ZONES 1 - 9, and so on. My gut feeling is that the only way to gain this sort of autonumbering would be to set the ZONE ID field as LONG, automatically create ZONE 1 when the PROJECT is created, and then fire off a manual routine each time a new ZONE is created which would determine the MAX number that has already been assigned within that PROJECT and just increment it by 1. Index the ZONE table on both PROJECT ID and ZONE ID. Then repeat the same process in the OBJECT table, indexing that table on PROJECT ID, ZONE ID and OBJECT ID.
Do I think aright? Or am I forgetting an obvious element of functionality that Access provides that would handle this kind of repetitive numbering within "Parent" groupings?
Thanks, folks. I never cease to be amazed at the breadth and depth of talent out there, and I look forward to your feedback.
...Jed
I'm setting up a hierarchy of three related datasets. The governing entity is a PROJECT. A PROJECT may in turn contain multiple ZONES, and each ZONE may in turn contain multiple OBJECTS.
I'm experiencing a brain cramp. Typically I would let Access assign unique ID numbers (autonumbering) for each new ZONE that is created within a PROJECT, but in this case, it will be important for the users to have a "handle" for each ZONE which they can use in referencing any ZONE. This kind of easily identifiable "handle" would not really exist (unless of course the user was asked to assign the ID for each new ZONE), because with autonumbering, the assignment of new ZONES won't have any discernible pattern: the first ZONE for any PROJECT may be assigned ID #345, the second may be assigned #962, and so on.
Maybe I'm just worrying about aesthetics, but it would be nice to have the first ZONE assigned to any PROJECT receive ID #1, the second #2, and so on. So the "Big River" PROJECT has ZONES 1 - 15, the "Little River" PROJECT has ZONES 1 - 9, and so on. My gut feeling is that the only way to gain this sort of autonumbering would be to set the ZONE ID field as LONG, automatically create ZONE 1 when the PROJECT is created, and then fire off a manual routine each time a new ZONE is created which would determine the MAX number that has already been assigned within that PROJECT and just increment it by 1. Index the ZONE table on both PROJECT ID and ZONE ID. Then repeat the same process in the OBJECT table, indexing that table on PROJECT ID, ZONE ID and OBJECT ID.
Do I think aright? Or am I forgetting an obvious element of functionality that Access provides that would handle this kind of repetitive numbering within "Parent" groupings?
Thanks, folks. I never cease to be amazed at the breadth and depth of talent out there, and I look forward to your feedback.
...Jed
I have an application where entities are added with an autonumber PK but also have a sequence number which is meaninful and which will not be changed unless the user changes it. (This might be a problem with the solution above- if a zone is deleted the others would get different numbers- is this what you want?)
When the user adds a zone I assign it a new sequence number in the BeforeInsert event, by finding the next available number. (If 1,2, and 3 have been used it will be 4, but if 2 has been deleted the new one will be 2.) I do this in a small routine that reads through a recordset that contains the entities that are children of the same parent. I also provide a button on the form to "compress" the numbers, so that if an entity has been deleted leaving the numbering as 1,2,4,5 it will move 4 and 5 down to fill the gap.
I can post code samples if it would be useful.
When the user adds a zone I assign it a new sequence number in the BeforeInsert event, by finding the next available number. (If 1,2, and 3 have been used it will be 4, but if 2 has been deleted the new one will be 2.) I do this in a small routine that reads through a recordset that contains the entities that are children of the same parent. I also provide a button on the form to "compress" the numbers, so that if an entity has been deleted leaving the numbering as 1,2,4,5 it will move 4 and 5 down to fill the gap.
I can post code samples if it would be useful.
ASKER
Thanks to you both, Shane and Clippit...
Shane, I absolutely agree with you in principle regarding the use of autonumbers. However, as you suggest, if zones are deleted (and this will inevitably happen, unfortunately) "the results might become unpredictable".
Clippit, it sounds like we're onto something here. And yes, a few code samples would defitely help me orient. The compression functionality is probably more than I'll need; I don't mind a deleted zone burning a numeric assignment as long as the results are (for example) 1, 2, 3, 5, 6 ... that would still be very workable within the environmental context.
Thanks to you both. I'll leave the question open for another day or two for Clippit and I to yak a bit more ...
...Jed
Shane, I absolutely agree with you in principle regarding the use of autonumbers. However, as you suggest, if zones are deleted (and this will inevitably happen, unfortunately) "the results might become unpredictable".
Clippit, it sounds like we're onto something here. And yes, a few code samples would defitely help me orient. The compression functionality is probably more than I'll need; I don't mind a deleted zone burning a numeric assignment as long as the results are (for example) 1, 2, 3, 5, 6 ... that would still be very workable within the environmental context.
Thanks to you both. I'll leave the question open for another day or two for Clippit and I to yak a bit more ...
...Jed
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Once again, many thanks for your thoughts...
You're welcome- thanks for the grade.
However, you could determine which zone a particular record is, within its parent. An expression like this:
DCount("*","ZONES","[ZoneI
on a form that contains the zone's autonumber in txtZoneID and the projectID in txtProjectID would tell you which zone that is in relation to its project. So for example, if project 12 has zone records 345, 346 and 347, the expression would display 2 for zone 346, since there is 1 zone with a lower number than itself for projectID 12. This would only work though if zones were never deleted from that project.