今天的事件
是發生在更新DB資料時
回傳的更新筆數異常問題
一段看似再尋常不過的Sql
背後竟然還藏著看不見的玄機

使用的是熟到不能再熟的Dapper
用Sql直接去update資料
Where條件是用GUID
(什麼是GUID)

以三層式的架構來說
在Repository層的方法
我通常是回傳更新筆數

然後在Service層
只要判斷更新筆數大於0
就是更新成功

寫完API後，看到資料正常
原本就要繼續寫下一個功能
突然心血來潮
想確定一下Sql有沒有錯

下中斷點去看一下更新筆數
赫然發現更新筆數竟然是2
而不是1筆
嚇到從椅子上跳起來

不可能GUID這麼簡單就相撞了吧
第一個動作就是用GUID去查詢DB
的確只有一筆
而且資料也有更新
看起來是滿正常的

不死心又執行了一次
Dapper還是原封不動的告訴你
異動了兩筆資料

再看一下程式碼
就是一句再普通不過的 connection.ExecuteAsync
也沒有對回傳值加加減減
想不透另外一筆異動的資料在哪

原本想說資料正確
那就算了
看看時間已經5:50
準備打卡下班時

突然靈光一閃
Sql回傳的資料是該次傳輸的結果
所以那個異動筆數
有可能是來自另外一張Table

合理推測
原本的Table有埋Trigger
異動時觸發寫資料到另外一張Log Table
所以異動筆數才會是2

仔細看一下DB還真的有另外一張表
上面的資料
完完全全就是我剛剛Update的內容

難怪說少用Tirgger
錯怪Dapper和GUID了
結案下班