Привет всем!

Усиленно осваиваю курсорадаптер VFP9SP1.
Наткнулся на интересный глюк: есть (на MS-SQL) поле nSum тип SMALLMONEY, делаю курсорадаптер в DE формы и его подставляю источником для грида. Тут все нормально.

Хочу понизить точность, чтобы не четыре знака после запятой, а два было:
CA.CursorSchema = '... NSUM n(11, 2) ...'
CA.UseCursorSchema = .T.

Вот тут все и начинается: грид показывает 4 знака после запятой (brow тоже), но стоит только встать на эту ячейку так становится 2 знака после запятой.

Пока полечил: Grid.Column1.Format = '999999.99'.
Можно конечно еще Grid.Column1.Text1.Format = '999999.99' и вообще курсорсхему не пользовать,
но как-то это не красиво получается. Может я чего не доделал?

PaulWistВ самом select-e использовать explicit conversion из small money в decimal (12,2)
Выход конечно, но хочется на стороне фокса порешать. Остановлюсь пока на форматах.

PaulWistЕсли на стороне фокса, то не заставляйте драйвер ODBC выполнять работу по конвертации из одного типа в другой...
Ну на счет ODBC драйвера ты допустим загнул. Преобразование по CursorSchema фокс делает.

Как я понимаю свойство CursorSchema как раз и нужно для ручного приведения типа фоксом. Не все типы фокса есть на MSSQL и наоборот. С датами все на ура проходит, кстати без CursorSchema мне никак не удалось DATE получить, нет такого типа у MSSQL.

А глюк этот похоже в наследство от dbf-а достался, где NUMERIC фактически как строка хранится, сохраняется например '100.0000' и точка жестко не забита, например 100 в формате N(5,2) будет хранится как '100.0' (хотя переполнение должно быть), а при выводе форматируется под заданную структуру. Наверно в текстбоксах форматирование под структуру сделали, а в гриде и brow забыли.

PS Money у MSSQL это Currency фокса, аналога smallmoney у фокса нет.

PaulWist... в фоксовом курсоре необходимо тоже иметь тип данных money Что я и сделал через Grid.Column1.Format и Grid.Column1.Text1.Format

ВладимирМ1. Проверь, какой реально тип данных получился у поля курсора. Можно по AFILEDS() Пробовал copy to ... - отрабатывает правильно N(11,2), как я и задал. AFILEDS() тоже N(11,2) дает

ВладимирМ2. Если активная ячейка показывает не то, что не активная, то это может быть ошибка в самих данных. Format всего-лишь прячет проблему не вылечивая ее.
Дак и надо "спрятать". Проблема только в гриде пока не встанешь на ячейку (т.е. пока текстбокс в ячейке не появится). Если поле привязано к текстбоксу на правку - все нормально N(11,2)

ВладимирМ3. Если поле нужно только на чтение, то попробуй преобразовать ее на MS SQL через CAST() в тип Real или Decimal. Если поле нужно на модификацию, то посмотри что именно происходит при записи. Записывается то, что нужно или тоде есть проблемы?
По идеологии клиент-сервера задача сервера предоставлять данные, а клиента отображать. Потому и не хочу сервер лишней работой напрягать если на клиенте задача решается. Чтоб потом когда база распухнет голову не ломать про разгрузку сервера.

PS Вопрос решился. Окончательное решение получилось такое - в Init() базового класса грида прописал обход колонок и для типа currency установку InputMask = '999,999,999.99'. Про Format выше я поторопился, он на currency не действует.

2 PaulWist. А так:

Деньги считают с точностью до копейки, а не до тысячных долей копейки. И непонятно к чему про точность разговор. Ограничения money форматов известны, также как и преимущества. Формат изначально расчитан на хранение денежных сумм. Четырех десятичных знаков достаточно для точного проведения любых расчетов с делением и последующим округлением результата до копеек.

Физически money это INT у которого показывают точку смещенную на 4 знака при визуализации. Благодаря этому нет проблем с точностью при больших размерностях чисел. Если число влазит в размерность, то оно хранится без искажений:
2. Меньше места при хранении (для MSSQL money - 8 байт, smallmoney - 4 байта)
3. Быстрее расчеты. Процессор быстрее выполняет операции над целочисленными двоичными операндами, чем с плавающей точкой или двоичнодесятичными.

PS Предлагаю религиозную войну прекратить. Вопрос я все-таки по курсорадаптер задавал.

ВладимирМС типом Numeric тип Money - "не дружит" ...
Я думаю Numeric фоксовый ни с кем не дружит. Т.к. в DBF-е он хранится как строка, то гридом и brow выводится как есть. В курсорах вряд ли что поменяли. А КА и вью сначала происходит какое-то стандартное преобразование в numeric, а потом смена типа на заданный. Так видим тоже 4 знака:
Хотя numeric MSSQL и numeric фокса это тоже два разны формата.

А вот если nSum = 100 и CA.CursorSchema = '... NSUM n(5, 2) ...' то 1 знак после запятой: 100.0

Такое впечатление что MS с преобразованием типов перемудрили. Переоптимизировали видать

PS Будем считать это фичей, а не багом.

PaulWist Dima T
Деньги считают с точностью до копейки, а не до тысячных долей копейки. И непонятно к чему про точность разговор.

Найдите сумму НДС от 1 шт товара стоящего 10 коп, а затем найдите сумму НДС для 10 шт товара по 10 коп, что называется почуствуйте разницу. Уже почувствовал, лет 7-8 назад. Спасибо нашим законописателям. В опте НДС на сумму считается, в рознице на штуку, а в документах все до копеек округляется. Оптовики же "доброе дело" делают, считают кто во что горазд, под розницу якобы подстраиваются. Вот самые популярные методы:
1. Сумма НДС = ROUND(Сумма без НДС * Ставка НДС, 2)
2. Сумма НДС = ROUND(Сумма с НДС * Ставка НДС / (100% + Ставка НДС), 2)
3. Сумма НДС = ROUND(Цена без НДС * Ставка НДС, 2) * Количество
А потом розница приходует это безобразие и матерится - копейки в суммах не сходятся. Такое типами данных не лечится.
Мой конечный вариант - сделал три алгоритма расчета входящего НДСа при приходе. Тип алгоритма привязывается к поставщику, при появлении расхождений в суммах алгоритм меняется. После этого проблема с "копейками" закрылась.

PaulWistСогласен, главное, что когда у Вас "полезут" непонятки с мат действиями над суммами Вы вспомнили данное обсуждение Не надо вспоминать, надо просто не забывать когда делить собираешься.

PS Я ж не агитирую за использование money форматов повсеместно, а сам прекрасно представляю все ньюансы их использования.