Форум: "Базы";
Текущий архив: 2002.07.15;
Скачать: [xml.tar.bz2];
ВнизОтчего жуткое торможение 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]Уважаемые товарищи и господа, видимо я забыл поставить под советами значок :))))
Прошу воспринимать данный совет с точностью до наоборот
НЕ НАДО ДЕЛАТЬ БОЛЬШИЕ ВЫБОРКИ - ОНИ ПРИЧИНА ТОРМОЗОВ
← →
Delirium (2002-06-18 13:33) [10]"NOLOCK, кстати, абсолютно не изменил ситуации" - значит проблема не с блокировками. Что тут посоветовать - экспериментируй, попробуй изменить CursorLocation на clUseServer - это снимет проблему прокачки большого объёма данных...
← →
Aleksandr (2002-06-18 14:21) [11]Попробую :(... Хотя слышал, что она не работает на данный момент. Чего-то меня АДО вообще расстраивать начало... В одной программе, например, АДО периодически вешает запросом весь компьютер (после третьего-четвертого вызова). Тут - тормоза. Стандартные компоненты быстрее работают, нафиг.
← →
Delirium (2002-06-18 14:27) [12]Тем не мнее - стандартная прога из комплекта MSSQL - Query Analyser работает именно посредством ADO и безглючно :)
Вывод - если в Analyser-е что-то работает, а у тя не работает или работает, но не так - ищи ошибку у себя :)
← →
Fay (2002-06-19 04:32) [13]>>"Данный запрос занят ожиданием результатов другого запроса". Что за фигня?
Похоже у тебя конфликт блокировок.
или
Попробую :(... Хотя слышал, что она не работает на данный момент. Чего-то меня АДО вообще расстраивать начало... В одной программе, например, АДО периодически вешает запросом весь компьютер (после третьего-четвертого вызова). Тут - тормоза. Стандартные компоненты быстрее работают, нафиг.
БДя раньше была?
BDE не качает все данные сразу - только докуда та добрался по BDEшному курсору.
ADODB тоже так делает - надо только ручками.
Не хочется ручками - читайте ответ гоблина.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.07.15;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.01 c