Попробуй что-то в этом роде:

Где sIn(0) = "Мid": sIn(1) = "Жid" - соответственные индексы в семье (муж,id), (жена,id), СемьяРебенок - в "детях", возрастающие по обоим полям. Отладил вчерне. Мож что поизячней нарисуешь.


По поводу "конфликта" саныч неправильно выразился. Там не будет конфликта программного (если не закрывать рекордсеты на уровнях явным образом). Там при возврате из вложенной процедуры будешь иметь совсем не тот рекордсет, который был задан на ЭТОМ уровне рекурсии (он переопределится на другом). Т.е. "конфликт" логический.

авторд.б. таким же - они супруги

ответ неверный. есть случаи нескольких семей у персоны. гаремы, опять же. и бастарды. :о)
и все равно прогонка по индексированному рекордсету (курсору - на сервере) должна работать (в данном случае) быстрее нескольких запросов. А именно - за счет "подготовки" запросов.


Да, и в случае разделенных данных/кода вместо set dbs=currentDb, открывай DB данных.

авторВремя работы на больших таблицах осталось прежним
не мудрено, если таблицы не индексированы по полям, по которым идет поиск (тут, у лободавы, не помешают индексы (Fam,Papa) и (Fam,Mama), причем как будут себя вести индексы при OR в ON в JOIN-е фих его знает. Возможно лучше (для больших таблиц) разбить запросы на 2 запроса - отельно по папам и отдельно по мамам).

для процедуры прогонки по рекордсету индексы (их имена) приведены в коде, состав полей - под ним.

для запросов со связями (или со сложным WHERE) индексы должны быть по возможности отсеивающими большую часть таблиц по условию. Для связи по нескольким полям - индексы должны быть составными по всем полям связи (если такая связь не определена как связь с поддержанием целостности на уровне схемы данных - т.к. в последнем случае Аксесом автоматически создаются служебные индексы (вторичные ключи), не отображаемые во вкладке "индексы" таблицы). Причем они должны быть одинаково структурированными для обеих связываемых таблиц..

соображения такие:
рекурсия приводит к сохранению на каждом уровне переменных уровня рекурсии

Dim i As Long, nS As Long, nR As Long, iSx As Long
Dim sIn(0 To 1) As String

не думаю, что пара тысяч этих переменных убьет процесс. Но вот каждая процедура должна при рекурсии еще и помнить, куда она должна вернуть результат/управление. Что там происходит - а бог его знает.

Посему, если грешить на рекурсию и переполнения, а не на банальный баг, который где-то недочищен (и зацикливает процедуру при редком сочетании данных), имеет смысл избавиться от рекурсии. Идея - в решении lobodava (в циклическом переборе по поколениям).


Но, видимо, имеет смысл не выполнять запросы, а в предложенном мной цикле выбросить рекурсивный вызов процедурой самой-себя, добавить параметры вызова (вернее - переменные уровня модуля), необходимые для нового вызова процедуры для следующего поколения из внешней процедуры-цикла (видимо - 2 массива: 1. массив потомков данного уровня, 2. массив потомков следующего, и, возможно, номер уровня) а во внешней процедуре вызывать процедуру в двойном цикле - до возврата пустого массива потомков следующего уровня, а во внутреннем цикле (двойного, внешней процедуры) - и осуществлять вызов - по массиву потомков текущего уровня (заполняя одновременно массив следующего). Почему массивы? Потому что иначе придется повторять операции чтения (вытягивать данные запросами, пусть и по индексированным таблицам), что дольше.


предполагаемый выигрыш: - освобождение от рекурсий и вместо смены индекса и поиска практически всякий раз Seek-ом, можно после первого Seek делать просто MoveNext (индекс то задан, и не меняется ни он, ни положение текущей записи в рекурсивных вызовах), до выхода по сравнению ключа. Что быстрее.

затраты: - 2 массива Long, переменной длинны, объявленные на уровне модуля, приватные; но на потомков только одного уровня (если будем вычислять потомков Адама или Евы, боюсь, памяти простой персоналки не хватит, но и запросы на таких объемах - не фонтан, результаты же их все равно надо куда-то складывать, если только не пытаться открыть рекордсет с последовательным доступом и т.п...). + Минимальная переделка процедуры FindDescendantT (выброска ре-Seek-ов и ре-Index; замена самовызова на блок пополнения массива потомков следующего уровня); и написание процедуры ее вызова как FindDescendantT(Pc(i), iGeneration) в цикле. (первый вызов - как и было).

Вот только не найдем ли мы в итоге логический "баг", наподобие ошибки в данных - нахождение кольца по предкам/потомкам? Или еще чего.

___
ЗЫ : ДА, есть теоретический вопрос. Если пипл является потомком другого более чем одного уровня (по паре веток разной длинны), то и его потомки будут дважды считаться в таблице потомков :). Что об этом случае думает генеология? (хорошо, что чел не может быть собственным предком, но база, кстати, об этом не знает - если нет триггеров/правил, отслеживающих кольца).

и все таки мыслится, что если процедура именно "останавливается", то надо посмотреть на вероятные баги в режиме отладки (уж очень мало). Очень может быть, что чегой-то я недоглядел.

Но есть и идейка о том, что задалбливают перечтения индексов, количество которых (перечтений) растет быстрее, чем число потомков (по возвращению из рекурсий со сменой пола - новое перечтение). Одна надежда, что индексы в кеш влезают.