Отражение состояния SP на клиенте (ProgressBar)

Если процедура выполняется на сервере больше 5 секунд у пользователя (да и не только) возникает некий напряг, хорошо еще если 5 - 10 секунд часто расчет идет десятки минут. Выводить окно "Подожните производится расчет" как-то недружелюбно.
Возникает потребность вывести на экран форму с Progress Bar и всякими поучительными сообщениями о текущем состоянии расчета.

Так просто из SP эту информацию не получить.

Был ли у кого-нибудь опыт решения подобных проблем?

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

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

привет.
меня тоже зовут Бронников Андрей.
зайди на www.bronnikov.ru :)
а по поводу вопроса можно выводить курсор мыши - песочные часики
и оптимизировать свой запрос.
[!]
когда график ядра в таскманагере в винде идет вместе с графиком CPU -> запрос написан правильно и выполняется шустро. это хорошо заметно только на 1-процессорных системах.
в принципе если это просто выборка, используй запрос в упор (например на delphi это компонент query) вместо вызова СП.
удачи.

когда график ядра в таскманагере в винде идет вместе с графиком CPU -> запрос написан правильно

Это почему? Обоснование какое?

П4 с 256ram. sql server 2000.d6+ado.
регулярно проявляется такая зависимость.
доказывается скоростью выборки.

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

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

это может и иногда будет проявляться.
обосновывать или не обосновывать - у меня так.
может кто-нибудь другой о иной зацепке расскажет?

как отличить по-тормозному написанный запрос с привлечение кучи СП,
выборок во временные таблицы итд (или просто select с where на гигатоннах данных). что _быстрее ANY или IN для использования с подзапросами для проверки значения в диапазонах?

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

Кстати может обрашали внимание QA при выполнение запроса все принты отображает на экране в Output window.
Как я только не пытался почитать эту информацию с помошью ODBC, так и не получилось. Делал следующее: открывал асинхронное соединение, запускал запрос и в цикле читал-читал, а он SQL_NO_DATA и все данные только в принты только в конце.

В общем так и не понял, как QA Работает.

А с помощью trace кто-нибудь пробовал отлавливать сообщения из SP на клиенте?

как отличить по-тормозному написанный запрос с привлечение кучи СП,
выборок во временные таблицы итд (или просто select с where на гигатоннах данных). что _быстрее ANY или IN для использования с подзапросами для проверки значения в диапазонах?

Если тебя напрягает скорость выполнения запроса, значит он тормозит. Практически в 100% случаев первоначально написанный запрос можно оптимизировать.

Если известен запрос, который медленно выполняется, то можно использовать index tuning в QA, он потужится и выдаст рекомендации по индексам, очень часто помогает.

Можно написать два или несколько вариантов запросов и сравнить их план выполнения (для обеих сразу) сразу станет понятнее какой лучше.

Иногда прихордится радикально менять алгоритм выборки (сравнивать в QA)

Если не понятно какой из запросов в SP Выполняется медленнее надо использовать profiler, там есть время начала исполнения и время конца исполнения, а дальше опять гонять в QA.

Приемов, много

Похоже это то, что надо. А то ушли все в обсуждение оптимизации :-) Оптимизация, конечно тоже хорошо, но градусники никто не отменял :-)