Сообщество
FAQ
Логин
Пароль
Войти при помощи
Кстати, вы можете
Присоединиться к нам вконтакте
или почитать наш твиттер
Общение / Веб версия / максимальная сумма операции 21 473 836

Максимальная сумма операции 21 473 836

Кирилл
8 ноября 2011 19:26
максимальная сумма операции 21 473 836 недостаточна для ведения бухгалтерии в Беларуси)
Admin
8 ноября 2011 20:09
Здравствуйте.
Значем об этой проблеме.. ждём апгрейда сервера до 64 бит ОС.
Кирилл
8 ноября 2011 21:58
Оо, значит нескоро((
Ilyan
9 ноября 2011 11:24
А как это поможет? В 64-битной ОС до 64 бит увеличиваются адреса - а размер других типов данных от этого не зависит.
Admin
9 ноября 2011 11:25
Ilyan Пишет:
а размер других типов данных от этого не зависит
Зависит
Admin
9 ноября 2011 11:26
+ железо тоже должно быть 64 бит.
Ilyan
9 ноября 2011 11:31
Понятно, что всегда можно найти тип для целочисленных данных, который равен размеру адреса. Но зачем связывать абсолютно несвязанные типы? Что, в 32-битной ОС нет возможности хранить 64-битные числа?
Ilyan
9 ноября 2011 11:39
Например, при эспорте я получаю файлы с именами такого формата:

1000000012257_transfer.csv

Т.е. всё-таки можно и на 32-битной ОС как-то получать числа больше триллиона (т. е. больше 10 миллиардов + 2 знака после запятой).
Admin
9 ноября 2011 12:11
Ilyan Пишет:
Т.е. всё-таки можно
Как-то можно.. но сложно.
Ilyan
9 ноября 2011 12:17
Вот кстати пишут, что PostgreSQL поддерживает 8-байтовый bigint (с которым действительно могут быть проблемы из-за ОС и железа)

Но там же описаны и другие типы, например:

8.1.2. Arbitrary Precision Numbers

... It is especially recommended for storing monetary amounts and other quantities where exactness is required.
Admin
9 ноября 2011 12:25
В БД 8-байтовые типы хорошо поддерживаются уже давно.
А вот в PHP - нет. Только на 64-бит ОС.
Ilyan
9 ноября 2011 12:55
Тогда вообще непонятно - вы же умеете правильно подсчитать остаток на счету даже если он превышает 21 473 836 - значит суммирование 64-битное.
Admin
9 ноября 2011 13:04
Ilyan Пишет:
Тогда вообще непонятно
Это нормально, вы же не разработчик.
Если хотите поучаствовать в разработке - присылайте резюме и круг задач, которыми хотите/можете заниматься :).
Ilyan
9 ноября 2011 13:07
Т. е. проблема не в БД и не в арифметических операциях, а в том, что вы используете integer php для анализа ввода пользователя?

Но ведь и в php есть "Arbitrary length integer / GMP"!
Ilyan
9 ноября 2011 15:59
Точнее, похоже, что вы сначала используете числа с плавающей точкой (для вычисления выражения в поле "Сумма", даже если оно не содержит арифметических действий).

А уже потом, перед попыткой конвертировать во временный 32-битный integer, выдаёте ошибку переполнения. Причём проверка и сообщение об ошибке именно ваше, иначе максимальная сумма была бы на 47 копеек больше.

А ведь 64-битное число с плавающей точкой содержит достаточно информации, чтобы без потерь конвертировать в целые числа до 2^54-1, т. е. до 180 трлн. (рублей или любой другой валюты).
Ilyan
9 ноября 2011 16:12
* немного ошибся - 2^53-1 + ошибки округления... но 45 трлн. точно можно :)
Кирилл
24 декабря 2013 12:47
2 года, а воз и ныне там. Теперь максимальная операция в бел рублях едва превышает 2000$. Печаль(
zvuk_on
7 февраля 2014 18:03
Попытался сегодня ввести сумму превышающую 21 млн через импорт данных - написало что все успешно добавлено, но остатки не изменились, в отчетах операция не появилась. но в блоке "Контроль расходов" сумма в "Итоги февраля" поменялась.
Раньше (может месяц назад) такой импорт работал.
Admin
7 февраля 2014 20:16
zvuk_on Пишет:
но остатки не изменились, в отчетах операция не появилась
Здравствуйте,
Проверьте, может быть вы ошиблись с датой и операция попала в будущее? Если нет - сообщите строку импорта, которая "пропала".
zvuk_on
7 февраля 2014 20:31
да, действительно, в будущем нашел, прошу прощения
Чтобы отвечать на сообщения - зарегистрируйтесь и войдите в личный кабинет.
© drebedengi.ru 2007 - 2017  |  Мобильная версия  |  Карта сайта  |  API интеграции  |  Обратная связь  |   English