Исключение

← →
zsnark (2002-11-05 17:59) [0]

В приложении выполняется SQL-запрос к таблице Paradox, содержащей поля типа Number. На четырех из шести машин запрос выполняется и результирующая выборка достигается. На двух остальных при попытке в первый раз выполнить этот запрос вываливается исключение "Floating point overflow". При повторной попытке выполнения запроса с теми же параметрами выборка приходит успешно. Меняем параметры запроса и снова при его первом выполнении появляется данное исключение.
Я первым делом начал грешить на железо (у тех машин, на которых наблюдается глюк, примерно одинаковая конфигурация, отличающаяся от машин, на которых все в порядке)

Буду признателен за каждый ваш ответ.

← →
MsGuns (2002-11-05 20:20) [1]

Query.Prepare есть перед запуском ?
И приведи текст запроса с указанием типа полей (в частности того, на котором переполнение.

← →
Max Zyuzin (2002-11-06 08:38) [2]

А переполненеи происходит именно при выполнении запроса? Или при "где то рядом"? Например при задании параметров зпроса?

← →
zsnark (2002-11-06 17:48) [3]

Подробности проблемы исключения с плавающей точкой.
Небольшое уточнение, не меняющее в принципе сути проблемы, в формулировке исключения "Invalid floating point operation" (прошу прощения, просто проблема давняя и даже подзабыл точный текст сообщения).

Метод Prepare перед запуском не стоял, но и его добавление не помогло.

Исключение происходит непосредственно при открытии запроса, а не
в момент инициализации параметров.

Текст запроса:
SELECT G.Gr, S.FIO, //строковые поле
sum(C.Nach - C.Oplach) //оба значения полей типа Number
FROM Gr.db as G, St.db as S, Crd.db as C
WHERE (G.GrID = S.GrID)and(S.StID = C.StID)
and(((S.PPID = 1)and(C.MID <= :edge1))
or((S.PPID = 2)and(C.MID <= :edge2))
or((S.PPID = 3)and(C.MID <= :edge3))
or((S.PPID = 4)and(C.MID <= :edge4)))
GROUP BY G.Gr, S.FIO

Впечатление такое, что это все из-за выражения в операторе WHERE

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

← →
MsGuns (2002-11-06 18:28) [4]

SELECT G.Gr, S.FIO, //строковые поле
sum(CAST(C.Nach as DECIMAL(12.2))- CAST(C.Oplach as DECIMAL(12.2)) //оба значения полей типа Number

и везде дальше вместо плав.поставь CAST(... as DECIMAL...)

← →
zsnark (2002-11-07 10:36) [5]

При попытке сделать явное приведение CAST выдается исключение о том, что данная возможность не поддерживается. "Capability not supported". Возможно это вследствие того, что используемый диалект не поддерживает явного приведения.

← →
Max Zyuzin (2002-11-10 08:19) [6]

>zsnark © (06.11.02 17:48)
А как значение параметрам присваиваете?

← →
zsnark (2002-11-10 20:11) [7]

Присвоение параметра идет следующим образом:
Query.ParamByName("Edge1").AsInteger=(StrToInt(Edit3.Text)+StrToInt(Edit4.Text))*100+ m;

Примерные значения.
Edit3.Text = "2001"
Edit4.Text = "2002"
0<=m<=9

Может быть, вместо доступа к значению параметра через AsInteger
попробовать свойство Value?

← →
Max Zyuzin (2002-11-11 08:29) [8]

>zsnark © (10.11.02 20:11)
На самом деле лучше оставить так как есть AsInteger;
Тогда давайте попробуем так - а какой тип имеют поля S.PPID и C.MID?

← →
exit (2002-11-11 09:44) [9]

Как много слов и ни одного по делу. Проблема с System Locale. В английской версии опер. систем Decimal Separator - обычно " . ", а в русских - " , ". Самый простой, но не самый красивый путь - при запуске приложения объявлять
DecimalSeparator := ",";
или
DecimalSeparator := ".";
по желанию.

← →
Max Zyuzin (2002-11-11 10:23) [10]

>exit (11.11.02 09:44)
А какое отношение DecimalSeparator имеет отношение здесь? Здесь на сколько я вижу нет попыток произвести преобразование из строк в float. (только целые)

← →
exit (2002-11-11 10:28) [11]

Во-первых при том, что нужно смотреть на описание ошибки,
во-вторых при том, что поле типа Number способно хранить числа с плавающей точкой и если в нем хранится число 3.14, а в операционке дробные числа форматируются #,## - будет ошибка.

← →
zsnark (2002-11-11 12:59) [12]

Полe S.PPID имеет тип Short (значения, хранящиеся там значения от 1 до 4), поле C.MID - Long Integer.

Настройки разделителя Decimal Separator просматривал через BDE Administrator (настройки совпадали с настройками на машинах с работающей программой). Но в замечании о разделителе остается неясным момент, когда в момент подобного сбоя при повторном открытии запроса выборка возвращается, хотя между этими двумя попытками никаких изменений в настройках Decimal Separator не производится, но печатный отчет по прежнему не формируется, выдавая подобный же сбой.

Вообще-то, после открытия запроса происходит фильтрация
по полю sum(C.Nach - C.Oplach) as Dolg с условием Dolg>0, которое задается во время проектирования, а не в коде.

Как вы думаете, может ли данное условие фильтра вызывать это исключение?

← →
Max Zyuzin (2002-11-11 13:08) [13]

А почему бы сразу в запросе не отбирать ненужные записи? Кстати по поводу отчета - вы сначала визуально просматриваете это или сразу в отчет пакуете?

← →
MsGuns (2002-11-11 13:18) [14]

А нельзя вместо параметров использовать динамическое формирование запроса
qu.Close;
qu.SQL.Clear;
qu.SQL.Add("SELECT...
qu.SQL.Add(" FROM...
...
qu.Prepare;
qu.Open;

Что-то мне подсказывает, что CAST не прокатывает именно из-за пераметров..

← →
ShuraGrp (2002-11-11 13:41) [15]

Надо определить тип параметров (Integer, input) в разделе параметры

← →
zsnark (2002-11-11 14:07) [16]

> Max Zyuzin (11.11.02 13:08)
К сожалению, фильтровать в самом запросе невозможно всвязи с логикой желаемых результатов запроса (фильтровать требуется по общей сумме, а не по каждой из суммируемых разностей (которые могут быть и положительные, и отрицательные, и нулевые)).
Для печатного отчета вначале вызывается метод Preview, который выводит на экран белый лист и сообщение "Invalid floating point operation".

>MsGuns (11.11.02 13:18)
Я обязательно опробую динамическое формирование строки запроса (все осложняется тем, что на машине, где я сам отлаживаю проект, все работает нормально, и среду надо устанавливать на машине клиента-бухгалтера, который весь день занимает машину; только в конце рабочего дня появляется возможность). Насколько это преобразование будет успешным я сообщу отдельно.

>ShuraGrp (11.11.02 13:41)
Типы значений параметров Integer, а также тип входного параметра в проекте указаны.

← →
Max Zyuzin (2002-11-11 14:18) [17]

>zsnark © (11.11.02 14:07)
А если все это дело в простой грид выводить сначала... сразу в отчет не лепить? Может грабли в отчете...?

← →
ShuraGrp (2002-11-11 14:21) [18]

Попробуй пересоздать поля Query.

← →
exit (2002-11-11 14:26) [19]

А еще настроить для Query типы Params

← →
zsnark (2002-11-11 14:47) [20]

В приложении именно подобным образом и сделано: вначале запрос выборка выбрасывается в форму с Grid"ом, а затем уже по отдельной кнопке распечатывается отчет. И исключение появляется еще до первого использования распечатки.

← →
zsnark (2002-11-11 14:54) [21]

>ShuraGrp (11.11.02 14:21)
Каким образом пересоздать? В Design Time?

>exit (11.11.02 14:47)
Настраивать типы в период run-time?

Но как же все-таки при повторном вызове запроса он выдает результат? Даже если происходит некоторая путаница с типами полей и параметров? Как ЭТО можно объяснить?

← →
exit (2002-11-11 15:07) [22]

> Настраивать типы в период run-time?

Зачем же в run-time? Не нужно перегибать палки.

> Но как же все-таки при повторном вызове запроса он выдает
> результат? Даже если происходит некоторая путаница с типами
> полей и параметров? Как ЭТО можно объяснить?

Это к тем, кто писал BDE скорее всего вопрос.

← →
MsGuns (2002-11-11 16:11) [23]

>exit (11.11.02 15:07)

Не помню кто именно сказал у Шекспира:

"Есть много в мире, друг Горацио,
Что и не снилось нашим мудрецам",

но он явно имел в виду и BDE ;))))

← →
Андрей Прокофьев (2002-11-11 16:14) [24]

← →
ShuraGrp (2002-11-13 10:28) [25]

А нет ли у тебя значения в полях = Null. В D6 up2 Null значения необходимо контролировать самому. Похоже, что во второй раз у тебя как раз поля уже имеют конкретные значения, поэтому и не ругаются.

Исключение Найти похожие ветки