Сбой нескольких вставок SQL Server, но остаются незамеченными в Mule

#sql-server #mule

#sql-server #mule

Вопрос:

Когда я запускаю несколько запросов insert вместе в базу данных SQL Server с помощью Mule, если вторая вставка завершается неудачно, она не вставляет строку и не отображается как сбой в потоке или журналах.

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

После некоторого расследования выясняется, что Mule примет результат первой вставки SQL в качестве кода возврата, независимо от того, сработали ли результирующие вставки SQL или нет.

Я попытался изменить это на МАССОВОЕ ОБНОВЛЕНИЕ, но я все равно получаю тот же результат.

Редактировать — код включен для примера вставки. 4 инструкции insert, 3 будут успешными, 1 завершится неудачно, но просто будет передан как успешный —

 insert into highjump.t_import_order(status,idoc_number,datetime_created,datetime_processed,error_message,wh_id,order_number,order_type,order_subtype,is_vas,is_shrinkwrap,is_mhe_packhold,is_consolidation,is_nonmhe_packhold,is_full_case,ship_to_account,ship_to_name,ship_to_address1,ship_to_address2,ship_to_address3,ship_to_city,ship_to_state,ship_to_zip,ship_to_country,sold_to_account,sold_to_name,sold_to_address1,sold_to_address2,sold_to_address3,sold_to_city,sold_to_state,sold_to_zip,telephone_number,sold_to_country,stock_pool,discount,box_type,service_level,telephone_number_alt,dest_type,carrier_code,route_code,inv_cat,cust_order_date,expected_ship_date,expected_delivery_date,dsv_tracking_number,postage_cost,carton_contents_type,unit_total,total_before_discount,total_after_discount,carton_cubing_indicator,req_proof_of_delivery,payment_type,is_cms,carrier_override_type,sales_org,pack_note_preference,shipper_order_id,master_order_number,currency_code,store_code,order_method,dsv_reference,email_address,ship_complete_flag,replen_type,carton_content_flags,partner_profile) values 
(N'Z',N'0000000629673252','2019-04-12 09:57:38','2019-04-12 09:57:38',null,N'WST',N'6412210697',N'MCR',N'STD EU',0,0,0,0,0,0,N'MCRSHPTODE',N'Dave Smith',
N'888415936',N'PACKSTATION 432',null,N'Koettgenstr. 8',null,N'13629',N'DE',N'MCRSLDTODE',N'MCR SOLD TO DE',N'High St.',null,null,N'Street',null,N'BA330YA',null,
N'GB',N'MC01',0,N'BAG',N'10',null,N'RE','',N'01',N'W','2019-03-29 11:38:13','2019-03-29 11:38:13','2019-03-29 11:38:13',null,0,N'001',2,null,null,'91',1,
N'MCR CON - UK Orders',1,'1',null,N'N',null,N'623611121','GBP',null,null,null,N'Smith@arcor.com',null,'R',N'F', N'WWMULESFTH');

insert into highjump.t_import_order_cms 
(order_id,delivery_from_date,delivery_to_date,pin_number,cms_location,cms_delivery_endpoint,cms_comm_preference,cms_dont_despatch_before,cms_market,cms_brand,is_gift,gift_message,loyalty_number,cms_dest_type,cms_time_delivery,cms_day_delivery,cms_customer_type,carrier_service_name,special_instructions) values ((select top(1) order_id from highjump.t_import_order where order_number='6412210697'),'2019-04-03','2019-04-03',null,N'432',N'PACKSTATIONPACKSTATION',null,null,null,N'CLA',null,null,null,N'PUDO',null,null,null,null,null);

insert into highjump.t_import_order_detail 
(order_id,line_number,item_number,order_quantity,customer_item_number,ratio_pack_group,is_ratio_pack,ratio_pack_qty,uom,retail_price,freight_class,sales_order_number,customer_order_number,dsv_price_discount,customer_item_colour,price_paid,currency_code,customer_item_size) 
values ((select top(1) order_id from highjump.t_import_order where order_number='6412210697'),00010,'261392464080',1.000,null,null,null,null,'U','0.0',null,N'623611121000010',N'623611121',null,null,99.95,null,null);

insert into highjump.t_import_order_detail (order_id,line_number,item_number,order_quantity,customer_item_number,ratio_pack_group,is_ratio_pack,ratio_pack_qty,uom,retail_price,freight_class,sales_order_number,customer_order_number,dsv_price_discount,customer_item_colour,price_paid,currency_code,customer_item_size) 
values ((select top(1) order_id from highjump.t_import_order where order_number='6412210697'),00020,'261394324080',1.000,null,null,null,null,'U','0.0',null,N'623611121000020',N'623611121',null,null,89.95,null,null);
  

Комментарии:

1. Массового ОБНОВЛЕНИЯ нет. Существует МАССОВАЯ ВСТАВКА, которая работает с файлами. Вы не опубликовали никакого кода (Java или SQL) и не объяснили, что вы делаете, поэтому невозможно сказать, почему он поглощает ошибки. Если вы хотите, чтобы несколько операторов в сценарии SQL выполнялись как одна транзакция, вам придется явно использовать BEGIN TRAN/COMMINT TRAN etc . Если вы хотите контролировать то, что возвращается, вам придется использовать TRY CATCH

2. Извиняюсь за отсутствие кода. Сейчас обновится.

3. Что именно означает «1 завершится ошибкой»? И откуда вы это знаете?

Ответ №1:

Структурно эти SQL-запросы кажутся нормальными. Мне непонятно, почему и как любой из этих запросов завершится неудачно (или не будет вставлять какие-либо данные). Насколько я вижу, все должно работать нормально.

В конце концов, когда вы выполняете эти запросы в среде SQL Server Management Studio, все они должны возвращать значение 1:

 select count(*) from highjump.t_import_order where order_number = '6412210697';
select count(*) from highjump.t_import_order_cms where order_id = (select top (1) order_id from highjump.t_import_order where order_number = '6412210697');
select count(*) from highjump.t_import_order_detail where line_number = 10 and order_id = (select top (1) order_id from highjump.t_import_order where order_number = '6412210697');
select count(*) from highjump.t_import_order_detail where line_number = 20 and order_id = (select top (1) order_id from highjump.t_import_order where order_number = '6412210697');
  

Комментарии:

1. Структурно запросы в порядке, но в таблице ‘import_order_cms’ столбец delivery_endpoint имеет ограничение 9, которое превышается при вставке туда ‘PACKSTATION’.

2. Ага. Я вижу. Это не может быть получено из предоставленной вами информации. Итак, вы определили проблему. Что ж, исправление этого, возможно, еще одна проблема. Если вы являетесь тем (или одним из людей), кто отвечает за проектирование и обслуживание базы данных, вы можете решить увеличить длину этого столбца. Или вы можете решить использовать сокращение. Или вы можете связаться с разработчиками системы, предоставить им свои отзывы и попросить их расширить это поле. Боюсь, я мало чем могу вам здесь помочь. Я понятия не имею, какие требования, варианты использования, истории пользователей и т. Д. Могут быть нарушены при изменении этого поля.

Ответ №2:

Используйте транзакцию для выполнения нескольких запросов на вставку. В нескольких SQL-запросах предположим, что один запрос выдает ошибку, тогда он будет откат.

 BEGIN TRY
    BEGIN TRANSACTION
       //Here you will write multiple insert/delete/update queries 
    COMMIT
END TRY
BEGIN CATCH
    ROLLBACK
END CATCH
  

Комментарии:

1. И как это поможет? OP ясно (возможно, ошибочно, но мы не можем знать), что результатом выполнения запроса является «успех», а не «ошибка». В таком случае единственным логическим путем является фиксация транзакции, которая будет иметь тот же эффект, что и отказ от использования какой-либо транзакции.

2. Это работает, но это просто откатит всю транзакцию (все вставки), но не отобразится как сбой в журналах консоли mulesoft. Казалось бы, когда все 4 выполняются вместе, код причины возвращается из результата первой вставки и игнорирует остальные.

3. Внутри блока catch вы можете записать сведения об исключении в file или любую таблицу для получения сведений о журнале ошибок.