Еще как мешает. Такие ошибки округления лезут ...
Сейчам не могу привести компактный пример, но это прекрасно проявлется в сумме сделки продажи.

Серега, извини, не поверю, пока не увижу пример :) В ONTARIO у меня на float весь матучет работал без проблем.

На какой версии?

Начинали с 6.5, сейчас у них все на 2000.

См. начало темы. На 6.5 такой проблемы нет, а на 2000 наверняка им пришлось все на money переделать. Но это уже не твои проблемы, верно? :)

Что на money переделывать, матучет ? :) :)

Деньги изначально хранились в money, которое есть просто numeric(19, 4). Во float хранятся количества, которые проблематично запихнуть а numeric из-за неизвестной заранее необходимой разрядности для хранения количества в базовых ед.измерения.

Я сделал небольшой типовой тест на MSSQL2000.
Заполняется таблица из 1000 строк вещественными занчениями (количество и цена). Затем считаем сумму их произведений
1. Без округления
2. Округляя предварительно каждое количество до 4 знаков

Результаты после округления отличаются на единицу во втором знаке. И это при относительной погрешности 2,3e-10 (!)

set nocount on
go
create table F (v1 float, v2 money)
go
declare @count int, @i int, @r1 float, @r2 float
set @count = 1000
set @r1 = rand(datepart(ms, getdate()))
set @i = 1
while @i <= @count begin
  set @r1 = rand(@r1 * 100000000)
  set @r2 = rand()
  insert into F values (@r1 + @r2 * 1000, @r2 * 100)
  select @i = @i + 1
end
go
select
  sum(v1 * v2),
  convert(numeric(12, 2), sum(v1 * v2)),
  sum(convert(numeric(12, 4), v1) * v2),
  convert(numeric(12, 2), sum(convert(numeric(12, 4), v1) * v2))
from F
go
drop table F
go

34777247.629571319
34777247.63
34777247.63744812
34777247.64

нужна точность в итогах - делаем подгонку с требуемой точностью, не нужна - обходимся маленькой относительной погрешностью.

Это позиция кодера, а не аналитика.

Почему ? Я же сразу сказал, что точность нужна для официальной отчестности, а в управленческом учете допустимы небольшие относительные погрешности. Т.е. тип числа для хранения данных учета инвариантен итоговому представлению данных. Важно, чтобы разрядность была достаточной для обеспечения требуемой погрешности.
Собсно гря, этот вопрос (точность хранения, обработки и представления числовых данных) к постановке задачи финучета имеет отдаленное отношение. Максимум, как одно из требований.

Я тебе про то же и говорю. Если манагер считает, что для поиска причин расхождения в 1,33 евро нужно потратить время своих сотрудников (не думаю, правда, что час работы кого-то из них обходится фирме дешевле), то выкатывается соответствующее требование к точности.
Обычно же расхождения ищутся, если поиск будет стоит дешевле. Иначе просто спишут "на усушку".

О чем вообще дискуссия ? Округляй float во время обработки, а не по итогам, и ты получишь тот же самый numeric. Сделай вьюшку, где поля float будут представлены как numeric и работай с ней.
Проблемы не существует.

все должно биться до цента.

Да, весьма правильно.

О, вспомнил и нашел дискуссию в ФИДО по той же теме. Там и про Sybase и про вещественный склад есть :)
Вот ссылка на дискуссию
Вот ссылка на мое сообщение про склад и единицы измерения там же.

Вообще, тема сильно связана с единицами измерения.

Можно и numeric, только непонятно, "где запятую ставить"
ИМХО,
Можно и float

Да только реализовано на varchar() :) Т.е., что видит человек то и правильно

Для отчетности да convert(numeric() ) согласен
для арифметических всяческих наворотов да convert(float ) согласен
Но хранить надо в varchar()
Например, он хочет видеть такой формат

000444.565656000000 or
000444,565656000000

Какой numeric() или float справится? :)

В numeric запятая всегда на своем месте, в отличии от float.

В этом и проблема. Поставишь запятую в одно место - нормально, для других ТМЦ окажется запятой.
Если у тебя два склада в системе: один бетон учитывает, другой - химреактивы, то всякий раз придется "настраивать" разрядность и положение запятой.

При этом самый точный float (15 разрядов) занимает 8 байт (есть еще 8-разрядный 4-байтовый), а самый точный numeric (38 разрядов) - 17 байт, более чем в 2 раза больше.

У float очень небольшое кол-во значащих разрядов, использовать этот тип в регистрах учета нельзя.

У float 15 знаков с плавающей точкой. Относительная погрешность (1Е-15, 10 в минус 15 степени) уже физически недостижима при измерениях. Обычные весы в магазине - 10E-2, электронные - 1Е-3. Написать 20 знаков до запятой - это фикция. Нет таких весов даже близко.

Масса Земли 6*10^24 кг. Сколько у нее в 16 знаке - трудно сказать.

Таким образом, float обеспечивает охват практически всех физ.величин с разумной точностью учета (намного перекрывает все относительные погрешности измерений).

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

Еще пример. Грузоподъемность нефтяного танкера - около 100 тыс. тонн. Использование float позволит "учесть" (беру в кавычки, т.к. см. пример с арбузами) нефть с точностью до микрограммов.