Unless you insist on using treeview control, there is one old solution
of creating hierarchy of stock items which worked just fine for me.
Idea is similar to general ledger chart organisation.
It works basically like lookup to items table.
So you will be having one table maintaining hierarchy
Like ;
001 General Stock
001-001 Electronics
001-001-001 Consumer Electronics
001-001-001-001 Televisions
001-001-001-002 Stereo Systems
.
.
001-001-002 Electrical Tools
.
001-002 Plastics
....
002 Food
002-001 Baby food
002-002 Spices
.
From item side all you build is simple lookup / foreign key field,
pointing directly to classification where it belongs.
ItemId 12345
ItemName Sony Bravia ...
ClassGrp 001-001-001-001
.
ItemId 12346
ItemName Humana Fruit Cream
ClassGrp 002-001
It of course needs index tag in products table to connect the two.
That is that long hkey (In my version I use also shrinked key like '1-1-2') pointing to its place in hierarchy. Or if you want it can be even dummy ID integer as pointer.
I hv built myself class object (session) maintaining that 'tree' structure
separately with help of one small supporting table defining tree parameters. This way I can 'talk to it' just like you can do with real treeview activeX :)
oItemTree.add_root()
oItemTree.get_parent(cHKey)
oItemTree.get_level(cHKey)
.
.
etc.
In this case dept of hierarchy is of course limited but it can be build quiet sufficient. Aldough is possible to easily extend it (add space to hkey field) , I never used more then 9 levels.
As result, you get very fast operations. To present hierarchy, I use ordinary grid with space indented group names resembling pretty well tree look.
When it comes to reporting, unlike with activex data structure, you can use that 'flat' hierarchy key to built relatively easy all kinds of grouped reports.
>Hi friends,
>
>I use to create one table for each information like this:
>
>Table_A Table_B Table_C
>ID_A 1-------+ ID_B 1--------+ ID_C
>GroupName | SubGroupName | ProductName
> +----N ID_A +---N ID_B
>
>
>This way is easy to get the products that are part of some subGroup or Group. But I have a problem here, because I limited it to 3 levels (Group / SubGroup / Product).
>
>Now I have a problem that I can't say 3 or 5 or 9 levels. So, I think I have to do that:
>
>Table_A Table_C
>ID_A 1-------+---+ ID_C
>GroupName | | ProductName
>ID_A_Main N--+ +---N ID_A
>
>
>So, I can add any number of levels I want. And I can't add a Product for a Group that has a "Main Group". Until here, no problem.
>
>My question is: After users add a lot of groups, they will want to get some information about one major group or any other level. Beside that, they will want to print a report divided by Group / SubGroup / SubSubGroup / ... / Product.
>
>Said that, I have no idea how handle it! Anybody can help me?