這篇文章之後，我應該不會再針對 ansi_padding 這個系列再PO文。 因為，感覺上我講的已經開始重複鬼打牆了，再說也還是一樣的事。 當然啦! 還是歡迎大家指教，我會聽，但不會再寫。:) 事情的起因是ronlee543問到為什麼 ansi_padding 一定要是ON，這 樣不是會多一些不必要的空白嗎? TeemingVoid: 預設為 ON 比較有彈性，要不要空白都順我們的意。 trueQoo: 這個選項是「向前相容」。 trueQoo: 讓 char 與 varchar 有別區別。 Adonisy: 所以 ansi_padding 之前是為了向前相容無誤, 但以後拿 掉也很正常,只是不用期待他何時拿掉 說實在的，我想給原PO一個拍拍，因為，我們說了半天，都沒有回答 他的問題: 究竟有什麼理由，ansi_padding 一定不可以是 OFF 呢? 我贊成 ansi_padding 設為 ON，所以說了一個使用上的理由，自我 說服：好吧！就聽微軟的，反正這樣比較好。 trueQoo說出 ansi_padding 出現的緣由。但我認為「前向相容」絕 對不是這個選項該退出江湖的原因，因為 ansi_padding 跟其他選項 不同，設為 OFF，建立的那個資料表就是會砍掉結尾空白，就算你設 回ON，那個表還是會砍掉結尾空白。偏偏這個選項又這麼多年了，所 以如果我們重視「前向相容」，反而應該留著這個選項。 Adonisy的回文內容，在我的理解，是說這個選項既然有生，自然有滅， 完成階段任務後，隨時可以除役。但是，我還是認為這個選項在完成 其階段任務的期間，恐怕也創造了一些「歷史共業」。 在我認為，上述事項都不足以是 ansi_* 非死不可的關鍵。我們三人， 沒有一人提出一個無可反駁的原因，說明為什麼 ansi_padding 一定只 能是 ON。 究竟有什麼重大的危害，所以 ansi_padding 一定要是 ON? 如果有， 不會過了十多年都沒事。如果沒有，為什麼沒事要改成只能 ON? 經過這幾天，我反而想問跟ronlee543一樣的問題，為什麼ansi_padding 非死不可? 想設成 OFF 的，就用 OFF，免去 ASP 年代老是 string too long... truncated 的錯誤訊息。想設成 ON 的，就用 ON 啊! 各人造 業各人擔。 有什麼理由為什麼 ansi_padding 一定只能是 ON 呢? 我會聽，但不會再說了，謝謝大家喔! ^_^ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.41.100.79 ※ 編輯: TeemingVoid 來自: 114.41.100.79 (02/18 20:18)