正常來說 SQL Server 可以很容易的去掛載前三個版本內的資料庫檔案，但太鐵齒的狀況下還是會踩到雷
在之前的文章中 「升級資料庫主機的帳號對應」，主要是在幫朋友測試升級資料庫的時候所遇到的問題，本來想說既然測試完了，應該就可以正式來移機了，但很不湊巧的，看到正式要移轉的環境時，差點要去膜拜了。居然在 2019 年還可以看到 Windows NT 4.0 + SQL 7.0 的環境，這實在是太神奇了。 ( 雖然前年還有看到 SQL 6.5，但只能說那真是遇到骨董了 )
本來想說應該也只是個簡單任務，因此就直接請朋友開啟 SSMS，先把原本 SQL 7.0 的伺服器給關閉，然後把資料檔案複製到新的移轉主機上，把他升級到 SQL 2005 之後，再往後升級到 2017 的上面。但沒有想到在第一關機然就出現問題了，看朋友的操作也沒有多大的問題，就是開啟 SSMS ，選擇附加資料庫之後，按下「加入」的按鈕
然後選擇我們要掛載的檔案，這裡我使用原本在 SQL 7.0 上面的 pubs 資料庫來測試
但沒有想到就居然出錯了，而從訊息中也實在很難猜出來到底哪裡出錯了，忽然有點撞牆卡關了.....
而當自己決定不理他先去睡覺之後，起來後忽然想到，難道 SSMS 在掛載資料庫之前，莫非是下了甚麼樣的指令，才造成這樣的錯誤訊息嗎 ? 因此利用 SQL Profile 攔截一下 SSMS 所下的指令，把指令複製出來測試一下，果然 Bingo 看到錯誤的問題，原來是 SSMS 利用 dbcc checkprimaryfile 指令所造成的異常，那看起來問題就好解決了。
首先我們要先知道 dbcc checkprimaryfile 這個指令是做甚麼用途的，基本上 SSMS 要透過那個指令，來取得所要還原的資料檔案，他原本的資料庫名稱、版本和定序是甚麼，然後來組合後續的副載指令。而 dbcc checkprimaryfile 又只支援 SQL Server 2000 含以後的版本，因此就還是自己乖乖地用 sp_attach_db 的指令來掛載資料庫吧。
而當我們直接改用指令來掛載的時候，就可以看到資料庫很順利地掛載上來，並且完成必要的升級了
因此又順利的完成一個簡單任務，可以放心地去休假了。