>Cetin,
>
>The relationship is that of parent-child.
>Imagine you have a desk which consists of a top,a back, 2 sides,and four legs and 2 pedestal (the boxes the drawers are in) and 2 grommet kits
>
>The pedestal contains 2 sides, a top, a bottom and 8 #12 flathead screws, and 2 file drawers and 2 grommet kits.
>
>The file drawer contains a front, 2 sides, a back and a bottom and let's say 4 #12 flathead screws
>
>
>Here is the bill of meterials for this hypotethical desk:
>desk
>--top 1
>--back 1
>--sides 2
>--legs 4
>--pedestal 2
>----sides 2
>----top 1
>----bottom 1
>----flathead screws 8
>----grommet kits 2
>------grommet
>------grommet cover
>----file drawers 2
>------front 1
>------sides 2
>------back 1
>------bottom 1
>------flathead screws 4
>--grommet kits 2
>------grommet
>------grommet cover
>
>
>
>As soon as you get to the bolded grommet whose parent is the grommet kit the treview chokes, it does not know which parent to look at (not unique key) so i have:
> pedestal-grommet kit
> desk-grommet kit
>
>But I am afraid if i have a very deep BOM I could extend the keylength of the treeview.
>
>
>I guess what I can do is use unique keys for all parts and create a lookup cursor to translate the temporary keys into the real keys
>
>Or concatenate the keys
>
>
>I hope that clearifies the problem
>
>
>Peter



Concatenation is a good solution.
I use it in one of my applications.

I am using a fixed len key and concatenate it along the tree and the key was always unique.
This way, simply by usign the key I can say at which level I was and get the ID of every parent on the path.

Example, with a 5 chars key, if you have "123AB123CD123EF" as a key, you know that you are at level 3 (len/5), the parent is "123CD" and the grand-parent is "123AB".