Галактика в вопросах и ответах

При работе с древовидной структурой основанной на таблице в памяти замечена очень нехорошая деталь: быстрый поиск работет только внутри уровня на котором находишься. Станешь на корень - ищет только по верхнему уровню, стоит войти внутрь узла - ищет только внутри узла. Также не получается поюзать стандартные функции типа JumpToRecord(Ex) и т.п. Они вроде бы работают, но приводят к диким и непредсказуемым результатам типа немерянного размножения узлов. Подозреваю, что дело может быть в описании структуры таблицы. Вот она:
Table Struct ttK1 (
FC_KOD : Comp, //Код записи
FC_GKOD : Comp, //Код группы
FC_NAME : String[50] //Всё остальное
)
with index (
IDX1=FC_KOD,
IDX2=FC_GKOD,
IDX3=FC_NAME
);

create view W1 as
select *
from ttK1
where
((CurGroup==ttK1.FC_GKOD));

Работа дерева описана так:

cmTreeTop: CurGroup:=0;
cmTreeUp: CurGroup:=ttK1.FC_GKOD;
cmTreeDown: CurGroup:=ttK1.FC_KOD;
cmTreeNodeType:
{
if ttK1.FC_GKOD <> 0
TreeSetNodeType(trKARDS,2);
}

В чём может быть дело?

Дело не в написании структуры, а в функционировании самого дерева.
Это также не будет работать на физической таблице.

Логическая таблица и события интерфейса, определяющие построение дерева, так влияют. Система никогда не будет искать те записи, которые не подходят под текущие ограничения (будь то подцепка или фильтр). Когда мы стоим на каком-то нижнем уровне дерева, то в текущем наборе записей логической таблицы не будет ни одной записи со ссылкой на родителя равной нулю(верхний уровень) и никоим боком она их не найдет. Соотвественно если мы на верхнем - то с нижними такая же ситуация.

Дерево в галактике - это не стандартный Windows'кий контрол (он вообще крайне неудобен для инкапсуляции в какой-либо класс для отображения иерархической информации из БД), это нечто List'о- или ListView-образное. И для корректного отображения дерева как раз и нужны описанные в примере события, которые как раз и накладывают эти ограничения на логическую таблицу , не дающие на нижнем по поиску выходить на верхних и наоборот.

По поводу JumpToRecord - тут разговор особый . Переданный ему параметр система считает уникальным идентификатором записи(самая первое поле) в таблице по которому есть уникальный индекс с номером 0 ( так мне объяснили в Минске в Топ-Софте) - то бишь NRec в обычных таблах, а код группы как в Вашем случае . JumpToRecordEx - это отдельная песня, он аналогичен не-Ех, но предназначен для деревьев , построенных нескольких таблицах и на одной табле может привести к непредсказуемым последствиям