Examples where you might need several levels are: personnel ("A" is the boss of "B"), accounting (plan de cuentas), and production (Article "A" contains material "B" - some of the "materials" may be intermediate articles, which contain other articles).

Yes, you should use a single table. In the article example, you need the article table, and the composition table (to resolve the many-to-many relation: each article can contain several materials, and each material may be contained in multiple articles). The article table would contain everything from the material (materia prima) to the finished article (passing through intermediate article).

With a single table, each table needs its own primary key, and a reference to the primary key of the parent.

For hierarchical display, I would suggest a treeview.

HTH, Hilmar.

>Hi!
>
>
>My problem is as follows: I got to develop an app where the child records can Be of different levels or hierarchies (5 levels max ).
>For some reason I think that some times is easier to handle parent-child relations of multiple levels in just one Table (I hope I came across well)
>
>To establish a relation between a parent record and a child record is easy, you just need to create two fields (same approach you use in treeviews). The problem Comes up when I want to show the records in a grid in a hierarchical way, in order to do that I need to create a special field(s) that allow me to Establish the right order so that I can show the hierarchy properly.
>
>One of my solutions was this: let's say a parent record got an id=1 and that the next Parent record got an id=2, if I want to add a child record to the first parent record I just got to use a formula like this :
>
>ChildRecordId= ( CurrentParentRecordId+ NextParentRecordId)/2
>ChildRecordId=1.5
>
>(this is formula shows my idea in a simplistic way )
>
>This works to a certain extent, as soon or later I will run out of numbers for my Ids due to the nature of the numeric fields ( I need that any record can have n number of child records [no subnodes, although that would be great]).
>
>I know that using structures like lists, arrays , etc I could solve the problem (I could even have a hierarchy of n levels and all), but unfortunately I don't master Languages like C++ to get such solution.
>
>Another solution could be using the MSHflexgrid, but as far as I know this control is Read-only and each level of the hierarchy must be stored in a table.
>
>How can I solve this problem? Is there a way I can generate numbers or strings that Can give the right way to display my records? Is it normal or acceptable to store parent and child records in the same table or there are better and easier approaches ?
>
>
>Thanks in Advance