>Hi Bret,
>
>In your case, I think that you are best served with a join table and get rid of the parent task fields in the main task table. Consider this: if you have a join table with ParentTask and ChildTask fields, then you can imply the Child-Grandchild-Greatgrandchild relationship.
>
>Now, your SQL statements are going to be a bitch in this scenario, and I'm not sure how you're going to pull it off in Access.
>

I don't see how a separate join table helps me. It looks as if it would contain the information I already have in basically the same format. Perhaps I misunderstand the format of the join table you have in mind.

I still don't think the desired cursors can be built with SQL at all. I can't prove it. If there were a set maximum number of levels of grouping, the SQL might contain that many self-joins, perhaps. But the boss says that there is no maximum. Writing the recursive procedure doesn't sound impossible. It would be DAO code in Access and xBase code in VFP. The algorithm would be the same.

Running the report in Access, I'll probably open the report in runtime and add group objects, or something (I haven't really studied the Access report object model yet). Doing the same thing in VFP would involve hacking the report in a pretty harsh way, I guess. Perhaps you'd have to append entire records to the report table. You'd have to know the report format cold (at least know it better than me), and would have a QA nightmare. One might just stick to textmerge.