Суть примерно следующая: сейчас данные хранятся в DOUBLE PRECISION и при работе с данными постоянно появляется погрешность в одну копейку. К тому же в некоторых запросах используется конструкция типа x/y/z - где типы данных каждого поля - DOUBLE PRECISION. При использовании такой конструкции выскакивает ошибка "Arithmetic exception, numeric overflow, or string truncation". Я так понимаю дробная часть получается слишком большой...

В связи с этим было принято решение изменить тип данных полей на numeric(18,6). Для этого был создан новый домен с требуемым типом данных. Для полей созданы копии с новым доменом. Данные перенесены update'ом в новые поля.


Закомментированы все процедуры, триггеры и удалены все связи на эти поля. Удалены поля со старым доменом. Новые поля с новым доменом переименованы в старые. Все связи восстановлены, триггеры и процедуры раскомментированы. И напоследок даже Backup-Restore сделаны, но проблемы это не решило. Как писали одной похожей теме:
kdvв IB/FB существует "версионность метаданных таблиц". то есть, когда ты меняешь структуру таблицы - порядок, типы или размер столбцов - данные не трогаются, а просто показываются в новом формате.
В моем случае данные точно так же просто отображаются в новом формате. Что было сделано не так? Alter domain читал, собственно по форуму тоже почитал, но однозначного ответа не нашел. Вроде бы все сделано по технологии, но результат не соответствует ожиданию.

Прошу прощения, что ввел в заблуждение. Постараюсь ответить всем.

Симонов Денис 1. Какой диалект?
1. Используем третий диалект
Симонов Денис 2. Если ты создавал новое поле с новым типом, то почему же ты скопировал это поле само в себя, а не новое поле?
2. Поле я копировал не в само себя, а в этих таблицах было создано буферное поле. В него и копировал. Запрос набросал на скорую руку.
kdv - с одной стороны, автор показал свою крутизну использованием rdb$db_key
3. если это не сарказм, то... не считаю это крутизной, потому что не придумал иного способа как скриптом на 600 полей в которых может быть составной первичный ключ найти соответствие по полю (каюсь, sql не на столько хорошо знаю, как стоило бы, но познаю потихоньку по мере надобности).
kdv Если он добавил столбец нового типа к таблице, то опять же достаточно
update table set field1 = field
и зачем тут cast к "новому домену" - совершенно непонятно.
4. Не знал о таких нюансах.
MrCatOverflow, скорее, вызывает большой порядок (что-то около 10^308) результата. Который получается, небось, из-за многократного деления на "что-то около нуля" ("x/y/z"). Которое получается, небось, как разница между двумя "почти равными" (float же ж) значениями. В этом случае переход на NUMERIC не спасёт, ибо будет деление уже на чистый ноль.
kdv А с переполнением в конструкции x/y/z совсем мутно. Я скорее поверю, что переполнение будет при numeric(18,6) в третьем диалекте, чем с double precision в любом диалекте. Потому что при умножении и делении numeric в третьем диалекте точность (scale) складывается. То есть num(18,6)/num(18,6) будет num(18,12), т.е. для целой части остается всего 6 знаков.
На сколько я теперь понимаю нашей проблемы смена домена не решит. Не знаю всех причин, но вроде как основная причина - ошибка при делении трех столбцов "Arithmetic exception, numeric overflow, or string truncation".

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

S.G.,

Вам известны методы борьбы с "копейкой" ? На сколько я понял банки, например, округляют через раз: один раз происходит округление в большую сторону, другой в меньшую. Других примеров мне не известно.

Пока что у меня вопросов больше не осталось. С ошибкой "Arithmetic exception, numeric overflow, or string truncation" вроде разобрался, по крайней мере приведение результата деления cast-ом к numeric(18,6) помогло... Осталось проверить сотруднику, которому нужна эта реализация.

По поводу копейки методы реализации будем рассматривать. Лично мне подсказанное помогло узнать что-то новое, за что я всем благодарен.

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

Сейчас создал буферные поля, заполнил их запросами типа:


Получаю: значение в ячейке отображается как 7589,030000, а при двойном клике по ячейке вижу значение 7589,0299999999998. Тип поля Numeric(18,6). Просматриваю таблицу через IBExpert.
Вопрос: Почему значение показывается с некоторой погрешностью (и можно ли так выражаться в данном случае вообще??) и отразится ли это как-то на результатах запросов к этим полям?

kdv Но что-то у меня такое в памяти, что столбец double precision не превратится в int64 если его тип поменять на numeric(18,6) (надо проверять, но мне это не интересно).
В какой тип можно конвертировать double precision? Что сделать, чтобы не отображалось этой погрешности?

В другой теме спрашивали как сменить numeric на double precision, советовали для применения сделать "холостой update" т.е. поле присвоить самому себе - тоже не помогает.

Мимопроходящий Hello, Freddie26!
You wrote on 3 апреля 2015 г. 12:16:37:

Freddie26
> при двойном клике по ячейке вижу значение 7589,0299999999998.
> Тип поля Numeric(18,6).

у тебя поле создано не в третьем диалекте.


Диалект БД судя информации записанной в RDB$DATABASE - 3.
При подключении к БД я явно нигде не указываю диалект и собственно не нашел где его можно явно указать. Да и вроде бы он по умолчанию должен быть третьим.

Dimitry Sibiryakov Или ты врёшь про диалект, или это баг эксперта.
Что за выражение "врешь"? Я заинтересован в нахождении истины, зачем мне намеренно давать ложные данные?

Симонов Денис,

Выполняю скрипты в IBExpert в редакторе скриптов. На сколько я понял вы говорите, что я поля создал не в 3-м диалекте. Так вот мои действия: