手工RUN:Import Delivery Lines後可能造成WSH_DELIVERY_DETAILS中資料重復
查核是否有重復資料,我用的SQL是
select a.*
from (
select l.org_id,h.order_number,h.header_id,
l.line_id,l.ordered_quantity,
(select sum(d.REQUESTED_QUANTITY)
from wsh_delivery_details d
where d.source_line_id=l.line_id
and d.source_header_id=l.header_id
and d.source_code='OE'
) d_qty
-- into &orgid,&order_no,&headerid,&lineid,&ordqty,&wshqty
from oe_order_lines_all l,oe_order_headers_all h
where l.org_id=:ORG_ID
and h.header_id=l.header_id
and l.open_flag='Y'
) a
where a.ordered_quantity<>d_qty
--我是用QTY來比較的
--依上面SQL出來如有記錄,則用LINE_ID作條件用下面的SQL檢視.
select l.line_id,l.ordered_item,l.ordered_quantity,l.CANCELLED_QUANTITY, d.REQUESTED_QUANTITY,
d.released_status,d.CREATED_BY,d.CREATION_DATE,
d.*
from wsh_delivery_details d,oe_order_lines_all l
where l.line_id in (6738108,6738118)
and l.line_id=d.source_line_id
and d.source_code='OE'
--有重復資料時,一般d.released_status會不同一個R,一個N.我都是將N的作CANCELLED(SQL如下)
update wsh_delivery_details
set SRC_REQUESTED_QUANTITY=0,
cancelled_quantity=SRC_REQUESTED_QUANTITY,
requested_quantity=0,
RELEASED_STATUS='D',
DATE_SCHEDULED=null
where delivery_detail_id in (6765925,6766661) --=6597192
commit --最後提交
[@more@]
select a.*
from (
select l.org_id,h.order_number,h.header_id,
l.line_id,l.ordered_quantity,
(select sum(d.REQUESTED_QUANTITY)
from wsh_delivery_details d
where d.source_line_id=l.line_id
and d.source_header_id=l.header_id
and d.source_code='OE'
) d_qty
-- into &orgid,&order_no,&headerid,&lineid,&ordqty,&wshqty
from oe_order_lines_all l,oe_order_headers_all h
where l.org_id=801
and h.header_id=l.header_id
and l.open_flag='Y'
) a
where a.ordered_quantity<>d_qty
select l.line_id,l.ordered_item,l.ordered_quantity,l.CANCELLED_QUANTITY, d.REQUESTED_QUANTITY,
d.released_status,d.CREATED_BY,d.CREATION_DATE,
d.*
from wsh_delivery_details d,oe_order_lines_all l
where l.line_id in (6738108,6738118)
and l.line_id=d.source_line_id
and d.source_code='OE'
update wsh_delivery_details
set SRC_REQUESTED_QUANTITY=0,
cancelled_quantity=SRC_REQUESTED_QUANTITY,
requested_quantity=0,
RELEASED_STATUS='D',
DATE_SCHEDULED=null
where delivery_detail_id in (6765925,6766661) --=6597192
commit
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/92289/viewspace-1038966/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 達夢資料庫手工恢復相關命令資料庫
- Leaflet入門:新增點線面並匯入GeoJSON資料|Tutorial of Leaflet: Adding Points, Lines, Polygons and Import GeoJSON FileJSONGoImport
- 【資料庫資料恢復】突然斷電造成Syabse資料庫無法啟動的資料恢復案例資料庫資料恢復
- 【資料庫資料恢復】ORACLE常見資料災難&資料恢復可能性資料庫資料恢復Oracle
- 【vsan資料恢復】vsan資料重構失敗的資料恢復案例資料恢復
- 分析提取出重組raid所需的資料後使用北亞自研資料恢復AI資料恢復
- 重構smart-importImport
- 執行在容器中Postgres資料庫資料損壞後如何恢復?資料庫
- 資料洩露的12個可能後果
- [20190104]bbed手工插入資料.txt
- oracle asm 資料塊重構恢復OracleASM
- 資料庫資料恢復-ORACLE資料庫的常見故障&各種故障下的資料恢復可能性資料庫資料恢復Oracle
- 【伺服器資料恢復】掉線硬碟重新上線同步資料被中斷後資料丟失的資料恢復伺服器資料恢復硬碟
- 儘可能地恢復織夢CMS的資料庫資料庫
- 【北亞資料恢復】伺服器中Raid5磁碟陣列重建後資料丟失的資料恢復資料恢復伺服器AI陣列
- 【北亞資料恢復】企業如何避免伺服器資料丟失造成重大損失?資料恢復伺服器
- 2.4.10 Step 9:手工建立資料庫資料庫
- 伺服器資料恢復-UNIX類檔案系統資料災難的資料恢復可能性分析伺服器資料恢復
- Telephone Lines S
- 《自然》:研究發現化療可能造成精子突變 甚至影響後代基因
- 【儲存資料恢復案例】儲存斷電後無法成功重啟,虛擬機器無法啟動-資料恢復資料恢復虛擬機
- 復刻或重製老遊戲,可能並沒有想象中那麼簡單遊戲
- vsan資料恢復-vsan進行資料重構及遷移過程中斷電導致硬碟離線故障的資料恢復資料恢復硬碟
- 甩手工具箱:如何打造成功的促銷活動
- 【伺服器資料恢復案例解讀】伺服器突然崩潰,重啟後無法進入系統故障的資料恢復伺服器資料恢復
- Kafka SimpleStringSchema 可能會造成空指標異常Kafka指標
- 【伺服器資料恢復】多次異常斷電後儲存執行中突然崩潰的資料恢復伺服器資料恢復
- 電腦硬碟資料丟失後怎麼恢復?硬碟資料恢復技巧教程硬碟資料恢復
- Mysql資料庫delete刪除後資料恢復報告MySql資料庫delete資料恢復
- 資料庫資料恢復—SQLserver資料庫中勒索病毒被加密怎麼恢復資料?資料庫資料恢復SQLServer加密
- Mongodb資料庫誤刪後的恢復MongoDB資料庫
- git reset --hard 操作後的資料恢復Git資料恢復
- chkdsk 後資料丟失的恢復方法
- 研究發現22%的AI生成醫療建議可能導致死亡或造成嚴重傷害AI
- MySQL Shell import_table資料匯入MySqlImport
- sqlserver中刪除重複資料SQLServer
- 【伺服器資料恢復】RAID5重建初始化失敗,資料丟失的資料恢復伺服器資料恢復AI
- 徹底搞懂Python 中的 import 與 from importPythonImport
- idea編輯器中 This document contents very long lines..........Idea