Are you always going to print it from the very top? Not jump to like a great-grandchild and print from them down? (which would make them the parent)

Yes, I'll always start from the top. Sort of. Actually, the data that I'm using is from another genealogy database called Brothers Keeper (v. 6 is a btrieve database) and the data in it is from GRANDMA (started with the Russian/Mennonite immigrants). There are over one million names in the copy that I have. I can export the "Family" that I want to a GEDCOM file. Then I use Access to put the data into the table that you see here. The FAMS field signifies that it's a spouse and the FAMC means it's a child. I also have another table where I have the FamilyIDs where it says it's a husband, wife, or child, but I don't think I need that information to do what I want to do. So, since I export the data that I want, starting with the 1st generation, I'll generally start at the top. I thought that I could also get the beginning personID from a form and then go down from there. So it could be 3 to who knows how many generations. Maybe 10 or more. I've attached a sample of my existing table. Me, my daughter, and my grandson.

If there's that much data, a query sounds like it would take a long time to load everytime you need it. I would probably just use a nested recordset and add a field that places them with a number, it's probably going to take a while to run the recordset through but you'd have the data available instantly after that. You could have it add the numbers as you add new members too quickly, but if you found/added an older generation you'd have to rerun the recordset to make #1 be #2, etc...

There is a lot of data in the main database, but I'll never export it all. Might be 2-3 hundred records at a time. My problem is, I haven't figured out the logic to use to do that. Richard Rost says they are "your" legos and you can put them together anyway you want. I has hoping I could get an example of how the query would be set up. Or how the nested loop would look.

I guess it would need to calculate at the time of making the report, because if A and B had a baby called C, then if you were looking through A's family tree, C could be the 5th generation, but if you looked through B's family tree and had more information, they could be the 8th generation or something. So you can't just assign a number unless you assigned mothers and fathers side.

So what information do you have when you go to start the report? I'll think up something, do you just click a button from inside a form? What information is available to use on that form? Is the highest tier parent ID on it per chance?

So I think I would build a temporary table, maybe to base the report on. I've been playing around with it. I remember seeing Richard join the same table together--like when there were employees and some of the employees were supervisors. Here is the SQL that first updates the Children to generation #2 from the father's PersonID. Then the next SQL updates the next generation to #3 from the MotherID of Generation #2 (run it again with FatherID to get the males) And you would just continue. It looks like these can all be run from VBA--one right after another. (I was using a temporary table called GWB) You could probably decide on how many generations to run and then use a variable and loop through the code where X = the Generation #.

UPDATE GWB INNER JOIN GWB AS GWB_1 ON GWB.PersonID = GWB_1.FatherID SET GWB_1.Generation = 2
WHERE ((([gwb]![PersonID])=652415));

UPDATE GWB INNER JOIN GWB AS GWB_1 ON GWB.PersonID = GWB_1.MotherID SET [gwb_1]![Generation] = 3
WHERE (((GWB.Generation)=2));