Есть 1с 7.7 27 версия и база в файловом варианте и в ней справочник "Номенклатура" с 15 000 позиций.
Когда в его списке (при откл. режиме вывода по группам) первый раз кликаешь на иконку "Найти в дереве", то всегда находит и показывает маркером слева в дереве папку-родитель, НО стоит ещё выбрать в списке любую другую позицию и второй раз "Найти в дереве", то 1с думает 5-7 сек. и тупо вываливается без каких либо предупреждений.
Пробовал уже всё: Исправление и тестирование базы, удаление и пересоздание индексов, удаление и пересоздание DD-файла, НО ничего не помагает.
Грешит на ОС и на 1С не могу, так как в другой папке есть аналогичная файловая база с 18 000 позициями, которая команду "Найти в дереве" отрабатывает на все 100%.
Подскажите пожалуйста куда копать и в чём может быть проблема?
Спасибо за ответы.

Зациклен родитель

(1) В смысле. Это как? Можно по-подробней пожалуйста.

У группа1 родитель группа2, а у группа2 группа1.
Может быть через какие-то промежуточные элементы

7.7 гамно. переходите на 8

(3) А как такое 1с позволяет делать?
(4) Когда будет (8.Финальная версия) так и сразу будем переходить

(5) да? а чо, 7-ка была "финальная"? да это всю несознательную жизнь был инвалид, которого утыкали костылями как кактус иголками.

(6) Непросто слезть с 7-ки уж много плюшек в ней прикручено.

(0) Повторюсь, что ЛЮБУЮ позицию находит в дереве с первой попытки, вторая попытка - КРАХ 1С.

Выгрузи и загрузи БД. (Ещё хорошо бы сравнить исходную и полученную, но готовых инструментов я не видел).

(9) Уже пробую

(0) Очень интересно
А если второй выбрать ту позицию, которая первый раз прокатывает? Т.е. дело именно во втором разе?

(6) Ты сам-то имел дело с 7.7 в сознательном возрасте?
Там есть ООП и проч. в виде "палок и иголок", которого нет в 8.х до сих пор

(9) НЕ ПОМОГЛО, к сожаленью
(11) Не зависит от конкретной позиции, а зависит от самого раза (со второго - "ЧАУ"),позиция  которая находилась в дереве с первого раза в любом варианте, если будет выбрана для поиска в дереве вторым разом вылет 1С обеспечен.
Кстати смотрю утилитой монитора файлов от systernals, то вижу что буксуется 2 файла sc135.dbf и sc135.cdx (в DD - Номенклатура) , но как писал выше убивание cdx и пересоздание оного положительного результата нет.

(12) ой-ой.. ну-ка поведай нам, а то я что-то упустил

(3) 1c так не позволяет делать. Но бывают глюки. Даже на sql-базе пару раз ловили такое зацикливание.

(13) Напиши обработку по поиску зацикленного родителя

Вообще по доброму - сделать бэкап, все элементы перенести в корневую группу.

В смысле на копии сделать (17). Отписать сюда.

(16) Или sql-запросом удалить все строки, у которых родитель равен идентификатору. Для dbf можно использовать даже древний фокспро.

Для дбф можно даже использовать саму 1с.
Xbase еще никто не отменял.

(16), (19), (20) Пробую уже..

(19) тут может быть и по другому. Пусть сначала сделать всем корневого родителя. Потом уже будем посмотреть!

(20) foxpro умеет sql, что намного упрощает)

(23) Fox - это моя любимая среда до встречи с 1С
Вообщем нет пока видимости причины:
Вердикт фокса:
USE e:\work\1c\7.7\postavka_base\sc135.dbf SHARED
BROWSE

SELECT * FROM sc135 WHERE id=parenid // печатает  весь справочник
SELECT COUNT(*) FROM sc135 // печатает 14673

SELECT * FROM sc135 WHERE id=parentid  // ничего нет
SELECT COUNT(*) FROM sc135 WHERE id=parentid // печатает 0

(24) Сори за описку : SELECT * FROM sc135 WHERE id=parenid // печатает  весь справочник
Там комент предполагался для browse, то есть так

browse // печатает  весь справочник

(0) а оно это вам надо, "найти в дереве"? Столько лет работаю, никогда даже не слышал о такой кнопке. Есть же нормальные средства работы там в семерке, что вы так прикипели к этой придурочной функции? К тому же и не работающей.

(26) Конечно, не самое важное, но есть осадок и нет уверенности, что всё в жизни заМЕЧТАтельно. :)))))))

Проверка на заЦИКЛивание элементов (групп) справочников конфигурации
http://infostart.ru/public/85714/

(28) Спасибо, но ФОКС с единственным запросом ( SELECT * FROM sc135 spr WHERE spr.id=spr.parentid  // ПУСТАЯ выборка ) опроверг подозрение-гипотезу о таком случае.

(0)
Выгрузка и загрузка в пустую - исправляет баги в спр

Но зацикливание более вероятно. Сталкивался.
Оно не обязано быть вида сам на себя
Может через несколько промежуточных

SELECT DISTINCT sp2.parentid FROM
(SELECT DISTINCT sp1.parentid FROM
(SELECT DISTINCT spr0.parentid FROM
(SELECT DISTINCT spr.parentid FROM sc135 spr
)spr0
)spr1
)spr2

ну и так допустимыхуровней+1 - если не пусто - зацикл

очепятка sp spr

(30) Выгружал и загружал 3(!) раза, причём и на другой комп и плюс с другой ОС. НЕ помогло.
Вопрос скорей всего кроется в особенности обработки платформой 1С в данном случае конкретной этой базы, где у неё случается "Потеря сознания". В других базах на этом же компе, с этой же 1с-кой "найти в дереве" работает на УРА хоть 100 раз осуществляй эту функцию! А здесь адзын раз и накрывается медным тазом.

(31) Спасибо попробую!

(33)
не - неправильный запрос, уже подзабыл
Ну идея понятна

(34) Я понял. Самый вложенный Запрос выводит список групп-родителей, а все остальные по иерархии запросы делают тоже самое.

что вроде этого для 2-х уровнего

SELECT DISTINCT  SC3.parentid FROM
(SELECT DISTINCT SC2.parentid FROM
(SELECT DISTINCT SC1.parentid FROM
(SELECT DISTINCT spr.parentid FROM sc135 spr
)spr0 Left JOIN sc135 SC1 ON spr0.parentid =SC1.id
)spr1 Left JOIN sc135 SC2 ON spr1.parentid =SC2.id
)spr2 Left JOIN sc135 SC3 ON spr1.parentid =SC3.id

(36) Спасибо огромное за помощь, но к сожаленью надо отлучиться. Реализация идеи ясна, что для каждого уровня у элементов есть только ОДИН непосредственный родитель. Ваш пример обязательно опробую и о результатах отпишусь!

(0) ОТВЕТ найден и был ещё озвучен в (1) посте и далее.
Немного радостно, но в тоже время и грустно и прискорбно за зря потраченное время и силы форумчан, за что конечно огромная им БЛАГОДАРНОСТЬ.
Но тут как говорится: "Неверующая Фома не поверит пока не проверит".
НАшлась папка на третьем уровне с ID=0(!). Непонятно откуда ей 1С присвоило такое странное значение. Даже несколько раз пытался создавать пустую базу, но там ID всегда начинается с 1.
Но как известно в корневом катологе справочника все элементы и группы имеют ParentID=0;
Вот оно и зацикливалось! Ёпть.  
Ксати после XP даже на Windows 7 умудрился зарядить, где она хоть как-то нарисовала ошибку при падении:

Сигнатура проблемы:
 Имя события проблемы:    APPCRASH
 Имя приложения:    1cv7s.exe
 Версия приложения:    7.70.0.27
 Отметка времени приложения:    4573fcd8
 Имя модуля с ошибкой:    MFC42.DLL
 Версия модуля с ошибкой:    6.6.8063.0
 Отметка времени модуля с ошибкой:    4a5bda30
 Код исключения:    c00000fd
 Смещение исключения:    00013779
 Версия ОС:    6.1.7601.2.1.0.256.1
 Код языка:    1049
 Дополнительные сведения 1:    585e
 Дополнительные сведения 2:    585ef2312291978d8ea132aceae065eb
 Дополнительные сведения 3:    40ca
 Дополнительные сведения 4:    40ca51e68e1af2bc8c975a12a0ef9834

Ознакомьтесь с заявлением о конфиденциальности в Интернете:
 http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0419

Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
 C:\Windows\system32\ru-RU\erofflps.txt

Кстати пардон, что торопился ответить и забыл написать как же собственно ответ получил:
Если запрос вернул хоть одну зацикленную парочку(2 записи), то дело плохо
SELECT spr1.id, spr1.parentid FROM sc135 as spr1 JOIN (select spr2.parentid, spr2.id FROM sc135 as spr2) spr2 ON ((spr1.id=spr2.parentid) AND (spr1.parentid = spr2.id))

(5)
"Когда будет (8.Финальная версия) так и сразу будем переходить"
бугага