General Logic for LOOPING process needed

[Sam Ceccola]

Another senior moment. I am having trouble getting the logic down on a flow chart so that I can code it.

I'm using VB 6 but that's not the issue. The issue, as stated before is the logic. Once I have that, I can code it.

Here's what I need to do:
Can anyone give me an example or show me how to do LOOP processing?

I am doing a AssemblyPart explosion. Example:
To make a Desk, it has 3 (Level-1) Assemblies:
Assemblies-1 is the TOP
Assemblies-2 are the SIDES
Assemblies-3 are the LEGS

Assemblies-1(TOP) may have 2 sub-assemblies (level-2):
Assemblies-4 Formica
Assemblies-5 board

Then Assembly 4 & 5 may have sub-assemblies
When I get to the end of all nested sub-assemblies for Assembly-1, I then come back and process Assembly-2 the same way. Keep going until I exhaust the Level-1 Assemblies. The number of Level-1 assemblies can vary, therefore the number of level-2's can vary, the same with level-3, etc.

It would be very difficult to predict the maximum number of level-1's and sub-levels.

Sam
__________________

[kelly]

Don't know, it's been quite a while since I did any programming. Maybe you need to use a counter for each Assembly and define the values when it runs.
-td

[Terry Hanushek]

Sam

If I read your problem statement correctly, you have three levels, Assemblies Sub Assemblies and Sub Sub Assemblies (level 1, level 2 and level 3). I am not sure how your data is organized but I will assume you are able to identify its hierarchy (which level 2's belong to a level 1, etc.)

With this structure, you can use a three level loop structure to process all of the assemblies.

START
Initialization
 
Loop1
Readnext Level 1  ..  at end goto END
Process Level 1
Perform LEVEL2 thru LEVEL2EXIT
Go to Loop1
 
LEVEL2
 
Loop2
Readnext Level 2  ..  at end goto LEVEL2EXIT
     Note: at end condition implies no more level 2's for current level 1
Process Level 2
Perform LEVEL3 thru LEVEL3EXIT
Go to Loop2
 
LEVEL2EXIT
 
LEVEL3
 
Loop3
Readnext Level 3  ..  at end goto LEVEL3EXIT
    Note: at condition implies no more level 3's for current level 2
Process Level 3
Go to Loop3
 
LEVEL3EXIT
 
END
Wrap up

This is a general structure for processing three levels of data. Depending on the language, data structure and processing requirements there can be variations. The 'Perform' can be replaced with a 'Do While', the 'at end' can be replaced with an 'Until'. This should get you started.

HTH

Terry

[Sam Ceccola]

Terry:

Thank you for your reply but your example will only go 3 levels deep. The number of sub-levels can vary. The maximum number of sub-levels is almost impossible to predict.

Maybe, think of a PC, Car, Plane . Assume these are level-1's.
A PC is made up of (level-2)circuit boards (MB, video, ethernet,etc). A MB is made up with (Level-3)Parts(processor, memory,etc) the processor is made up of (Level-4) case,screws,etc). This example has 4 levels. After these are processed, I want to check to see if there are anymore Level-1's.

I would then process a Car. This was a level-1. A car is made up of (level-2) tires,body; the tires have no sublevels(level-3) but the body has Level-3's(doors, windows), etc.

I'm sure you get the drift.

[Terry Hanushek]

Sam

Thank you for your reply but your example will only go 3 levels deep. The number of sub-levels can vary. The maximum number of sub-levels is almost impossible to predict.

It seems like the number of levels would be related to your data structure which should be predictable. Is it hierarchal? Is it fixed or dynamic? It seems to me that once your data structure is nailed down then you can develop you programming logic.

I'm not sure if you are saying that the absolute number of levels can change or that not every level has all sub levels (like the tires in your example above). The former would be difficult to address, the latter can be addressed with the structure I outlined (perhaps with additional levels to match the data structure).

Terry

[Sam Ceccola]

Terry:
I may need to re-think the data structure. Currently, it is a MS Access database with several tables. Two of the tables are written to during processing (Assemblies, Assm_Parts). The Assemblies table contains the assembly number that is used in any level. The Assm_Parts table contains the parts that make up an assembly. During processing, if there is an Assm_Part that in itself is an Assembly(sub-Assembly), that sub-assembly number is placed in the Assemblies Table.

I have the logic written but I am only getting Level-1's and Level-2's.

[Sam Ceccola]

Terry:

Based on a couple things you said, I think I may have a workable solution. The way the logic is currently doing the processing is getting the Level-1, then the level-2's, then level-3's, etc and when I am all done with the sublevels, get the next Level 1.

A possible workable solution:
Get all the level-1's, then get all the level-2's for all the level-1's; then get all the level-3's for all the level-2's, etc.

I can add a field to the table called LEVELS and keep track of the current record and level I am working with. What do you think?

Sam

[Sam Ceccola]

Hey folks, I got it. close this thread.

[Terry Hanushek]

Sam

I may need to re-think the data structure. Currently, it is a MS Access database with several tables. Two of the tables are written to during processing (Assemblies, Assm_Parts). The Assemblies table contains the assembly number that is used in any level. The Assm_Parts table contains the parts that make up an assembly. During processing, if there is an Assm_Part that in itself is an Assembly(sub-Assembly), that sub-assembly number is placed in the Assemblies Table.

I have the logic written but I am only getting Level-1's and Level-2's.

I had assumed that you were accessing an existing hierarchal database which described your assemblies. You appear to be building the tables in your processing.

What is the nature / format of the input that you are using to build your tables?

Without knowing how the two tables are being built, it appears like you are identifying singular relationships (father / son). It is not clear if or how you are identifying multiple relationships (grandfather / father / son). This may be why you are getting only level 1's and level 2's.

What is the objective of your processing? What is your intended output? Are you trying to develop costs for assemblies? bills of material?

Another question - can a component be part of more than assembly?

Based on a couple things you said, I think I may have a workable solution. The way the logic is currently doing the processing is getting the Level-1, then the level-2's, then level-3's, etc and when I am all done with the sublevels, get the next Level 1.

A possible workable solution:
Get all the level-1's, then get all the level-2's for all the level-1's; then get all the level-3's for all the level-2's, etc.

I can add a field to the table called LEVELS and keep track of the current record and level I am working with. What do you think?

Without a clear picture of the input data and output requirements, it is difficult for me to suggest a processing approach. I do believe that the successful solution depends on the proper organization of your data.

Terry

[Freehold Fred]

Dunno about the logic (I'm a senior, too), but the possible command tools to dig out are:
DO WHILE
DO UNTIL
WHILE/WEND
CASE