Отображение прогресса при UPDATE базы

← →
leonidus (2008-05-30 16:33) [0]

Юзаю Access-базу через ADO. Делаю UPDATE большой базы, и на некоторых слабеньких машинах он длится по 10-15 секунд в течении которого программа подвисает и юзер нервничает не понимая что происходит. Подскажите пожалуйста как в ходе обновления показывать прогресс работы или хотябы периодически иметь возможность вызвать application.ProcessMessages?

← →
Stas © (2008-05-30 16:39) [1]

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

← →
leonidus (2008-05-30 16:40) [2]

Stas, встречный вопрос, а как выполнить запрос асинхронно?

← →
Stas © (2008-05-30 16:43) [3]

AdoDataSet.ExecuteOptions:=[eoAsyncExecute]

← →
sniknik © (2008-05-30 19:53) [4]

> и на некоторых слабеньких машинах он длится по 10-15 секунд
машина - 286й пень?
не могу другую представить, чтобы один UPDATE на ограниченной по размеру базе делался аж целых 15 секунд...

← →
leonidus (2008-05-30 22:13) [5]

UPDATE не один, у меня их 7, база - 1000 записей:

ADOQuery1.Close;
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.status=:Str1"+ " WHERE tab.header<>:Str2");
ADOQuery1.Parameters.ParamByName("Str1").Value:="";
ADOQuery1.Parameters.ParamByName("Str2").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.active_word=:Str3"+ " WHERE tab.header<>:Str4");
flag:=false;
ADOQuery1.Parameters.ParamByName("Str3").Value:=flag;
ADOQuery1.Parameters.ParamByName("Str4").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.associaciya_true=:Str1"+ " WHERE tab.header<>:Str2");
ADOQuery1.Parameters.ParamByName("Str1").Value:=0;
ADOQuery1.Parameters.ParamByName("Str2").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.vibor_perevoda_true=:Str1"+ " WHERE tab.header<>:Str2");
ADOQuery1.Parameters.ParamByName("Str1").Value:=0;
ADOQuery1.Parameters.ParamByName("Str2").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.mozaika_true=:Str1"+ " WHERE tab.header<>:Str2");
ADOQuery1.Parameters.ParamByName("Str1").Value:=0;
ADOQuery1.Parameters.ParamByName("Str2").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.vspomnit_true=:Str1"+ " WHERE tab.header<>:Str2");
ADOQuery1.Parameters.ParamByName("Str1").Value:=0;
ADOQuery1.Parameters.ParamByName("Str2").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add("UPDATE tab SET tab.perevod_true=:Str1"+ " WHERE tab.header<>:Str2");
ADOQuery1.Parameters.ParamByName("Str1").Value:=0;
ADOQuery1.Parameters.ParamByName("Str2").Value:="";
ADOQuery1.ExecSQL;
ADOQuery1.Close;

может можно как-то оптимизировать запросы?

← →
leonidus (2008-05-30 22:52) [6]

хотя потом делаю еще и выборку:

ADODataSet1.Close;
ADODataSet1.CommandText:="SELECT * FROM tab ORDER BY tab.header";
ADODataSet1.Open;

может она больше всего времени занимает?

← →
Правильный_Вася (2008-05-30 22:55) [7]

> ADOQuery1.ExecSQL; ADOQuery1.Close;

в чем сакральный смысл выделенного?

> может она больше всего времени занимает?

вероятно, если каждый из апдейтов изменяет только одну запись (что вряд ли, судя по условию <>

← →
sniknik © (2008-05-30 23:33) [8]

> может можно как-то оптимизировать запросы?
конечно... ведь это на самом деле один запрос разбитый зачемто на 7.

и еще немного времени можно выиграть используя ADOCommand вместо ADOQuery, совсем чуть чуть, но... Close в нем нет, и это хорошо, видя как ты его используеш.

> может она больше всего времени занимает?
проверь. выполни без него...

← →
Германн © (2008-05-31 02:01) [9]

> > может она больше всего времени занимает?
> проверь. выполни без него...
>

Может. Но я всё равно сомневаюсь, что
> длится по 10-15 секунд

именно из-за чего-то приведённого в [5].

← →
Германн © (2008-05-31 02:04) [10]

> sniknik © (30.05.08 19:53) [4]
>
> > и на некоторых слабеньких машинах он длится по 10-15 секунд
> машина - 286й пень?
> не могу другую представить, чтобы один UPDATE на ограниченной
> по размеру базе делался аж целых 15 секунд...
>

Могу себе представить, если объём оперативки не соответствует требованиям ОС. Плюс загружено много процессов.

← →
sniknik © (2008-05-31 10:41) [11]

> Может. Но я всё равно сомневаюсь, что
>> длится по 10-15 секунд
> именно из-за чего-то приведённого в [5].
ну да, даже 7 запросов на 1000 записей не тянут на 15 сек... но это не повод чтобы писать 7 вместо одного.
и да скорее всего чтото там еще есть, только раз оно не показано значит необсуждаемо. потом, если всплывет, можно будет еще про индексы поговорить, про нормализацию (условие у него смотрю по строке, т.е. там куча повторяющихся значений строк, нормализация прямотаки напрашивается). и о нужности этих запросов вообще... (значения присваиваются странные, 0, ""... это начальная инициализация записи?... про дефаултные значения для полей автор похоже не знает... но опять таки что делается, и зачем не сказано, есть только вопрос о оптимизации запросов)

> Могу себе представить, если объём оперативки не соответствует требованиям ОС. Плюс загружено много процессов.
ага, а если к машине привязать собаку, и ехать соответственно так чтобы она успевала, или мерить скорость на участках с пробками... то можно говорить что машины ужасно медленные, практически на лошади обогнать можно... и нафига они тогда нужны?

← →
leonidus (2008-05-31 15:29) [12]

>Stas, если делаю так:

AdoDataSet1.ExecuteOptions:=[eoAsyncExecute];
ADODataSet1.Close;
ADODataSet1.CommandText:="SELECT * FROM tab ORDER BY tab.header";
ADODataSet1.Open;

то при выполнении этого блока программа подвисает

← →
Anatoly Podgoretsky © (2008-05-31 18:10) [13]

> leonidus (31.05.2008 15:29:12) [12]

Разве это команда, что бы ее
исполнять?

← →
leonidus (2008-05-31 18:50) [14]

Анатолий, простите не понял вас... если вы о явном присвоении:
AdoDataSet1.ExecuteOptions:=[eoAsyncExecute];

то я пробовал и в обжект инспекторе выставлять eoAsyncExecute, все равно подвисает программа...

← →
stas © (2008-05-31 20:56) [15]

leonidus (31.05.08 18:50) [14]
Я писал про Update, а ві делаете Select.

← →
leonidus (2008-05-31 21:00) [16]

сейчас посмотрел, действительно UPDATE выполняется довольно быстно, а вот с SELECT проблемка... его асинхронно никак выполнить нельзя?

← →
stas © (2008-05-31 21:01) [17]

Хотя можно и селект выполнять, вы почитайте как работать с запросами, которые выполняются асинхронно.

← →
stas © (2008-05-31 21:03) [18]

leonidus (31.05.08 21:00) [16]
Update не выполняется быстрее, он продолжает выполнятся в фоновом режиме

← →
Anatoly Podgoretsky © (2008-05-31 21:24) [19]

> Хотя можно и селект выполнять, вы почитайте как работать
> с запросами, которые выполняются асинхронно.

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

← →
Anatoly Podgoretsky © (2008-05-31 21:27) [20]

> Анатолий, простите не понял вас...

Это конференция не для начинающих, надо обладать хотя бы начальными знаниями.

← →
leonidus (2008-05-31 22:38) [21]

Анатолий я вас очень уважаю, но все же хотел бы получить ответ на свой вопрос, а не простите, посылание на три буквы.

← →
Anatoly Podgoretsky © (2008-05-31 22:51) [22]

Не та конференция, чтобы расписывать элементарщину, а ты сам очень высоко оценил свои знания, написав сюда, а не в начинающие.
Правда большинство твоих вопросов слишком простые и для той конференции. Так что читай справку там черным по белом написанов, всего то десяток строк. А если для тебя нет разницы между выборками и командами, так это знаешь кто виноват.

← →
leonidus (2008-06-01 01:57) [23]

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

← →
Германн © (2008-06-01 02:14) [24]

> leonidus (01.06.08 01:57) [23]
>
> Анатолий, причем тут выборки и команды, у меня вопрос в
> другом, мне нужно сделать так чтобы пока происходит выборка
> основной поток не подвисал. Прошу помочь мне в этом.
>

> Отображение прогресса при UPDATE базы [D6]
>
> leonidus (30.05.08 16:33)

Ты уж, Саид, определись, что тебе нужно.

← →
leonidus (2008-06-01 02:17) [25]

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

> leonidus

А как у вас всё организовано?

AdoDataSet1.ExecuteOptions:= подставить правильное значение, их то всего 4

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

← →
Ум_ще (2008-06-01 16:07) [29]

> leonidus (30.05.08 16:33)

Самое простое решение - выполнить последовательность запросов к БД в отдельном потоке. Соответственно, сможешь и ProgressBar организовать при этом.

> Ум_ще (01.06.2008 16:07:29) [29]

АДО и так автоматически поддерживает выполнение в отдельном потоке с поддержкой прогресса.

← →
Ум_ще (2008-06-01 17:38) [31]

> Anatoly Podgoretsky © (01.06.08 17:28) [30]
> > Ум_ще (01.06.2008 16:07:29) [29]АДО и так автоматически
> поддерживает выполнение в отдельном потоке с поддержкой
> прогресса.

Это не значит, что нельзя или не нужно в доп. потоке сделать выполнение запроса.

> Ум_ще (01.06.2008 17:38:31) [31]

Ему до потоков, как тебе до луны.

> Это не значит, что нельзя или не нужно
можно то можно, но вот не нужно это факт.
и даже вредно, заморачиваться на этом игнорируя(/не разбираясь) реальную причину тормозов... можно конечно "глаза замазать" но смысл?

у меня простой синхронный запрос за 2.5 сек возвращает 373426 записей (машина тоже старая, не 286й конечно но...). 1000 практически не считается разница по времени (то 0 то 016 миллисекунд) надо на подсчет тиков переходить чтобы замерить... и на это прогресс бар?

← →
Ум_ще-011 (2008-06-01 18:53) [34]

> можно то можно, но вот не нужно это факт.

Может быть.

>Автор

Проиндексируй в tab поле header.

← →
Умище-011 (2008-06-01 18:55) [35]

Удалено модератором
Примечание: Offtopic

Отображение прогресса при UPDATE базы Найти похожие ветки