Отчего жуткое торможение ADO-запросов и ошибка?

← →
Aleksandr © (2002-06-18 12:30) [0]

Столкнулся с непонятной проблемой. Работают через ADOConnection 147 таблиц (разных) на MS SQL. Когда пользовался компонентами TDataBase и TTable - все работало прекрасно. Когда TTable заменил на TQuery (TTable имеет свойство глюкаво работать с MSSQL), периодически начали всплывать ошибки типа "Результ занят другим hstmt". Заменил все на АДО-компоненты - и началось полное безобразие. Запросы тормозят по пять минут, а при выполнении: "Данный запрос занят ожиданием результатов другого запроса". Что за фигня?

← →
Delirium © (2002-06-18 12:39) [1]

select * from MyTable with(nolock) - даёт быстрый, но неполный результ в обход блокировок других запросов

← →
Mike_Goblin © (2002-06-18 12:46) [2]

Ошибка в строке 17
1. Никогда на пользуйтесь View и хранимыми процедурами
2. Забудьте про слово where в тексте запроса - надо обязательно выкачать все данные из таблицы на клиента
3. Не надо бояться выборок большого объема - только ламеры считают что 500 тыс записей в результате запроса это много, пусть этот подлый пользователь сидит и просматривает такую выборку, а если он будет недоволен надо ему дать 1 млн записей, чтобы он сразу понял с кем имеет дело....

← →
fool © (2002-06-18 12:54) [3]

>Mike_Goblin Согласен полностью
это надо додуматься 147 таблиц и использовать TTable :0(

← →
Aleksandr © (2002-06-18 13:00) [4]

Ну, в данном случае я и не пользуюсь видами и хранимыми процедурами. Несколько потоков в программе подхватывают кодированные файлы данных, создают TADOQuery с серверных таблицы, в которые эти данные должны поступать, а затем выполняют запросы. Как я заметил, базовое торможение идет при выполнении TADOQuery.Open (с запросом SELECT * FROM Table) и TADOQuery.ExecSQL. with(nolock), как я понимаю, может ускорить выборку, когда требуется просто открыть таблицу, но вот допустим ли он, когда происходит UPDATE или INSERT?

← →
Delirium © (2002-06-18 13:10) [5]

Стоит разобраться, нужно-ли тебе 150 редактируемых запросов ?
Наверное надо как-то разгрузить задачу или по крайней мере, разбить её по сессиям (разным ADOConnection).

← →
TSV © (2002-06-18 13:14) [6]

> Mike_Goblin © (18.06.02 12:46)

1. Никогда на пользуйтесь View и хранимыми процедурами
Это еще почему???

2. Забудьте про слово where в тексте запроса - надо обязательно выкачать все данные из таблицы на клиента
Зачем? Юзер не в состоянии "переварить" больше 1000-1500 записей...

3. Не надо бояться выборок большого объема - только ламеры считают что 500 тыс записей в результате запроса это много, пусть этот подлый пользователь сидит и просматривает такую выборку, а если он будет недоволен надо ему дать 1 млн записей, чтобы он сразу понял с кем имеет дело....
Ага. Можно перефразировать так: "Давайте дадим возможность юзерам побыстрее исчерпать ресурсы сервера и сети!!!"

← →
Aleksandr © (2002-06-18 13:16) [7]

2 fool
Мы ведь не критикой занимаемся. TTable не я использовал в свое время. Потому и пытаюсь переделать.

2 Delirium
Мне - нет. Но когда начальник уверен, что он лучший программист и менять принцип не надо, потому что раньше и так все работало, это очень меняет дело. Если я выделю для каждой таблицы свой Connection (или каждой индивидуально зарисую Connection String) - что лучше и быстрее будет? NOLOCK, кстати, абсолютно не изменил ситуации. :(

← →
fool © (2002-06-18 13:18) [8]

>TSV © (18.06.02 13:14)
Военно-морского юмора не понимаешь...

← →
Mike_Goblin © (2002-06-18 13:19) [9]

Уважаемые товарищи и господа, видимо я забыл поставить под советами значок :))))
Прошу воспринимать данный совет с точностью до наоборот
НЕ НАДО ДЕЛАТЬ БОЛЬШИЕ ВЫБОРКИ - ОНИ ПРИЧИНА ТОРМОЗОВ

"NOLOCK, кстати, абсолютно не изменил ситуации" - значит проблема не с блокировками. Что тут посоветовать - экспериментируй, попробуй изменить CursorLocation на clUseServer - это снимет проблему прокачки большого объёма данных...

Попробую :(... Хотя слышал, что она не работает на данный момент. Чего-то меня АДО вообще расстраивать начало... В одной программе, например, АДО периодически вешает запросом весь компьютер (после третьего-четвертого вызова). Тут - тормоза. Стандартные компоненты быстрее работают, нафиг.

Тем не мнее - стандартная прога из комплекта MSSQL - Query Analyser работает именно посредством ADO и безглючно :)
Вывод - если в Analyser-е что-то работает, а у тя не работает или работает, но не так - ищи ошибку у себя :)

>>"Данный запрос занят ожиданием результатов другого запроса". Что за фигня?

Похоже у тебя конфликт блокировок.

или

Попробую :(... Хотя слышал, что она не работает на данный момент. Чего-то меня АДО вообще расстраивать начало... В одной программе, например, АДО периодически вешает запросом весь компьютер (после третьего-четвертого вызова). Тут - тормоза. Стандартные компоненты быстрее работают, нафиг.

БДя раньше была?

BDE не качает все данные сразу - только докуда та добрался по BDEшному курсору.
ADODB тоже так делает - надо только ручками.
Не хочется ручками - читайте ответ гоблина.

Отчего жуткое торможение ADO-запросов и ошибка? Найти похожие ветки