Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Тормоза ADO SQL [D5, D6, MSSQL]


Mike_ ©   (2003-02-06 17:31:00) 

Доброго времени суток. Вводная: есть БД Access, есть таблица Exel. При обработке и переносе данных из Exel (через OLE) в .MDB (ADO, SQL, практически только Insert) наблюдается постепенное замедление скорости вставки данных. При после 7000-8000 вставленных записей скорость (по сравнению со скоростью вставки первых записей) падает в 10-15 раз, потом еще сильнее. База индексирована.

Что делать? Надо ускорить, а как? Не оставьте без ответа плиз.


Mike_   (2003-02-10 08:42:00) [1]

Во! Замена на AccessAdoQuery помогла! Скорость достигла (на машине Cel466, RAM 128M) 1200 записей в минуту, стабильна вне зависимости от размера базы. Спасибо всем!


Nikolai_S   (2003-02-07 11:49:00) [2]

Замедление вставки может замедляться из-за индексов. Ведь как известно индексы замедляют процессы вставки. Но чтобы так сильно замедлять... А каким образом вставка происходит? Через ADO компоненты (Append/Post) или напрямую SQL-запросами (Insert Into)?
Вообще желательно сначала открыть черз TADOTable/TADOQuery и лист Excel и Таблицу Access:
1. ExcelAdoQuery.SQL.Text := "SELECT * FROM [Лист1$]";
2. AccessAdoQuery.SQL.Text := "SELECT * FROM [ACCESS_TABLE]";
Естественно ADO компоненты должны быть подсоедены к соответствующим TADOConnection"ам. Тогда должно быстрее работать, чем через OLE...


sniknik   (2003-02-07 11:49:00) [3]

> разбор и анализ строкового поля
так примерно?

INSERT INTO TrTest (CASH,FLAG,SUSER,SCOUNT) VALUES
(iif( "YES"= "да","0",0), iif(Instr(1, "YES", "I", 0)=0, 10,100), "dbo", 0)

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

> закрываем, запускаем
не закрываем, запускаем а уничтожаем/создаем. (переоткрытие мне тоже не помагало)


Mike_   (2003-02-07 11:09:00) [4]

Нет, утечек памяти нет, проверено. Ресурсы тоже не кушает. Даже так: обрабатывае 5000 записей, время растет и приближается к минуте на запись, закрываем, запускаем снова с того места где остановились и дальше - время вставки тоже около минуты, и продолжает расти.
Одним запросом? В каждой записи необходимо произвести разбор и анализ строкового поля, так что приходится читать по одному, и соответственно вставлять. При этом после анализа принимается решение, вставлять строку в поле допустим, Field_1 или в Field_2. То есть, таблица ёкселя должна быть предварительно "причесана".
------------
Для визуализации используется DBGrid, попробую отключить, и Label, в который выводится порядковый номер записи(ИМХО отключать не стоит...).


VAleksey   (2003-02-07 06:31:00) [5]

А еще вот что ... Ты данные визуализируешь при вставке ? Если да, то какие компоненты используешь ?
Попробуй вообще все визуальные контролы отключить при выполнении этой операции.


sniknik   (2003-02-06 23:54:00) [6]

тогда проверь следующее.

(надеюсь у тебя 2000-й,NT на крайняк XP но не 98-95 не подходят для программирования/тестов по моему)

открой диспечер задачь, вкладка быстродействие, и во время запросов проследи за количеством открытых дескрипторов и доступной память. (был у меня такой глюк на одной из версий МДАКа или Jet-а) ресурсы сжирались с каждой командой (причем примерно равные независимо от "тяжести" комманды) и возвращались только с "убийством формы" или по завершении программы например.
тогда я вышел из положения, динамически создавая ADO компоненты, и пересоздавал ~ после 3000 вызовов. Free компоненте освобождало память.

если у тебя так же можеш попробовать.

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

тоже можно попробовать проапдейтить.

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

надеюсь помог.
почему нельзя обработать одним запросом? у jet-а довольно большая функциональность. многое можно, только за счет функциональности может обгонять BDE при работе с dbf к примеру (в большинстве это не так а совсем наоборот).


Mike_   (2003-02-06 23:13:00) [7]

Нет, надо каждую запись обработать.
Так что читаем по одной ( пробовал уж и Эксель в txt конвертить и читать стримом, не играет роли, никакого увеличения скорости) и по одной же вставляем.
Вот так. :(


sniknik   (2003-02-06 19:25:00) [8]

а сколько у вас идет запрос?
для примера попробовал из Exel в Access

insert into ExelMax SELECT * FROM [Sheet2$] IN "" [Excel 5.0; DATABASE=D:\Кассовые события.xls;]

получилось 1,75сек. 65535 записей (нормально вполне), и больше не будет (65535 максимально для Exel) так стоит ли беспокоится?

или у вас не так? тогда как? подробно.


ermserg   (2003-02-06 18:26:00) [9]

Ispolzovat DTS


Наверх

Титульная страница Поиск, карта сайта Написать письмо