Временные файлы при выполнении SQL запроса

← →
zerohold (2008-05-13 21:23) [0]

Подскажите.
Использую стандартный компонент TQuery для выполнения SQL запроса, работаю с базой paradox.
Проблема в том, что после каждого выполнения запроса формируется временный файл и не удаляется. При накоплении 48 файлов (ограничение в настройках BDE Admin) появляется FatalError.
Увеличение количества файлов явно не правильное решение потому как запросов может быть больше.
значит чего делаю?
[code]
procedure ...
SQL=TQuery.Create(nil);

// сам запрос простой
SELECT t.ID, t.Name, t.Phones, t.Site, t.Email, t.Address, t.ModeWorks, t.IDSection, t.IDKind, t.IDCity, t.Priority, t.Rating FROM "company.db" t ORDER BY Priority DESC, Rating, Name
поля только char, integer и float
SQLs.DatabaseName:=PathData;
SQLs.SQL.Clear;
SQLs.SQL.Add(SQL_text); try
SQLs.ExecSQL;
except
on EDBEngineError do AddLogFile(NameErrorFile,"Error SQL. procedure SQL_Run; Text SQL: "+SQL_text);
end;
SQLs.Active:=True;
SQLs.First;

....
SQL.Free;

[/code]
я вот думаю может чего из-за сортировки такой сложной ?

← →
Виталий Панасенко(дом) (2008-05-13 22:15) [1]

а PrivateDir у Session не пробовал настроить ?

← →
zerohold (2008-05-13 22:22) [2]

Session вообще не использую.. я бы указал
убрал из запросов
ORDER BY
файлы временные перестали появляться и все заработало.
Как только добавляю ORDER by снова начинается глюки.

← →
Loginov Dmitry © (2008-05-14 00:33) [3]

> SQLs.ExecSQL;
> except
> on EDBEngineError do AddLogFile(NameErrorFile,"Error
> SQL. procedure SQL_Run; Text SQL: "+SQL_text);
> end;
> SQLs.Active:=True;

Временные файлы появляются и не удаляются только при ошибках, и то далеко не всегда.
У тебя же здесь по истине пляски с бубном!

А вот это:

> except
> on EDBEngineError do AddLogFile(NameErrorFile,"Error
> SQL. procedure SQL_Run; Text SQL: "+SQL_text);
> end;

диверсия. Лучше вообще без except..end. Как можно прятать оригинальное сообщение об ошибке?!

← →
Виталий Панасенко(дом) (2008-05-14 11:04) [4]

> zerohold (13.05.08 22:22) [2]
>
> Session вообще не использую.. я бы указал

Враки... Эта переменная присутствует, даже если ты и не "кинул" компонент.. Точно так же, как и Application...Так и называется - Session..

← →
MsGuns © (2008-05-14 12:16) [5]

>Виталий Панасенко(дом) (14.05.08 11:04) [4]
>.. даже если ты и не "кинул" компонент..

Его и не нужно "кидать" без крайней необходимости

← →
Виталий Панасенко(дом) (2008-05-14 12:35) [6]

> MsGuns © (14.05.08 12:16) [5]

Не спорю.. С прошедшим...:-)

← →
Виталий Панасенко(дом) (2008-05-14 13:04) [7]

Удалено модератором

← →
Amoeba © (2008-05-14 13:09) [8]

> // сам запрос простой
> SELECT t.ID, ...

> SQLs.DatabaseName:=PathData;
>
> SQLs.SQL.Clear;
> SQLs.SQL.Add(SQL_text);
> try
> SQLs.ExecSQL;

ExecSQL при запросе SELECT? Слов на такое нет, одни буквы.

← →
zerohold (2008-05-22 12:18) [9]

> Loginov Dmitry

> диверсия. Лучше вообще без except..end. Как можно прятать
> оригинальное сообщение об ошибке?!

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

> MsGuns ©

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

> Amoeba

Каюсь, виновен. CopyPast проклятый, не увидел очевидной вещи :(( дааа, но такое в нашей программной практике не редкость, бывает + с - перепутаешь в сложной формуле и тогда долго и очень долго ищешь что не так.

Тему можно закрыть
Исправил на SQLs.Open - все пошло и работает нормуль.
Спасибо всем

> Такого рода ошибки они явно не любят.

Больше они не любят, когда их дурят.

> Они вызывают катастрафическое "ААААаааа, все пропало" лучше
> прятать их, и потом смотреть в тихоря логи.

Бред. Полный. Лучше сообщить о них пользователю, чтобы пользователь дал знать о проблеме. Если он не будет о ней знать, то не сможет сообщить своевременно. А вот когда на пару-миллионный оборот пропадут данные, тогда будешь ему объяснять, что хотел "как лучше".

> Потому как все равно заставить клиента прочитать нормально
> код ошибки и его содержание это все равно что слона заставить
> говорить по тибетски.

Обязательно дублируй сообщение об ошибке в логах. Среднестатисчического оператора ты естественно не заставишь прочесть лог, приведенный на английском языке (скорее всего, и на русском языке оператор тоже прочесть не сможет, так как в 80% случаев он нажмет по привычке на <Enter> или <Escape>, никогда не читая, что ему напишешь, это не лечится).

> Видимо вы мало работали с клиентами.

Куда уж мне!

> Обязательно дублируй сообщение об ошибке в логах.

Даже если оператор неспособен сообщить администратору об ошибках программы (а это бывает очень часто, гдето в 80%), то потом начнут делать сверку, и обнаружат несхождения, с причинами которых помогут разобраться корректные логи. А то что ты предлагаешь:

> except
> on EDBEngineError do AddLogFile(NameErrorFile,"Error
> SQL. procedure SQL_Run; Text SQL: "+SQL_text);
> end;

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

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

Какие-то у тебя неправильные клиенты. Ты их меняй скорее, от них добра не будет

Временные файлы при выполнении SQL запроса Найти похожие ветки