想讓資訊聊天機器人有溫度，有個重要的關鍵就是聽懂使用者問題(Language Understanding)，如果自己寫資訊問答機器人的程式，我們可能要寫很多關鍵字的解析才能判斷好客戶的意圖，經過持續的回饋及除錯，最後才能聰明的回答出設計好的答案。微軟Azure上有一個認知服務(Cognitive Service)可以讓這件事變得簡單，服務的名稱是QnA Maker，今年5月已經是GA(General availability)版本了，介紹的網頁上說，只要數分鐘就能從FAQ到BOT，要串接既有系統的網頁或是加入即時通訊合作軟體也很方便，來試試From FAQ to Bot in minutes。
明明同事用了using來確保區塊結束時會呼叫Dispose()作到自動釋放資源，但還是被源碼檢測工具fortify舉報。呼~~來解題。
同事最近想在新版本的SQL Server追蹤異常的SQL登入(SQL Login Fail)，不過同事在舊版本SQL Server都用SQL Trace，來推薦同事改用擴充事件(Extended Event)追蹤登入失敗的錯誤碼18456。
同事的專案因為時間長，累積超過上千個Jira issues，每到了專案會議前要整理issues狀態作統計，就會收到客戶對於下載上限1,000筆限制的抱怨，來幫DevOps Team解題。
最近在新的專案CI流程內開始加入聲納(SonarQube)來進行程式碼分析，希望能獲得海面下更多有關程式碼品質度量的指標。從Jenkins以Command Line執行大型程式庫掃描時，卻出現了記憶體不足的異常，不過小型程式庫則可以正常完成掃描。
進入疑難排解階段，我們先確認伺服器記憶體是充足無虞的，不過觀察掃描程式在大型程式庫執行時，只吃到1G多一點就出現記憶體不足的異常。筆記解題方法。
最近參與了同事專案的討論，在專案文件庫中，發現年輕同事曾遇到MSTest整合進CI Server的問題，CI Server加裝的MSTest Plugin以Command Line(CLI)跑測試時，出現了"沒有要執行的測試"(No tests to execute.)訊息，先前自己也遇到，來筆記這個問題。
上一篇先筆記Realtime的評分預存程序sp_rxPredict給同事看，這篇來筆記SQL 2017推出的原生(Native)述詞- PREDICT，更直覺簡單的寫法。
測試環境訓練好模型，正式上場預測前，我們會需要再建立一段R的評分程式碼，並且以字串的方式包在外部預存程序介面內(sp_execute_external_script)，透過讀取序列化後的模型在R的環境執行預測。
但這樣的方式還是多了點麻煩，第一個是程式的可讀性，第二個則是正式環境的資料庫必需依賴R的環境作運算，要解決這個問題，也許可以試試看SQL2016就推出的Realtime評分(sp_rxPredict)或是SQL 2017推出的原生(Native)評分方式，更即時更原生的方式執行。
在.NET程式透過WebRequest來建立HTTPS或FTPS連線時，有時攻城獅可能因為無法確認憑證有效性，寫了不理會憑證是否有效的程式碼來讓程式正常運作，上線前，送到源碼檢測健康檢查時，就會被列出來*標示Critical的風險，來還技術債吧。
為了避免SQL Server與AP伺服器傳輸時的內容被攔截竊取後容易解析，我們可以採用加密的傳輸通道，一來可以增加傳輸封包安全性，二來也避免源碼檢測工具打小報告。
以前都是在DB Server手動裝憑證，然後DB匯出，AP伺服器匯入再設定連線字串啟用加密，才能啟用加密連線(大誤)。最近和同事討論，意外發現，即使沒有額外處理憑證，單只要AP連線字串加上TrustServerCertificate=true;Encrypt=true，實際連線時，SQL會自動產生憑證，重要的TDS封包就被加密了，而且專案中的組態檔還可以通過源碼檢測的盤查。
由於工作的關係，時常需要和源碼檢測工具神鬼交鋒一下，持續整合之路上也有源碼檢測的探險，累積幾家客戶的要求，半數是以Fortify SCA(Source Code Analyzer)作為檢測工具，也寫筆記留給同事及以後的自己參考。
上一篇筆記了Ad hoc使用暫存資料表(#Table)引發的重新編譯(Recompilations)，過量的重新編譯會增加CPU的負擔，換個方式執行SQL，如果預存程序(Stored Procedure)中使用暫存資料表(#TABLE)會不會造成每次執行就重新編譯?
我們有時在SQL Server監控CPU的效能時，會額外多觀察每秒陳述式重新編譯次數(SQL Re-Compilations/sec)的效能計數，透過收集的資訊及後續的調校來降低生產環境出現大量的重新編譯。
最近專案裡，奉旨把SQL程式也加入持續整合(CI)的測試項目內，在掃描SQL程式時發現幾位成員在頻繁的線上交易語法中，使用了少許的暫存資料表(#TABLE)，解釋給同事聽，順便筆記可能引發的大量持續不斷的重新編譯。
SQL Server 2017推出STRING_AGG 字串集合的串接函式，但限制是SQL2017的版本。上個月重新加入一個大型專案中，專案的版本要求是SQL 2016，Code Review時發現同事改用For Xml Path再Distinct的替代，T-SQL閱讀起來多了點複雜，捲手來救援T-SQL程式的可讀性。
再次和Fortify神鬼交鋒(新的Rule Pack上市)，Fortify SCA新檢測出Path Manipulation及XML External Entity Injection(Input Validation and Representation, Data Flow)，來筆記這次的修正。
最近同事的程式在兩個專案陸續發生SQLCLR無法載入檔案或組件問題，一個發生在測試環境因為備份還原的場景，另一個則是正式環境突發性的發生，自己太少用SQL CLR了，來試試解題然後筆記。
最近同事在匯入大量資料常碰到SQL Msg 8152, String or binary data would be truncated，中文訊息是是字串或二進位資料會被截斷。
除了找出有問題的資料行與列或是將欄位型別改為varchar(max)兩個方法外，能不能在SQL裡自動截斷過長的資料，不要讓SQL出現錯誤?
最近在駐點的客戶端遇到一個很神奇的問題，剛匯入大筆資料的隔天(50%以上的異動量)，同事有一支程式跑了很久都沒執行完，想辦法和AP人員清理舊資料、加索引，更新統計值後，程式瞬間秒殺，但過沒多久，同事另一支類似功能的程式又塞住，這次即使更新統計值、清除plan cache 、Recompile SQL都沒效。
在SQL2016以前，當自動更新統計值選項啟用後，20% + 500筆是一般資料表觸發重新統計的門檻(RT)，資料異動累積量達標後，第一個使用統計值的交易會先更新統計值才完成編譯後再實際執行，在某些資料表比較胖的時候，也許先更新統計值再查詢資料的順序可能就會影響OLTP個案交易的執行效能，此時可以試試非同步更新統計值。
上一篇我們注意到統計值(Statistics)不夠即時可能造成SQL Optimizer無法產生最佳的執行計畫，另外也發現自動更新統計值並不是發生在資料更新的同時，而是發生在更新後第一次使用統計值的SQL指令作編譯前，那麼多少的異動量條件會觸發統計值更新?
