Кирилл
|
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
|
да, действительно, в будущем нашел, прошу прощения
|
|
|