同事在新客戶端佈署測試網站，部分電腦連線時發現網站外觀與預期不同(破版)，肉眼可見的功能表消失、位置跑掉等問題油然而生，但透過網站本機或是其它伺服器端開啟網站卻很正常。客戶IT人員很有經驗的說明是瀏覽器與網站間的相容性模式所造成，由於客戶端還有許多舊版IE才能瀏覽的網站，因此ie瀏覽器預設的相容性模式是開啟的。
除了在Client端將網站新增到相容性檢視清單 或 取消[在相容性檢視下顯示內部網路網站]的勾選（因為user多），來試試從IIS網站(伺服器端)來解決問題。
昨天留在駐點辦公室驗證需求，客戶端的程式開發人員來討論一個主管交辦的任務，產表時，要多幾個下拉欄位給user選，而且希望透過程式動態帶出下拉選單的值，趁女兒睡著，來試試用NPOI實現從後端作Excel資料驗證。
星期日晚上來寫blog，上一篇先解決了列印時的表頭資訊，這一篇來解決同事其他的需求:依照資料筆數分頁列印、小計等。順邊筆記2的十次方分頁問題。
同事剛加入急急如律令的專案幫忙開發報表，使用者有一項需求是列印報表時，表頭要出現頁數、標題、欄位名稱等，專案中使用的是NPOI，之前自己參加專案時都是同事寫好了元件，對NPOI操作不太熟悉，這次捲起袖子來試試。
最近在駐點的客戶端遇到一個很神奇的問題，剛匯入大筆資料的隔天(50%以上的異動量)，同事有一支程式跑了很久都沒執行完，想辦法和AP人員清理舊資料、加索引，更新統計值後，程式瞬間秒殺，但過沒多久，同事另一支類似功能的程式又塞住，這次即使更新統計值、清除plan cache 、Recompile SQL都沒效。
在SQL2016以前，當自動更新統計值選項啟用後，20% + 500筆是一般資料表觸發重新統計的門檻(RT)，資料異動累積量達標後，第一個使用統計值的交易會先更新統計值才完成編譯後再實際執行，在某些資料表比較胖的時候，也許先更新統計值再查詢資料的順序可能就會影響OLTP個案交易的執行效能，此時可以試試非同步更新統計值。
上一篇我們注意到統計值(Statistics)不夠即時可能造成SQL Optimizer無法產生最佳的執行計畫，另外也發現自動更新統計值並不是發生在資料更新的同時，而是發生在更新後第一次使用統計值的SQL指令作編譯前，那麼多少的異動量條件會觸發統計值更新?
去年底上線前的一次系統轉換演練，碰到某支轉檔SQL執行變慢，表象是執行計畫改變(plan change)，進一步找原因則發現是不太即時的統計值造成Query Optimizer產生較差的執行計畫。
去年底的跨年，終於把駐點14個月的專案上線了，這個客戶和幾年前上線的客戶最近都遇上統計值影響效能，來記錄問題，順便重修統計值(Statistics)。
統計值是描述欄位值與索引欄位值的分佈統計，也是SQL Query Optimizer進行基數估計(cardinality estimate)的分析來源，透過基數預估，進而決策出優秀的執行計畫來擷取或更新資料。
統計值統治的範圍包含一般資料表、#臨時資料表以及幾個新的企業版本@資料表變數都有統計值。
資料庫因為胖胖的讓公司測試環境很擠，但想透過上個月月初備份檔(.bak)還原幾個資料表來比較測試結果，測試環境的空間及資源都不足，當初也沒把幾個資料表放在指定檔案群組(File Group)，這次不能使用還原檔案群組招式。
來筆記付費的Third party工具，透過ApexSQL Recover工具，不需要還原整個資料庫就能還原單一資料表。
在SQL 2016以前，Insert Into Select一直都只能用一條執行緒執行資料表插入，SQL Server先在2014版本時優化了Select Into新增了平行，到了SQL 2016版本也優化了Insert Into Select，只要資料庫相容性層級設置為130(SQL 2016)，搭配WITH (TABLOCK)的Table Hint，我們也可以在非叢集索引資料表平行執行Insert Into Select了。來筆記實驗過程。
在SQL Server 2014以前，Select Into一直都只能用一條執行緒執行資料表插入，即使Into到tempdb也是；不過到了SQL 2014之後，只要資料庫相容性層級設置為120(SQL 2014)就可以在成本大的語法平行執行Select Into了。來筆記實驗過程。
維護SQL2000的系統要作資料移轉時，除了寫AP程式或是用ETL工具轉換資料，其實也能繼續用舊機卸離 x 新機附加直接移轉user databse的資料庫檔案。
上一篇實驗了移轉SQL2005的檔案到SQL2017，實驗結果可以直升；這次實驗SQL2000的user database，事前從ms blog的討論發現需要先轉到SQL2005或SQL2008，再跳到SQL2017。
這次不用升級SQL Instance版本(就地升級)，但要移轉幾個User Database到新機器上新版本的SQL Instance。在學校曾上過SQL 2000的課，幾年前重新接觸SQL Server，已經是SQL 2008R2 ，幾年下來慢慢也從SQL 2008移轉到2012/2014/2016，好在SQL資料庫的相容性，每次都很順利，不過這次是自己沒使用過的SQL 2005，試試SQL2005到SQL2017，一個12生肖的距離。
同事報案在Server2012R2環境測試Windows Form程式指定在背景下(session 0)執行時看不到UI，已經確認互動偵測服務(Interactive Services Detection)啟動，Windows排程啟動程式後，在工作管理員(Task manager)也在Background process看到程式閃耀著，但切到背景下(session 0)查看UI時卻看不到?
以前只有寫判斷銀行營業、關帳日、計息起息結息日的，趁中午吃點心來補同事們需要的函數(判斷月初、月底、季初、季底、年初、年底)。
很開心在上周末下班前一起和客戶端的.NET架構師解決了開發人員的NHibernate交易使用問題，好久沒用Hibernate這個老牌ORM武器了，連開保險上膛都很生疏，來筆記Hibernate問題解決，順便回憶。
客戶端開發人員的問題是在同一個Transaction中，有三個資料庫的操作，但後面的操作無法讀取到同一個Transaction先前寫入的資料。
經過上一篇的實驗，磁碟資料表(Disk-based table)啟用讀取認可快照(RCSI)或是快照隔離(Snapshot isolation)都能到使用資料列版本讀取到前一版的資料而避免封鎖(blocked)，特別兩者在處理”資料一致性的層級”以及”交易發生衝突的處理上”有些不同；那麼到了記憶體資料表(Memory-optimized table)?
SQL Server在磁碟資料表(Disk-Base)提供了兩種與快照有關的樂觀鎖定機制: RCSI(Read Committed Snapshot Isolation)及Snapshot Isolation，他們都是減少查詢交易被封鎖的武器之一，當資料被其他交易更新時，這兩種機制都可以透過Tempdb加上row version查詢到資料的前一版，讓交易免於被封鎖(blocked)的命運。明晚要參加SQL Pass，Rico大的主題是進擊的In-Memory OLTP，學習記憶體資料表交易前，先來預習傳統磁碟資料表在這兩種機制下的查詢一致性。
想移除歷史交易資料時，很直覺想到串DML Delete；但如果刪除交易量大，怕影響線上交易時，辛苦的攻城師需要改成預存程序分批刪除，每次刪2,000筆還放慢半秒，但鎖定物件較多，批次時間也久；如果資料表能獲得DBA大人同意設置成Partition Table，用上Switch Partition可以飛快的轉出資料；不過Switch Partition手續有些繁瑣，得先建立相同分割檔案群組、相同結構的空資料表再轉移。
SQL Server 2016更方便了，TRUNCATE TABLE支援指定分割編號，秒殺的概念，來試試。