Ошибка при выполнении арифметической операции переполнение при преобразовании

Ошибка при выполнении арифметической операции Переполнение при преобразовании значения

 ВЫРАЗИТЬ(втИтоги.КоличествоОборот / втИтоги.ПланМП1 * 100 КАК ЧИСЛО(5, 2)) КАК ПроцентВыполнения   

I keep getting this error message everytime I run this query:

Msg 8115, Level 16, State 8, Line 33
Arithmetic overflow error converting numeric to data type numeric.
The statement has been terminated.

But if I change the create table to (7,0), I don’t get the error message.But I need my data to be displayed as a decimal. I have tried 8,3 does not work.

Is there any one who can help me work this?Any help will be greatly appreciated.

DECLARE @StartDate AS DATETIME
DECLARE @StartDate_y AS DATETIME
DECLARE @EndDate AS DATETIME
DECLARE @temp_y AS DATETIME

SET @temp_y = Dateadd(yy, Datediff(yy, 0, Getdate()), 0)
SET @StartDate_y = Dateadd(dd, 1 - Datepart(dw, Dateadd("ww", -2, @temp_y)),
                                      Dateadd("ww", -2, @temp_y))
SET @StartDate = Dateadd(dd, 1 - Datepart(dw, Dateadd("ww", -2, Getdate())),
                                  Dateadd("ww", -2, Getdate()))
SET @EndDate = Dateadd(dd, 6, @StartDate)

--temp table to hold all cities in list
CREATE TABLE ##temp
  (
     city VARCHAR(50)
  )

INSERT INTO ##temp
VALUES     ('ABERDEEN'),
            ('CHESAPEAKE'),
            ('Preffered-Seafood/CHICAGO'),
            ('Preffered-Redist/CHICAGO'),
            ('CLACKAMAS'),
            ('COLUMBUS'),
            ('CONKLIN'),
            ('DENVER'),
            ('FORT WORTH'),
            ('HANOVER PARK'),
            ('JACKSONVILLE'),
            ('LAKELAND'),
            ('MONTGOMERY'),
            ('PFW-NORTHEAST'),
            ('PFW-SOUTHEAST'),
            ('RIVERSIDE'),
            ('TRENTON,CANADA'),
            ('VERNON')

--temp to hold data for the cities
CREATE TABLE #temp
  (
     city            VARCHAR(50),
     ytdshipments    INT,
     ytdtotalweight  DECIMAL(7, 2) NOT NULL,
     ytdtotalcharges DECIMAL (7, 2) NOT NULL
  --YTDRevperPound decimal (7,2) not null
  )

INSERT INTO #temp
SELECT ##temp.city,
       0,
       0,
       0
FROM   ##temp

INSERT #temp
-- YTD shipments/Charges/Weight by city
SELECT city = CASE
                WHEN nameaddrmstr_1.city IN( 'ABERDEEN', 'CHESAPEAKE', 'CHICAGO'
                                             ,
                                             'CLACKAMAS',
                                             'COLUMBUS', 'CONKLIN', 'DENVER',
                                             'FORT WORTH',
                                             'HANOVER PARK', 'JACKSONVILLE',
                                             'LAKELAND'
                                             ,
                                             'MONTGOMERY'
                                                    ,
                                             'RIVERSIDE', 'TRENTON', 'VERNON' )
              THEN
                CASE
                  WHEN
              nameaddrmstr_1.city = 'CHICAGO'
              AND h.shipr = 'PREFRESVS' THEN 'Preffered-Redist/CHICAGO'
                WHEN
              nameaddrmstr_1.city = 'TRENTON'
              AND nameaddrmstr_1.city = 'CA' THEN 'TRENTON,CANADA'
                ELSE
              nameaddrmstr_1.city
                END
                ELSE 'Other'
              END,
       ytdshipments = COUNT(CONVERT(VARCHAR(10), h.dateshipped, 101)),
       ytdtotalweight =SUM(CASE
                             WHEN h.totaldimwgt > h.totalwgt THEN h.totaldimwgt
                             ELSE h.totalwgt
                           END),
       ytdtotalcharges = SUM (cs.totalestrevcharges)
--YTDRevperPound = convert(decimal(7,2),sum (cs.TotalEstRevCharges )/sum( CASE WHEN h.TotalDimWGT > > h.TotalWGT THEN h.TotalDimWGT ELSE h.TotalWGT END ))
FROM   as400.dbo.hawb AS h WITH(nolock)
       INNER JOIN as400.dbo.chargesummary AS cs
         ON h.hawbnum = cs.hawbnum
       LEFT OUTER JOIN as400.dbo.nameaddrmstr AS nameaddrmstr_1
         ON h.shipr = nameaddrmstr_1.nameaddrcode
WHERE  h.dateshipped >= '01/01/2010'
       AND h.dateshipped <= '12/19/2010'
       --WHERE H.DateShipped >= >= @StartDate_y AND H.dateshipped <= @EndDate 
       AND h.cust IN( 'DARDENREED', 'MAINEDARDE', 'MBMRIVRSDE', 'MBMCOLUMBS',
                      'MBMLAKELND', 'MBMFTWORTH', 'SYGMACOLUM', 'SYGMANETW6',
                      'MAI215', 'MBMMNTGMRY' )
GROUP  BY CASE
  WHEN nameaddrmstr_1.city IN( 'ABERDEEN', 'CHESAPEAKE', 'CHICAGO', 'CLACKAMAS',
                               'COLUMBUS', 'CONKLIN', 'DENVER', 'FORT WORTH',
                               'HANOVER PARK', 'JACKSONVILLE', 'LAKELAND',
                               'MONTGOMERY'
                                      ,
                               'RIVERSIDE', 'TRENTON', 'VERNON' ) THEN CASE
                                                                         WHEN
nameaddrmstr_1.city = 'CHICAGO'
AND h.shipr = 'PREFRESVS' THEN 'Preffered-Redist/CHICAGO'
                                                                         WHEN
nameaddrmstr_1.city = 'TRENTON'
AND nameaddrmstr_1.city = 'CA' THEN 'TRENTON,CANADA'
                                                                         ELSE
nameaddrmstr_1.city
                                                                       END
  ELSE 'Other'
END

SELECT #temp.city                 AS city,
       MAX(#temp.ytdshipments)    AS ytdshipments,
       MAX(#temp.ytdtotalweight)  AS ytdtotalweight,
       MAX(#temp.ytdtotalcharges) AS ytdtotalcharges
FROM   #temp WITH(nolock)
       LEFT OUTER JOIN ##temp
         ON ##temp.city = #temp.city
GROUP  BY #temp.city

DROP TABLE #temp

DROP TABLE ##temp  

31.01.16 — 21:52

Добрый день!

Конфигурация УТ 11.1.10.145, платформа 8.3.6.2237, SQL Server 2008.

При проведении документа «Расчет себестоимости товаров» за апрель, выскакивает ошибка

Ошибка при выполнении обработчика — ‘ОбработкаПроведения’

по причине:

{Документ.РасчетСебестоимостиТоваров.МодульОбъекта(2181)}: Ошибка при вызове метода контекста (ВыполнитьПакет)

        Выборка = Запрос.ВыполнитьПакет()[1].Выбрать();

по причине:

Ошибка выполнения запроса

по причине:

Ошибка при выполнении операции над данными:

Microsoft SQL Server Native Client 10.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.

HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Все  другие документы проводятся нормально. Подскажите пожалуйста, все чем может быть проблема, куда смотреть?

1 — 31.01.16 — 21:53

Я понимаю, что где-то в результате запроса получается большое число, вот только как найти, откуда это число возникает?

2 — 01.02.16 — 07:37

Пройтись отладчиком + ТИИ

3 — 01.02.16 — 11:57

Отладчик мне ничего не покажет, программа завершается в момент Выборка = Запрос.ВыполнитьПакет()[1].Выбрать(); , значит я не узнаю, что её выбивает. В файловом варианте база тоже не запускается, размер слишком большой.

4 — 01.02.16 — 12:04

обновитесь, говорят, на 11.1.10.150 проблема уходит.

5 — 01.02.16 — 12:14

(3) Можно попробовать в консоли удалять из пакета по 1. Или выполнять по 1.

6 — 01.02.16 — 12:16

профайлером (или тж) засечь запрос и посмотреть

7 — 01.02.16 — 15:21

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

8 — 02.02.16 — 16:16

Обновление не дало результатов. В ТЖ и профайлер смотрел — ничего не понял. Подскажите, может по какому нибудь регистру посмотреть какие нибудь значения подозрительные?

9 — 02.02.16 — 16:19

(8) первый запрос из пакета генерит не перевариваемое число — посмотри, какие там числовые поля и попытайся понять, откуда мб такое большое

10 — 02.02.16 — 17:16

(8) поищите большой ресурс «ПостояннаяРазница» в регистре ВыручкаИСебестоимостьПродаж в консоли запросов

11 — 02.02.16 — 18:37

(0) Скорее всего, это происходит где-то при делении, попробуй все такие места явно обработать через ВЫРАЗИТЬ( КАК ЧИСЛО(xx,yy))

12 — 02.02.16 — 18:53

ИР тебе в помощь — там и разбивка запроса на подзапросы, и отбор ТЖ по конкретному запросу

13 — 03.02.16 — 09:26

14 — 03.02.16 — 12:58

Запрос выполняется с использованием Менеджера временных таблиц

15 — 03.02.16 — 13:02

Еще глупый вопрос, в запросе выполняется первый пакет. Как мне его найти?

16 — 05.02.16 — 09:26

я вычислил, что всему виной вот эта строчка в запросе

|    ВЫРАЗИТЬ(СУММА(ЕСТЬNULL(ВтТаблицаРешений.ПостояннаяРазница, 0) * ЕСТЬNULL(ПеремещенияСписания.Количество, 0)) КАК ЧИСЛО(23,10))

Здесь и происходит переполнение.

17 — 05.02.16 — 09:35

(16) выкини выразить оттуда

18 — 05.02.16 — 09:35

и спи спокойно дальше

19 — 05.02.16 — 09:42

(17) Не помогло, все та же ошибка преобразования numeric.

Что интересно, только за апрель документ выжучивается, следующий месяц проводится без проблем.

20 — 05.02.16 — 09:43

ну поставь  КАК ЧИСЛО(15,0)

21 — 05.02.16 — 09:53

(20) Все так же упрямо выскакивает эта ошибка.

22 — 05.02.16 — 10:00

23 — 05.02.16 — 10:03

вообще, ИМХО, ВЫРАЗИТЬ в Сумма засунуть.

24 — 05.02.16 — 10:09

(16) Выведи в отладке содержимое ВтТаблицаРешений в ТЗ и посмотри, что там за числа.

25 — 05.02.16 — 10:53

(23) выразил, снова ошибка. (24)  Глазами пробежался по 12к строк, на первый взгляд никакого криминала. Попробую покромсать запрос и выполнять по частям.

26 — 05.02.16 — 13:11

Получается, что «ВтТаблицаРешений.ПостояннаяРазница» и «ПеремещенияСписания.Количество» имеют значение Null.

И если подставить, то получается, что выражение

ВЫРАЗИТЬ(СУММА(0 * 0) КАК ЧИСЛО(23,10)) — вызывает арифметическое переполнение.

27 — 05.02.16 — 13:50

Был неправ, зайдя дальше обнаружил, что умножение «ВтТаблицаРешений.ПостояннаяРазница» и «ПеремещенияСписания.Количество» на какой то итерации дает переполнение, буду двигаться дальше.

28 — 09.02.16 — 15:52

При проведении документа «Расчет себестоимости» формируются записи регистра накопления «Себестоимость товаров». Так вот за 2014 год все формировалось нормально, а с 2015 в колонке «Стоимость (ПР)» — постоянная разница, только по 2-3 номенклатурам начали появляться и расти огромные числа. Подскажите, из-за чего растет постоянная разница строго по 2 позициям номенклатуры?

Пример. Одна организация, два склада.

Документ перемещения формирует две записи в регистре накопления — Количество(10) по двум складам.

Документ Расчет себестоимости товаров формирует одну запись — Стоимость(ПР) : 134 046 229,30.   Откуда такая цифра? Причем некоторые записи идут корректно, в чем разница, так и не понял.

фпк1сл

31.01.16 — 21:52

фпк1сл

1 — 31.01.16 — 21:53

Я понимаю, что где-то в результате запроса получается большое число, вот только как найти, откуда это число возникает?

cw014

2 — 01.02.16 — 07:37

Пройтись отладчиком + ТИИ

фпк1сл

3 — 01.02.16 — 11:57

Отладчик мне ничего не покажет, программа завершается в момент Выборка = Запрос.ВыполнитьПакет()[1].Выбрать(); , значит я не узнаю, что её выбивает. В файловом варианте база тоже не запускается, размер слишком большой.

Timon1405

4 — 01.02.16 — 12:04

обновитесь, говорят, на 11.1.10.150 проблема уходит.

Михаил Козлов

5 — 01.02.16 — 12:14

(3) Можно попробовать в консоли удалять из пакета по 1. Или выполнять по 1.

Карупян

6 — 01.02.16 — 12:16

профайлером (или тж) засечь запрос и посмотреть

фпк1сл

7 — 01.02.16 — 15:21

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

фпк1сл

8 — 02.02.16 — 16:16

Обновление не дало результатов. В ТЖ и профайлер смотрел — ничего не понял. Подскажите, может по какому нибудь регистру посмотреть какие нибудь значения подозрительные?

mikecool

9 — 02.02.16 — 16:19

(8) первый запрос из пакета генерит не перевариваемое число — посмотри, какие там числовые поля и попытайся понять, откуда мб такое большое

Timon1405

10 — 02.02.16 — 17:16

(8) поищите большой ресурс «ПостояннаяРазница» в регистре ВыручкаИСебестоимостьПродаж в консоли запросов

Tateossian

11 — 02.02.16 — 18:37

(0) Скорее всего, это происходит где-то при делении, попробуй все такие места явно обработать через ВЫРАЗИТЬ( КАК ЧИСЛО(xx,yy))

Cyberhawk

12 — 02.02.16 — 18:53

ИР тебе в помощь — там и разбивка запроса на подзапросы, и отбор ТЖ по конкретному запросу

фпк1сл

13 — 03.02.16 — 09:26

фпк1сл

14 — 03.02.16 — 12:58

Запрос выполняется с использованием Менеджера временных таблиц

фпк1сл

15 — 03.02.16 — 13:02

Еще глупый вопрос, в запросе выполняется первый пакет. Как мне его найти?

фпк1сл

16 — 05.02.16 — 09:26

Ёпрст

17 — 05.02.16 — 09:35

(16) выкини выразить оттуда

Ёпрст

18 — 05.02.16 — 09:35

и спи спокойно дальше

фпк1сл

19 — 05.02.16 — 09:42

Ёпрст

20 — 05.02.16 — 09:43

ну поставь  КАК ЧИСЛО(15,0)

фпк1сл

21 — 05.02.16 — 09:53

(20) Все так же упрямо выскакивает эта ошибка.

НЕА123

22 — 05.02.16 — 10:00

НЕА123

23 — 05.02.16 — 10:03

вообще, ИМХО, ВЫРАЗИТЬ в Сумма засунуть.

Tateossian

24 — 05.02.16 — 10:09

(16) Выведи в отладке содержимое ВтТаблицаРешений в ТЗ и посмотри, что там за числа.

фпк1сл

25 — 05.02.16 — 10:53

(23) выразил, снова ошибка. (24)  Глазами пробежался по 12к строк, на первый взгляд никакого криминала. Попробую покромсать запрос и выполнять по частям.

фпк1сл

26 — 05.02.16 — 13:11

фпк1сл

27 — 05.02.16 — 13:50

Был неправ, зайдя дальше обнаружил, что умножение «ВтТаблицаРешений.ПостояннаяРазница» и «ПеремещенияСписания.Количество» на какой то итерации дает переполнение, буду двигаться дальше.

фпк1сл

28 — 09.02.16 — 15:52

При проведении документа «Расчет себестоимости» формируются записи регистра накопления «Себестоимость товаров». Так вот за 2014 год все формировалось нормально, а с 2015 в колонке «Стоимость (ПР)» — постоянная разница, только по 2-3 номенклатурам начали появляться и расти огромные числа. Подскажите, из-за чего растет постоянная разница строго по 2 позициям номенклатуры?

<?php // Полная загрузка сервисных книжек, создан 2023-01-05 12:44:55
global $wpdb2;

global $failure;

global $file_hist;
/////  echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;

//подключаемся к базе

$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL

// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке

if (!empty($wpdb2->error))

{

/////   echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';

$failure=TRUE;

wp_die( $wpdb2->error );

}
$m_size_file=0;

$m_mtime_file=0;

$m_comment='';

/////проверка существования файлов выгрузки из 1С

////файл выгрузки сервисных книжек

$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';

if (!file_exists($file_hist))

{

/////   echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';

$m_comment='Файл обмена с сервисными книжками не существует';

$failure=TRUE;

}
/////инициируем таблицу лога

/////если не существует файла то возврат и ничего не делаем

if ($failure){

///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']

/////   echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));

wp_die();

/////    echo '<H2><b>Возврат в начало.</b></H2><br>';

return $failure;

}

/////проверка лога загрузки, что бы не загружать тоже самое

$masiv_data_file=stat($file_hist);   ////передаем в массив свойство файла

$m_size_file=$masiv_data_file[7];    ////получаем размер файла

$m_mtime_file=$masiv_data_file[9];   ////получаем дату модификации файла

////создаем запрос на получение последней удачной загрузки

////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
/////   echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';

/////   echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';

/////   echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';

////препарируем запрос

$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);

$results=$wpdb2->get_results($text_zaprosa);
if ($results)

{   foreach ( $results as $r)

{

////если штамп времени и размер файла совпадают, возврат

if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))

{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));

wp_die();

return $failure;

}

}

}

////если данные новые, пишем в лог запись о начале загрузки

/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу

$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');

$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);

$results=$wpdb2->query($clear_tbl_zap_repl);

/////   echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';

if (empty($results))

{

/////   echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';

//// если очистка не удалась, возврат

$failure=TRUE;

wp_die();

return $failure;

}
////загружаем данные

$table='vin_history';         // Имя таблицы для импорта

//$file_hist Имя CSV файла, откуда берется информация     // (путь от корня web-сервера)

$delim=';';          // Разделитель полей в CSV файле

$enclosed='"';      // Кавычки для содержимого полей

$escaped='

Related Posts
  
 
 
Получение логина и пароля техподдержки 1С из базы
 
Класс для вывода отчета в Excel
 
Счет-фактура для УПП
 
Библиотека классов для создания внешней компоненты 1С на C#
 
Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
 
Прайс-лист с артикулом в отдельной колонке
 

22 Comments

 
 
Плюсану, поскольку сталкивался и лечил такие проблемы в самопальных складских программах.
 
Reply ↓ 
 
 
В данном случае помогло, но это не факт, что всегда поможет.
 Проблема может быть не только с длиной целой части, но и длиной дробной части.
Суть ошибки в том, что во время вычисления — SQL не может преобразовать тип внутри вычисления как правило умножения или деления. Решается не обязательно увеличением разрядности, достаточно ВЫРАЗИТЬ( Значение , ХХ,ХХ) использовать для всех вычисляемых аргументов в том числе внутри скобок. Тогда SQL не занимается самодеятельностью по выбору типа внутри самого вычисления и ошибка не происходит.
 
 
 ВЫРАЗИТЬ(СУММА(ЕСТЬNULL(ВтТаблицаРешений.ПостояннаяРазница, 0) * ЕСТЬNULL(ПеремещенияСписания.Количество, 0)) КАК ЧИСЛО(23, 10))) 

Будет 

ВЫРАЗИТЬ СУММА(ВЫРАЗИТЬ ЕСТЬNULL(ПеремещенияСписания.Количество, 0) КАК ЧИСЛО(23, 10) * ВЫРАЗИТЬ ЕСТЬNULL(ПеремещенияСписания.Количество, 0) КАК ЧИСЛО(23, 10) ) КАК ЧИСЛО(23, 10)

Reply ↓ 




При таких расчетах могут накапливаться и ошибки округления дробной части, здесь это нивелируется десятью знаками после запятой ЧИСЛО(…, 10). Попутно может всплыть проблема сравнения итогов с нулём или константой, так как из-за накопления ошибок округления дробной части выглядеть она будет как -0.0001 < x <0,0001
Reply ↓ 





Коллеги прошу помощи.
 Увеличение разрядности не помогло.
 Ошибка осталась. Кто может помочь?


Ошибка при выполнении обработчика — ‘ОбработкаПроведения’
 по причине:
 {ОбщийМодуль.КорректировкаСтоимостиУчетЗатрат.Модуль(403)}: Ошибка при вызове метода контекста (Выполнить)
 Док.Записать(РежимЗаписиДокумента.Проведение);
 по причине:
 Ошибка выполнения запроса
 по причине:
 Ошибка при выполнении операции над данными:
 Microsoft SQL Server Native Client 11.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
 HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Код такой: 

СУММА(ВЫРАЗИТЬ( | ВЫБОР КОГДА УчетЗатрат.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход) ТОГДА | УчетЗатрат.Стоимость | ИНАЧЕ | 0 | КОНЕЦ | КАК ЧИСЛО(38,10))) КАК Стоимость

Reply ↓ 




(5) Какая конфигурация?
Reply ↓ 




Какая конфигурация?
Reply ↓ 




Управление производственным предприятием, редакция 1.3 (1.3.89.2)
Если есть возможность помочь для более оперативного общения контакты на почту прислать? У меня каждый день на счету.
Reply ↓ 




А если попробовать поменять 

| КАК ЧИСЛО(38,10))) КАК Стоимость

на 

| КАК ЧИСЛО(32,10))) КАК Стоимость

Reply ↓ 





(9) читаем статью, «не хватает знаков ДО запятой», метод решения:
 Если есть строчки ВЫРАЗИТЬ(<ВыбранноеПоле> КАК ЧИСЛО (23,10)) изменяем их на ВЫРАЗИТЬ(<ВыбранноеПоле> КАК ЧИСЛО (25,10)) и радуемся результату.

Читаем (9) и понимаем, что уменьшение знаков до запятой не поможет…
Reply ↓ 




У меня такая же ситуация, только последняя УТ 11.3.3.231 я уже 2 месяца пытаюсь найти в данных проблему. пробовал увеличить разрядность, помогло на два месяца потом опять стала ошибка.
Reply ↓ 




(9) Начинали с 25,10 дошли до 38,10 не помогает. ТЬочнее попробовал 40,10 ругнулась что перебор…
Reply ↓ 




Проблема не решена. Помогите кто может.
Reply ↓ 




Вот и я попал. (37,10) стояло больше двух лет, сейчас не спасло. Решения нет?
Reply ↓ 





Теперь и я) как перевел базу на с 11.1 на 11.3.4… даже не пойму что он там по кругу выполняет,с каждым выполнением отклонение растет. Что это такое вообще? Кто сможет объяснить:
 Дополнительная информация об этапе:
 — Отклонение на текущей итерации: 42 631,8
 — Отклонение на текущей итерации: 24 780
 — Отклонение на текущей итерации: 21 311,8
 — Отклонение на текущей итерации: 17 797,43
 — Отклонение на текущей итерации: 7 800
 — Отклонение на текущей итерации: 20 588,5568513129
 — Отклонение на текущей итерации: 20 588,556851313
 — Отклонение на текущей итерации: 73 530,5601832607
 — Отклонение на текущей итерации: 73 530,5601832608
 — Отклонение на текущей итерации: 262 609,1435116457
 — Отклонение на текущей итерации: 262 609,1435116456
 — Отклонение на текущей итерации: 937 889,7982558771
 — Отклонение на текущей итерации: 937 889,798255877
 — Отклонение на текущей итерации: 3 349 606,4223424179
 — Отклонение на текущей итерации: 3 349 606,422342418
 — Отклонение на текущей итерации: 11 962 880,07979435
 — Отклонение на текущей итерации: 11 962 880,07979435
 — Отклонение на текущей итерации: 42 724 571,71355125
 — Отклонение на текущей итерации: 42 724 571,71355125
 — Отклонение на текущей итерации: 152 587 756,1198258929
 — Отклонение на текущей итерации: 152 587 756,119825893
 — Отклонение на текущей итерации: 544 956 271,8565210464
 — Отклонение на текущей итерации: 544 956 271,8565210464
 — Отклонение на текущей итерации: 1 946 272 399,4875751657
 — Отклонение на текущей итерации: 1 946 272 399,4875751656
 — Отклонение на текущей итерации: 6 950 972 855,3127684486
 — Отклонение на текущей итерации: 6 950 972 855,3127684486
 — Отклонение на текущей итерации: 24 824 903 054,688458745
 — Отклонение на текущей итерации: 24 824 903 054,688458745
 — Отклонение на текущей итерации: 88 660 368 052,4587812321
 — Отклонение на текущей итерации: 88 660 368 052,458781232
 — Отклонение на текущей итерации: 316 644 171 615,9242186857
 Это то что под приложением выдал из состоянии расчета.


А в отладчике последнее значение было таково :
 267 488 214 754 648 642 684 559 809,9800832
 и это на 85 Итерации из 200 как он показывает.

Что тут вообще происходит?)
Reply ↓ 




Такая же проблема. Увеличение разряда не помогает УТ 11.3.4.124
Reply ↓ 




Смысл ошибки можно сформулировать проще.
Запрос не может выразить полученное при исполнении числовое значение, так как в результате получено число больше, чем разрешено условиями запроса.
Если будет конструкция ВЫРАЗИТЬ(1,0) а запросу попадется число 11, то он не сможет выразить его числом от 0 до 9.
Так то у вас все написано правильно, но к сути проблемы докопаться сложно.
Reply ↓ 




(3)

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

 | СУММА(1) КАК Счетчик
Вот этот счетчик и выдал ошибку. Количество записей в самом большом регистре было около 62 млн. записей
и нормально заработала по вашему совету вот так:
 | СУММА(ВЫРАЗИТЬ (1 КАК Число(23,0))) КАК Счетчик
плюсую
Reply ↓ 


 


Такая же проблема. Запрос к регистру ВыручкаИСебестоимостьПродаж показал что каждый документ записан 2 раза один раз с правильным количеством товара и суммы. а второй раз с правильной суммой а количество равное нулю. После отмены проведения и повторно ручного проведения запись документа в этом регистре с нулевым количеством исчезает. Это стандартное поведение или ошибка в системе?
Reply ↓ 


 
 


(3)тоже самое. Пришлось всем полям ВЫРАЗИТЬ писать. Тогда ошибка ушла

СУММА(ВЫРАЗИТЬ( | ВЫБОР КОГДА ВЫРАЗИТЬ(УзлыКорректировкиСтоимостиСписания.Количество КАК ЧИСЛО(23, 10)) <> 0 ТОГДА | ВЫРАЗИТЬ(ТаблицаРешений.Стоимость КАК ЧИСЛО(23, 10)) * | (ВЫБОР КОГДА ВЫРАЗИТЬ(ВложенныйЗапрос.Количество КАК ЧИСЛО(23, 10)) = 0 ТОГДА | ВЫРАЗИТЬ(ВложенныйЗапрос.Стоимость КАК ЧИСЛО(23, 10)) | ИНАЧЕ | ВЫРАЗИТЬ(ВложенныйЗапрос.Количество КАК ЧИСЛО(23, 10)) | КОНЕЦ) / | ВЫРАЗИТЬ(УзлыКорректировкиСтоимостиСписания.Количество КАК ЧИСЛО(23, 10)) | ИНАЧЕ | 0 | КОНЕЦ | КАК ЧИСЛО(23,10))) КАК Стоимость
 Показать

Reply ↓ 




Leave a Comment 
Ваш адрес email не будет опубликован. Обязательные поля помечены *

Ошибка при выполнении операции над данными: Microsoft SQL Server Native Client 10.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.

В работе клиент серверной 1С иногда появляется сообщение:

Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
Microsoft OLE DB Provider for SQL Server: Arithmetic overflow error converting numeric to data type numeric.
HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Если данная ошибка появляется под управлением  MS SQL 2000, то рекомендуется проверить и установить обновление SP до SP4.

Но для SQL 2005 и 2008 появление такой ошибки не решается обновлением сервиспака.

Вообще появление указанной ошибки вызвано ошибкой в MS SQL при выполнении операции округления, например:

. касательно 1С и запросов выполняемых в ней, указанная ошибка может появляться при выполнении команды: ВЫРАЗИТЬ(ЕСТЬNULL(ВремяПоГрафикуВЧасахНорма, 0) КАК ЧИСЛО(5, 2)) КАК WorkingHours

Если в качестве операнда будет число со значением после запятой .5, в этом случае SQL считает/разбирает значение как литерал х.5 и преобразует к данным типа Numeric(2,1). Функция ROUND (округления)  отрабытывает правильно получая округленный результат и затем пытается сохранить как данные в формате Numeric(2,1), что не правильно и мы получаем сообщение «arithmetic overflow».

Если у Вас возникает такая ошибка, то попробуете использвать преобразование:

ВЫРАЗИТЬ(ЕСТЬNULL(ВремяПоГрафикуВЧасахНорма, 0) КАК ЧИСЛО(  {НОВОЕ значение} , 2)) КАК WorkingHours

, ГДЕ

     {НОВОЕ значение} — Это увеличенное на один (несколько) разряд значение, в это случае ошибки не будет возникать.

Автор решения Александр Шарафан

Описание ошибки:
Случилось, что в один момент отчет, который несколько лет работал без ошибок, при очередном формировании выдал ошибку: {ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Форма(480)}: Ошибка при вызове метода контекста (Выполнить)
мРезЗапроса = ОбъектЗапрос.Выполнить();
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
Microsoft SQL Server Native Client 10.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
HRESULT=80004005, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Найденные решения:

Исчерпывающее описание ошибки дало понять, что проблема скрывается в теле запроса. А формулировка «ошибка арифметического переполнения при преобразовании numeric к типу данных numeric» подсказывала, что проблема с числовыми данными, собираемых запросом. Внимательно присмотревшись к тексту запроса а так же благодаря заметке на сайте helpf.pro было выдвинуто предположение, что числа, получаемые запросом в результате арифметической операции, и приводимые с помощью функции языка запросов к числу с пятью знаками до запятой, стали длинее, чем указанная длина. 

Увеличение длины знаков до запятой решило проблему.

Оцените, помогло ли Вам предоставленное описание решения ошибки?

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

17-10-2018

Журавлев А.С.
(azhur-c.ru)