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?