姜勾 的隨手記錄冊

範例一:

UPDATE 資料表

--SET 資料欄位 =  '2018/5/10 10:16'      --這一行是可以執行的

SET 資料欄位 ='‎2018/5/10 10:16'     --跑這一行卻不行跑

where id = '123'

//已經確認過資料庫的欄位 資料內容 資料正常

可是如果我改成上面那行執行 卻變成可以執行。

範例二:

UPDATE 資料表

SET 資料欄位 =  '2018/5/10 10:16'      --這一行是可以執行的

--SET 資料欄位 ='‎2018/5/10 10:16'     --跑這一行卻不行跑

where id = '123'

↑執行範例二的第2行SQL碼卻成功?

↓ 順順利利的修改成功????

(1 個資料列受到影響)

??

?

??

??

黑人問號

我相信很多人說  哎呀  一定是因為我日期隔是用錯 要用-啦  用-!

好 我也想過 我也試過

修改範例一:

UPDATE 資料表

--SET 資料欄位 =  '2018/5/10 10:16'      --這一行是可以執行的

SET 資料欄位 ='‎2018-5-10 10:16'     --跑這一行卻不行跑

where id = '123'

我改成-了  一執行:

從字元字串轉換成日期及/或時間時，轉換失敗。

為了這一行研究了一個早上

以下解答:

問題出在那段雙引號中間的值!!

很多人看了好幾眼 奇怪明明就長一樣 哪裡有問題?

如果家中或公司中的SQL是2008年的 貼上去會一目了然

可是不一定每個人都是2008的

(我是2012年的) 

而2012年的貼上去執行會跟我一樣

那問題出在哪裡??

==========================不想看前面的解答在下方==========================

檢查雙引號中的值

用滑鼠點一下第一個雙引號前面

慢慢往右邊按 慢慢看 慢慢數

會發現怎麼在第一個引號跟2018的2前面多停留一個字元?

只要把這個"隱藏字元"刪除了  執行 就正常了

(1 個資料列受到影響)

==========================解答分隔線==========================

如此微不足道的問題，為什麼會發現?

因為請求主管求救的時候，因為主管是2008年的SQL server 所以一貼上去 隱藏字元看的一清二楚

所以才會找到這個發生原因，至於怎麼解決這個問題可能還要再想想。

(下台一鞠躬)