Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2007.01.21;
Скачать: CL | DM;

Вниз

Mysql и delphi7   Найти похожие ветки 

 
FBuilder   (2006-10-31 10:16) [0]

Есть один проект - используются сабджи.
По таймеру идет обновление базы данных. Так вот - иногда, это обновление вываливается - вываливается или на запросе к БД или на обновлении
active := false;
active := true;

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

Мускул - 4.0.18
Доступ - ДБЕкспресс Д7.

1. Что может быть?
2. Как это локализировать и устранить?

Любые мысли нужны, так как свои уже кончились - осталось только повышать версию мускула, а это в данном случае тяжело :(((


 
ANB ©   (2006-10-31 10:32) [1]


> По таймеру идет обновление базы данных. Так вот - иногда,
>  это обновление вываливается - вываливается или на запросе
> к БД или на обновлении
> active := false;
> active := true;

1. По таймеру обновляться - некузяво, но я так понял - исторически сложилось.
2. Обновление и запрос к БД - это фактически одно и тоже.
3. А что за ошибка то ?


 
Johnmen ©   (2006-10-31 10:41) [2]


> обновление базы данных.


Это фактически модифицирующие запросы к БД. Что на них "вываливается"?


 
FBuilder   (2006-10-31 11:18) [3]

В программе стоит (пример)

function IsOrderLocked(aOrderID: integer): boolean;
var
 QueryTmp: TSQLQuery;
begin
 result := false;
 QueryTmp := TSQLQuery.Create(nil);
 QueryTmp.SQLConnection := frmDM.SQLConnection1;
 QueryTmp.MaxBlobSize := -1;

 try
   with QueryTmp do
   begin
     close;
     SQL.Text := "SELECT `lock` FROM `orders` WHERE `num`=" + IntToStr(aOrderID); //:porderid";

     _OpenQuery(QueryTmp);

     if RecordCount > 0 then
       result := (FieldByName("lock").AsInteger > 0);
     close;
   end;
 except
   ErrorSQL := true;
   LogMsg("error: checking order for lock"); //rem111
   CheckConnection;
 end;
 QueryTmp.Free;


Получаем:

[30.10.2006  14:15:16] order 19302 updated
[30.10.2006  14:15:19] order 19297 updated
[30.10.2006  14:19:09] error: Error in open_sql (before open=0): SELECT `lock` FROM `orders` WHERE `num`=19301

params - >
with sys_error #0, at address        0 message: "Операция успешно завершена"
[30.10.2006  14:19:09] error: checking order for lock
[30.10.2006  14:19:09] cheking connection...
[30.10.2006  14:19:09] connection ok

Этот запрос много раз -по 2 раза при обновлении заказа (что есть выше).


 
FBuilder   (2006-10-31 11:22) [4]


> По таймеру обновляться - некузяво, но я так понял - исторически
> сложилось.

А как лучше при ситуации по сети (+Интернет)
?


 
FBuilder   (2006-10-31 11:25) [5]

Код _OpenQuery (он и выбрасфвает ошибку) в прицнипе простой:

function _OpenQuery(query: TSQLQuery): boolean;
var
 Prms: TParams;
 ps: string;
 bo: boolean;
 i: integer;
begin
 bo := true;
 try
   if query.Active then query.close;

   Prms := TParams.Create;
   Prms.Assign(query.Params);

   for i := 0 to Prms.Count - 1 do
     ps := ps + ", :" + Prms[i].Name + "=" + Prms[i].AsString;

   query.SQL.Text := fgsSQL(query.SQL.Text);
//это прекодировка ` в " - для совместимости mysql и firebird.

   try
     query.Params.AssignValues(Prms);
   except
     LogMsgE("Error in open_sql: final param assigning, count1=" + IntToStr(query.Params.Count) + "; count2=" + IntToStr(Prms.Count));
   end;

   Prms.Clear;
   Prms.Free;

   bo := false;
   query.Open;
 except
//упало сюда...
   LogMsgE("Error in open_sql (before open=" + IntToStr(byte(bo)) + "): " + query.SQL.Text + #$D#$A"params - > " + ps);
 end;
 result := query.Active;
end;


 
FBuilder   (2006-10-31 11:26) [6]

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

Есть такое предположение, что может спасать переоткрытие коннекшена - но это как-то не весело :-/


 
Sergey13 ©   (2006-10-31 11:28) [7]

> [3] FBuilder   (31.10.06 11:18)

А зачем запрашивать рекордсет, если нужно просто наличие? Т.е. ИМХО логичнее был бы запрос
SELECT count(*) FROM `orders` WHERE `num`=:num


 
Sergey13 ©   (2006-10-31 11:33) [8]

> [7] Sergey13 ©   (31.10.06 11:28)

Хотя, сори, не заметил
FieldByName("lock").AsInteger > 0
Но параметры всяко лучше юзать для подобных запросов.


 
FBuilder   (2006-10-31 11:40) [9]


> Но параметры всяко лучше юзать для подобных запросов.

Согласен - они и юзаються обычно.

Но в чем проблема "почему падает???"?


 
Johnmen ©   (2006-10-31 11:50) [10]


> FBuilder


Лично я не понял, зачем столько всего накручено вокруг элементарного действия - задать значения параметрам. Это первое.
Второе. При работе с MySQL через DBX надо иметь в виду следующее:
1. По умолчанию коннект разрывается после выполнения запроса.
2. Если запрос селективный, то предыдущий селективный запрос в рамках того же коннекта будет закрыт. Не м.б. более одного открытого селективного запроса в рамках одного коннекта.
3. При определённых условиях коннект может клонироваться для обеспечения выполнения запроса.


 
ANB ©   (2006-10-31 11:58) [11]


> А как лучше при ситуации по сети (+Интернет)
> ?

Вообще то по таймеру многие обновляют.
Но, имхо, я бы продумал вариант определения необходимости обновления. Что-нибудь вроде события.


 
FBuilder   (2006-10-31 12:08) [12]


> Лично я не понял, зачем столько всего накручено вокруг элементарного
> действия - задать значения параметрам. Это первое.
Это приведены прокси функции, на которые ссылаються по всему коду программы. На этом уровне происходит а) логгинг, б) подмена синтаксиса для поддержки 2 баз - firebird и mysql. С firebird кстати, проблем как будто нет, но нужно более полные логи смотреть, что бы это утверждатью

> Второе. При работе с MySQL через DBX надо иметь в виду следующее:
>
> 1. По умолчанию коннект разрывается после выполнения запроса.
>
> 2. Если запрос селективный, то предыдущий селективный запрос
> в рамках того же коннекта будет закрыт. Не м.б. более одного
> открытого селективного запроса в рамках одного коннекта.
>
> 3. При определённых условиях коннект может клонироваться
> для обеспечения выполнения запроса.

Спасибо - уже есть над чем подумать, но что думать - пока не ясно :)

В принципе тут все сделано так, что все запросы к базе загнаны в один поток, но стресс тесты этоих обновлений за полчаса полной работы глюков не выдают :(.



Страницы: 1 вся ветка

Текущий архив: 2007.01.21;
Скачать: CL | DM;

Наверх




Память: 0.5 MB
Время: 0.046 c
3-1162332175
Vladimir_B
2006-11-01 01:02
2007.01.21
FreeReport утомил


2-1167517472
rolex
2006-12-31 01:24
2007.01.21
База данных на любом пк


15-1167239799
Kerk
2006-12-27 20:16
2007.01.21
Почта России. Тонкий стеб?


15-1167137406
AntiUser
2006-12-26 15:50
2007.01.21
Разработчики Firefox не смогли устранить ошибки при работе в ...


4-1157437127
ПЛОВ
2006-09-05 10:18
2007.01.21
Какой API ф-цией проверить состояние Radio Button