ADO и фильтрация вещественных чисел

[netpolice]

Столкнулся с такой проблемой, ADOTable при фильтрации вещественных чисел абсолютность коряво фильтрует числа с запятой.

Если DecimalSeparator:='.'; то при фильтрации, но уже с точкой все ОК.

А, да ADO коннектим с MSSQL.

Сталкивался ли кто с этим, и есть ли корректное лечение?

[eval]

Сталкивался ли кто с этим, и есть ли корректное лечение?

никто не сталкивался, т.к. там все правильно фильтрует и вещественные и нет и черта лысого тоже правильно.

[netpolice]

А вот не надо меня поливать грязью, а возмите и проверьте, фильтрацию проведете через ADOTable1.Filter

Повторюсь данный феномен возникает при Если DecimalSeparator:=',';
т.е. по умолчанию.

[eval]

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

[netpolice]

Какой код указывать, если нету вообще ничего, на форму накидано ADOConnection1, ADOTable1, DataSource1, DBGrid1 все соеденено и все отображается, но как только ADOTable1.Filter:='l_sqf = 2,8658' не выдает ни одного значения, хотя их 2, далее если так ADOTable1.Filter:='l_sqf = 2.8658' то все Ок, хотя это не совсем правильно. Ведь DecimalSeparator из системы берет запятую (проверено). Соответственно если значения фильтра целые или вообще относятся к др. не вещественным полям то все ОК. Могу картинки скинуть если надо..

[eval]

да при чем тут ваш сепаратор? сепаратор он для чего?
вы когда в коде пишите вещественное число вы на сепаратор смотрите? а почему ?
а почему тут смотрите?

[Serge_Bliznykov]

согласен с eval - сепаратор нужен только для преобразования числа из внутреннего представления (двоичное, со знаком, порядком и мантиссой) во внешнее и обратно.
Т.е. например, когда используете StrToFloat или FloatToStr, или когда выводите поле в грид - вот тогда этот разделитель нужен.
видимо, при парсинге строчки в фильтре код написан так, что берётся всегда точка. (ну, точно так же, как поступает компилятор Delphi, когда Вы пишете x := 2.5; )
вот и всё, это и есть ответ на ваш вопрос...

[Аватар]

Добавлю ещё 3 копейки - фильтр на строгое равенство l_sqf = 2.8658 не обязательно отработает корректно из-за погрешностей преобразования в плавающий формат, даже если действительно такие данные есть в таблице.

[netpolice]

Да я понимаю, что сепаратор нужен только для удобочитаемости соответствующей рассы.

А по поводу точки все понятно, хотя и уныло.... Если использовать DBGridEh (из EhLib) с фильтрацией, то в этом случае нужно уже жестко привязывать сепаратор к точке, иначе уже EhLib начинает ругаться на точку