DBGrid отображает не тот Float, что я ввел.

[Костя Мельников]

Здравствуйте, Я начинающий. Изучаю Delphi, базы данных. Подскажите, пожалуйста, у меня форма, на ней DBGrid, Edit, Button и др. База данных Access (mdb), для соединения использую ADOConnection, набор формируется в ADOQuery. Для занесения данных вызывается форма, там есть TimeEdit, AmountEdit и др., жмем кнопку «Сохранить» и данные, командой INSERT, вставляются в таблицу. В таблице есть поле «Time» тип «Дата/Время» с маской ввода «99:00:00;0;_», есть поле «Amount» (Сумма) тип «Одинарное с плавающей точкой». И ЗДЕСЬ Я НЕ ПОНИМАЮ: Я ввожу в AmountEdit, скажем «88,8», а в TimeEdit «12:31:16», в DBGrid-e же после сохранения Я вижу: в поле Amount «88,8000030517578», в поле Time «30.12.1899 12:31:16». При этом в таблице базы, данные хранятся в том виде в котором я их ввел, «88,8» и «12:31:16». Скажите, Пожалуйста, что это такое и будут ли лишние числа в поле Amount играть какую-то роль если я захочу сложить два таких числа и если будут, то как сделать, чтобы учитывались только два знака после запятой?

Не могу, ни где про это найти (тем более что не знаешь, что искать).

Заранее, Спасибо.

[Stilet]

Попробуй в ADOQuery выставить для этого поля свойство DisplayFormat #.##

[Костя Мельников]

Попробуй в ADOQuery выставить для этого поля свойство DisplayFormat #.##

Большое Спасибо, работает! А почему, это происходить? При расчете лишние цифры будут как то влиять на результат?

[Stilet]

При расчете лишние цифры будут как то влиять на результат?

Только при отображении. (хотя в некоторых случаях при округлении)

[Костя Мельников]

Ясно. Большое Вам Спасибо. И все-таки, если Вас не затруднит, уж очень интересно, откуда берутся эти цифры и дата такая странная? Ну, хотя бы намекните, а я дальше сам.

[Stilet]

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

[soleil@mmc]

а ты задавал точность при создании поля
в стандарте анси пишут, что для поля "с плавающей точкой" можно указывать точность - т.е. кол-во знаков после "запятой"
но в не очень хороших субд эта фишка так же нехорошо работает, т.е. ты указываешь точность и надеешься что там будут храниться числа, например, с 2 знаками после запятой, а оказывается вот такая чехарда и приходится прикручивать "костыли" в виде ЮДФ (как например реализовано было в интербейзе) для округления чисел

а дата такая странная - дык ты ж не указал дату, а по умолчанию она будет именно 30.12.1899
дата ведь имеет составной тип - дата + время

[Костя Мельников]

Точность в таблице задавать пробовал, не помогает.
После установки DisplayFormat в #.## , в DBGrid-е все нормально, а вот попробовал я вывести содержимое в Edit, опять ерунда: в базе храниться 12,3 в Edit-е отображается 12,3000001907349. Попробовал установить другой Access, был 2003 взял 2007, никакой разницы. Скажите можно это как-то решить раз и навсегда, что бы этих лишних цифр не было совсем, чтобы работать только с теми данными, которые ввел?

Скажите это вообще, чья вина Delphi или Access-а, я как-то не понял?

а дата такая странная - дык ты ж не указал дату, а по умолчанию она будет именно 30.12.1899

А какой тип поля нужно выбрать, мне только Время нужно, там отдельного такого типа нет, это получается, теперь эта дата всегда будет красоваться на экране? Я не понял, формат Access, что не предназначен для работы с типом «Время», как это вообще решается, люди же с ним как-то работают, или нет, подскажите, пожалуйста?

И еще вопрос, Я в сленге не разбираюсь, я новичок, что значит:

приходится прикручивать "костыли" в виде ЮДФ

.

[Stilet]

чья вина Delphi или Access-а, я как-то не понял?

Процессора. Подай на него в суд
Получай в Эдит число так:

Edit1.text:=format('%.2f',[Таблица.FieldByName('Поле').AsFloat]);

[soleil@mmc]

ЮДФ = UDF (User Defined Functions)
по-моему, в парадоксе они недоступны

2 Stilet
при чем здесь процессор
просто криворукие создатели
меня как пользователя не должно волновать каким образом они добьются того же представления введенного числа если в поле задана точность представления этого числа (пусть хоть десятикратное округление прикручивают на уровне БД)