Слишком большое число для проведения операции

[maxkov]

Случилась страшная кака - при пересчете балансов по периодам появились суммы размер которых превышает 32 байта и аксапта не может их записать и выдает ошибку SQL
что посоветуете сделать?
версия 4,0

[Sada]

бежать в кадры... А на самом деле интересная ситуация.... Я даже не знаю... Может завести ряд переменных и там хранить слагаемые.

[maxkov]

Ну вообще есть же страны у которых коробок спичек миллион стоит. Как то у них не переполняется ведь.

[MikeR]

А кто мешает сделать, как курс отношения 100:1000

[DmitryK]

Вы уверены, что правильно написали? 32 байта? Может все-таки бита? Или вам не принципиально? )
Для числа, хранимого в 32 байтах можно учитывать и спички по 1 млн.
Если мое предположение правильно, то данная проблема актуальна только для целочисленного представления данных.

C уважением, Дмитрий.

[maxkov]

ну биты биты )) не влазит вообщем


Error Сообщение (18:53:48) Невозможно создать запись в Операции по сальдо ГК (LedgerBalancesTrans). Номер счета : 51.02, 30.06.2012.
База данных SQL обнаружила ошибку.
Info Сообщение (18:53:48) Описание ошибки SQL: [Microsoft][ODBC SQL Server Driver]Числовое значение выходит за пределы допустимого диапазона
Info Сообщение (18:53:48) Оператор SQL: INSERT INTO LEDGERBALANCESTRANS (ACCOUNTNUM,TRANSDATE,DEBITMST,CREDITMST,DEBITOPRMST,CREDITOPRMST,DEBITTAXMST,CREDITTAXMST,PERIODCODE,DEBITMSTSECOND,CREDITMSTSECOND,DEBITOPRMSTSECOND,CREDITOPRMSTSECOND,DEBITTAXMSTSECOND,CREDITTAXMSTSECOND,QTY,SYSTEMGENERATEDULTIMO,LEDGERBALANCESVARIANT,DATAAREAID,RECVERSION,RECID) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)


А по поводу курса - уже куча операций по обычному курсу если сейчас поделить то миллион станет тыщей а старые проводки останутся миллионами

[TasmanianDevil]

Есть мнение, которое может быть ошибочным, но тем не менее ...

maxkov, а откуда дровишки про 32-бита ?
Вы уверены, что превышение именно в сумме?
32 бита - это обычный размер real на SQL, однако этот тип не применяется для хранения сумм для DAX, cуммы в DAX - это 13-байтовый Numeric(28,12), могущий хранить величины в пределах плюс/минус 10^28 - 1 (бессчетные окулиарды - как их превысить, ума не приложу).

Кроме того, 32-бита - это обычный int (который тоже является числовым значением, о котором говорится в ошибке). Данному типу у нас в приведенном запросе соответствуют:

1. поле RecVersion
2. поле SystemGeneratedUltimo
3. поле PeriodCode
4. поле LedgerBalancesVariant

Нет ли в данном случае попыток лечения китайца от желтухи и поиска черной кошки в темной комнате?
Можно трэйс запроса со стороны SQL-сервера в студию взамен корявого аксаптовского ?
Ибо есть серьезные подозрения (если Ваша правда про ругань именно на 32-хбитное число), что дело не в сумме, а int-овских полях

[DmitryK]

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

C уважением, Дмитрий.

[gl00mie]

Цитата:

Сообщение от maxkov

Невозможно создать запись в Операции по сальдо ГК (LedgerBalancesTrans). Номер счета : 51.02, 30.06.2012.
База данных SQL обнаружила ошибку. Числовое значение выходит за пределы допустимого диапазона

А вы не задумывались, откуда у вас за период такие суммы по счету взялись? Аналогичный случай был на форуме Dynamics Community. Там ошибка вылезала на вставке в InventSumDelta, и в результате некоторых изысканий выяснилось, что по одной из номенклатур просто была неправильно рассчитана себестоимость (ниже - скриншот из той темы), может, у вас тоже где-нить "не та" сумма проскочила?

[maxkov]

Были искусственные операции на большую сумму но тогда мы не звадумались о подобной проблеме. а ньюмерик реально не +-28знаков. мсдн врет