Сильные тормоза в 1С7.7 при поиске по справочнику #381808

Справочник содержит около 30тыс. элементов. Пользователи работают в терминале на сервере. Сервер: Тип ЦП      2x Intel Xeon, 3200 MHz Системная плата    Asus NCL-DE/SCSI  (1 PCI, 1 PCI-E x8, 1 PCI-E x16, 3 PCI-X, 8 DDR2 DIMM, 1 SO-DIMM, Video, Dual Gigabit LAN, SCSI) Чипсет системной платы      Intel Lindenhurst E7520 Системная память            8192 Мб Так вот когда кто-то из пользователей начинает выполнять "быстрый" поиск по справочнику (то есть набирают прямо в справочнике, а 1С по первым нажатым буквам ищет нужный элемент справочника), программа начинает тормозить, причем очень заметно. В чем проблема? Это так этот поиск работает? Или я зря на поиск грешу?

может формула какая нить? особенно для вычисления остатков?

расчётные колонки езззь?:

Людей-то сколько в базе?

сталю, на то, что у них есть колонка с остатками или ценой

+1 Адназначна!

Автор видимо ушел в себя

+ психанул, долго с ответами тянули.

мужики , спасибо , заставили задуматься! есть! только не формула, а внизу формы списка по текущему контрагенту выполняется поиск последнего документа определенного вида (нетиповой документ) с помощью "ВыбратьДокументы" конечно я еще не проверял но скорее всего из-за этого

Как запущено всё...

а в выбраных документах еще наверно по строкам бегает, и в конце проверка, если не проведен, то возврат. ))))))))))

Это не вормула разве? :))) Имхо убери и посмотри

Убей автора этого поиска... А вообще, такие вопросы принято задавать товарищу Профайлеру...

Пользователей ну очень интересует дата последнего такого документа, и они ее хотят видеть прям на форме. Когда думали как это сделать была мысль сделать эту дату реквизитом справлчника, и чтобы документ свою дату записывал в этот реквизит. Но это давно было, почему так не сделали уже не помню...

похоже обшибся... не вызывается эта процедура поиска, так что дело не в этом

Запускаешь отладчик, включаешь замер времени и начинаешь искать. Потом останавливаешь и смотришь, на что уходит время.

а как это? "включаешь замер времени"? и где его включать если тормозит не код, а просто поиск? получается что при поиске никакого кода не срабатывает

ау! Если никакой код не срабатывпает, сам поиск по справочнику может так тормозить систему???

Запусти отладчик и там Отладка - замер произовдительности. Если нет вычисляемых колонок, то не должен.

а почему есть отрицательные значения?

Ни разу не видел

ты чо-то сочиняешь, скриншот покажи с отрицательными трэйсами

Круто! Это "предварительные вычисления" - они добавляют скорость :-)

ржите-ржите, сегодня уже неохота, завтра выложу скриншот

Завтра ты надешься, что кто-то увидит? О_о

выкладывай паржом еще

Ржите

Справочник обычно тормозит при включенном показе остатков номенклатуры. Можно исключить колонку остатка (в последних релизах ТиС остаток отображается при перемещении курсора только по текущей позиции, этого может быть достаточно). Другой способ ускорить вывод остатков (если заранее известно число складов) показан тут: Суть в том что после проведения генерируется событие (можно сделать и через обработку ожидания) и остатки заносятся в реквизит Остаток справочника номенклатуры. Если несколько складов, то для каждого надо завести свой реквизит. Если карточка товара кем-то открыта, то остаток обновляется по ее закрытию.

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

Остатки, остатки... тоже есть одна чумовая база без всяких остатков... Код наберёшь, потом через минуту на него курсор перескочит...

+ для скорости поиска сделана обработка по кнопочке и позиционирование на найденном...

Если немного подумать, то делается это без всяких "асинхронных событий".

А что говорит товарищ Профайлер?

единственный нормальный выход (а не способ сношать сеюе мозг) работа со справочником программно...

а собственно база на SQL или DBF ?

Через обработку ожидания тоже получится, с небольшой правда задержкой. Но зато без внешней компоненты, если это критично.

(29, 30) у меня получается такая же ситуация: 1) справочник без формул и вычислений (была сначала догадка на вызов процедуры из текста на форме, но потом оказалось что в этой процедуре сразу срабатывает Возврат) 2) сделаана такая же кнопка, но бухи ей пользоваться не хотят, говорят не удобно, привыкли поиском по справлчнику. То есть причин для тороможения вроде нету, но все равно поиск жутко тормозит: набираешь букву - ждешь секунду а то и больше пока он спозиционируется. Причем начинают торомозитьи другие пользоватлели База SQL Так до конца и не понятно как с этим бороться. Замерять вроде и нечего

А что все-таки говорит товарищ Профайлер? (точнее, товарищи Профайлеры, раз база сиквельная?) поиск по какому реквизиту идет так долго?

Базу переиндексируй, выгрузи-загрузи

аналогичная проблема

ну как неохота сегодня этим заниматься :) давайте после праздников обязательно напишу про профайлер каждую ночь SQL переиндексирует рад что не у меня одного такая проблема, а то уж я что только не думал

мы и базу откатывали, и скуль переустанавливали, перезагружали все что можно и тд и тп

рассказываю. у нас справочник 70000 товаров. быстрый поиск по артикулу используется при наборке накладных. когда база была в ДБФ, жалоб не было. перевели базу в SQL - началось такое же. нажимаешь буковку, ждешь секунду, переходит 1С-ка на строку. нажимаешь опять буковку - опять секунда. и т.д. учитывая что артикул до 10-12 символов - полная торба запустил профайлер и получил культурный шок. 1С-ка, понятное дело, на каждое нажатие выполняет SELECT запрос к справочнику, но этот запрос НЕ ПОПАДАЕТ в индексы... и такой запрос выполнял порядка 30-70 тысяч считываний (параметр Reads в трейсе) кроме этого в запросе в условии присутствует функция subst, которая даже при попадании в индекс обяжет SQL обойти полтаблицы в общем я написал для подбора товара свою обработку с таблицей значений и перехватом клавиш Formex-ом. и свой запрос к справочнику в 1С++, который теперь выполняет в среднем 60-200 чтений, вместо десятков тысяч. стало быстро. очень.

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

тогда патчить 1С на предмет запроса который он выдает (-: вобщем, у нас тормоз был в одном только подборе в одном справочнике. решение точечное там чтобы все списки, все справочники поправить - это не выйдет

сделай еще одну форму,  и вынеси туда только наименование и код и попробуй быстрый поиск - если он работает нормально начинай наполнять форму необходимыми атрибутами. наверняка поймаешь такой момент, когда форма начнет тормозить

А отборов не стоит? ;) Может какой отбор хитрый стоит ...

Ничего удивительного. Подружитесь с товарищем профайлером, и вам воздастся... Зачем, собственно, патчить? Хотя ЗаменаЗапросов от ромикса может помочь - но лучше решать проблему нормально.

по нормальному с 1С-кой тут не получается договорится. или Вы что имеете ввиду под нормальным решением проблемы?