Lookupы при большом количестве записей выводимой таблицы

[Pavlo AKA Panok]

При работе с Lookup - выподающимим списками по таблицам, содержащим огромное количество записей (например InventTable при хранении в ней 140000 записей) возникает проблема. Предположим, что все артикулы представлены числами, лежащими в диапазоне от 000000 до 999999. Нажимаем на кнопочку Lookup и вызываем выпадающий список артикулов - это все работает быстро... Но теперь ничего не трогая (т.е. активна та колонка Lookup-формы, которая содержит артикулы) начинаем вводить начало некоего требуемого артикула... Здесь то и начинаются проблемы - при вводе номера начинающегося на 0 или 1 все еще ничего - время позиционирования курсора на нужной строчке Lookup-формы сносное. Но если мы сразу же наберем ченить с 5 до 9 то система занимает все ресурсы ЭВМ на неопределенный срок... у нас такое позиционирование при занимании громадных ресурсов (памяти и процессорного времени) неслабой ЭВМ занимает 5-10 минут

Как с этим бороться?

[mazzy]

попробуй ПЕРЕД тем, как нажать на кнопку lookup, ввести фильтр.

например, 5000*. При нажатии на * лукап откроется сам .

Таким образом количество записей в лукапе резко сократится.

[Pavlo AKA Panok]

Спасибо за ответ но только...

Я то нажму, а кто бы юзеру объяснил, что это выход... Так конечно быстрее работает и мне никакой разницы нет, но только ребята привыкли 1С-ом курсоры по спискам гонять, им в лом всякие звезды нажимать...

А других вариантов решения прогрессивная часть человечества не придумала?

[mazzy]

Кроме тебя юзеру объяснить больше никто не сможет.

Курсоры по спискам... А ты никогда не задумывался почему С.Нуралиев так сильно против вычисляемых динамических фильтров?

Звезды нажимать будут, если ты объяснишь. И преимущества будут осознаны и востребованы пользователями.

Прогрессивная часть человечества придумала многое. Но будешь ли ты этим пользоваться... Что делает лукап? он просто и тупо выдает запрос SQL-серверу. Сервер готовит курсор и... просто возвращает потихоньку записи из курсора. Все просто. Все штатными вредствами (и Аксапты, и Сервера) НО сервер тратит прорву времени на подготовку курсора.

Выход? Работать с записями вручную. Готовить курсор другого вида (править query вручную). В крайнем случае, работать с сервером в обход Аксапты. Тебе это надо? Может энергию направить по более конструктивному пути?

[Алексей Контев]

Можно вопрос по 1с?
А как в SQL 1C реализован механизм быстрого поиска? (в смысле не SQL запрос, а нажатие клавиш)
Как я понял, эта возможность появилась из любви к 1с.
На маленьких справочниках это удобно, а при больших ...
У нас раньше стояла Dos (Fox) Бухгалтерия, где поиск осуществлялся последовательным вводом наименования. После запуска Аксапты многие (все) очень плевались, что надо жать Ctl-F и т.п., но через 2 недели в старой программе хотели иметь возможность сложного поиска. Так что не стоит идти на поводу у неграмотного пользователя. Они просто не понимают своего счастья.
А про быстрый поиск в 1C -SQL я серьезно, есть он там или нет.

[Pavlo AKA Panok]

Нет, в принципе переучиться можно - ну нажимал ты F3 а теперь жмешь Ctrl-F...

Но в 1с есть фича от которой все писаються кипятком - значит стоишь на артикулах, и начинаешь ввод - предположим нужен тебе артикул 6343535. Набрали 634 а потом ошиблись и вместо 3 набрали 6. Если в системе нет ни одного артикула на 6346... то раздается звук из динамиков... Beep! Вот сидит юзер на экран не смотрит - колотит артикул - бип - ошибка посмотрел и исправил...

А со скоростью теже проблемы...

В Аксане этого бипа нет и врядли ктото скажет "через 2 недели" - во, супер, без бипа кайф!!! Он помогает, хотя конечно не всегода ошибочного артикула нет в картотеке. Я не спорю что Аксана предоставляет широчаайшие возможности, но существует ряд таких вот "бипов", которые засядут вечной занозой в молодое неокрепшее тело Аксаны у нас на фирме и будут вечным набатом...

Вот конретный пример - на нем и объясните мне как все зависит от меня и какие доводы могут быть за отсутсвие этого бипа)))

А со звездой идея продвижима в жизнь, это точно!!!!!!

[mazzy]

Цитата:

А как в SQL 1C реализован механизм быстрого поиска?

Очень просто
Вся таблица скачивается на клиента. После чего нормальным DBF-способом делается поиск.

Нажатие клавиш реализовно точно так же, как и нажатие первых символов в лукапе или в AOT'е.


Насчет бипа...
Действительно бипа нет. Неаккуратненько

[Pavlo AKA Panok]

Я подозреваю что чегото не допонимаю в работе Лукапа...

Когда мы жмем на кнопку Лукап SQL сервер формирует курсор и возвращает его нам весь? Или при перемещении по списку или при позиционировании при нажатии на какой либо символ идет дополнительный обмен данными между клиентом и сервером?

[mazzy]

Да. Сервер формирует курсор и возвращает только его часть. При перемещении по списку идет дополнительный обмен данными.

[Kura]

Можно и перед нажатием на лукап ввести 5000*, как уже предлагалось.
А можно и в отрытом лукапе спозиционировавшись на поле "Код номенклатуры", нажать клавиши CTRL+F(или бинокль) и там ввести теже 5000* - результат потрясающий. Все очень быстро и все довольны. Проверено на очень большом объеме данных. И пользователь к этому быстро привыкает.
Успехов.