※ 引述《GP03.bbs@aeug.twbbs.org (Gundam Pilot)》之銘言：
> ※ 引述《lobnqii@kkcity.com.tw (lobnqii)》之銘言：
> > 也許MSDN有它不為人知的理由，但想想，您進入一個系統中的每一頁皆要開關
> > 一次，這樣有效率嗎？
> 理由就是...不希望每一個使用者佔用connection太久
> 至於效率的問題,在這方面就透過connection pool 來彌補
> > 我的作法是登入後就打開一個connection，並指定給一個全域變數，以後就每
> > 一支程式就使用該全域變數即可，至使用者登出才關閉。
> 這樣的話,既使在idel中也佔用的connection資源
> 尤其是一道指令明明不到一秒就結束
> 可以把connection資源讓給別人用
> 確不放開還一直佔用,就是資源浪費
> 這就是為何MSDN要這樣做的原因"之一"
> 當然還有其他原因啦...
> 舉個例說,假如A,B,C三道command要分別執行
> 如果是在最前面把connection打開然後執行A,B,C這種情況
> 假若執行到A發生例外狀況,導致連線中斷,那B跟C就執行不到了
> 但假如是在執行前才打開連線,那既使A失敗,B,C仍有機會成功執行
> 對於除錯也是比較好進行
> 當然還有其他理由啦...
了解您的意思！但所說有瑕疵。
(1) connection idel 並不代表是佔用資源，這要分連線物件是屬於區域
或全域而定。只有在區域物件之狀況下，才算是佔用資源。
(2) 連線中斷之後B,C是否仍有機會執行的問題就更複雜。
首先要了解中斷的原因是什麼？
a.連線的中斷
這種中斷方式，是無論是否有開開關關或一直開著不關都是同樣的
結果。皆必須等connection time out之後，才可續連線。這個事件
是屬於未連線前而正準備連線上所產生。
b.因為command而中斷的連線
當已連線之後，若因中途不明因素在一道command之後而發現中斷連線
狀況，這種情況比較多見於網頁程式，通常是服務太多而導致time out
。這類的中斷，並不算是真的連線中斷，只是查詢逾時的中斷。對於是
否可得推導出應開開關關的結果並非正比亦非必要。因為是命令中斷而
不是真正的連線中斷之故。
若中斷情形是真正的連線中斷，在目前通用資料庫為MS SQL/MySQL/Oracle
的狀況下，那大約不是作業系統(web server)掛掉就是資料庫已掛掉了，
這時候開開關關也沒有必要性。
微軟的立場就像政府的立場，很多時候是在說一些免責、沒有必要的話。在實務
上，我很少碰到有連線中斷的狀況，中斷的狀況大都只是查詢失敗的命令中斷而
已，但在教育手冊中還是都會提及遇中斷須再進入一次。
所以，要開開關關的需求並沒想像中的必要。何況，對於連線時之命令使用，皆
會先判斷這一次的查詢是否有效。而有效的查詢是必經connection & recordset
的有效性判斷後才進行。若是失敗，就要程式自己去啟動再次的連線，在這種機
制下就更沒有必要開開關關的，只需在失敗時再開一次（這個機制是在判斷查詢
是否有效的函式中控制)
更何況，實際上每開一次連線也需要一段時間，而且程式也不夠簡潔，當然，若
硬體設備強捍，自己也不嫌多打幾行程式，堅持一定要開開關關也是無妨。
不過，recordset 倒是有必要考慮開關。這視這個物件是放在全域還是區域，以
及同樣視窗是否可以同時多啟，以及同系統不同視窗是否允許同時多啟而定。因
為區域性recordset有時會因為掃過許多的table而鎖住資料庫某些table & rows
(依transaction level而定，我曾在三年前遇到一位多年物流經驗的專案經理，
還不知道何謂transaction level...=.=），所以若不在結束使用時釋放，則不只
是浪費硬碟或RAM空間，同時也影響到後續查詢的使用(許多dead lock就是這樣產
生的)。
若recordset是全域物件，就須注意在多視窗之下會被後視窗中的查詢抹除，至於
connection物件因為只開一次(我的方式)所以不會有這種情況發生。
結論：
想要在每支程式中開關connection亦無不可，但我本人依多年實務經驗不會選
擇這個方式
--
┌─────◆ＫＫＣＩＴＹ◆─────┐KKMAN團隊 全新力作 ◎◎KKBOX◎◎
│ bbs.kkcity.com.tw │知名歌手通通都有 所有新歌想聽就聽
└──《From:203.204.90.144 》──┘※※ 內容豐富多元的線上音樂台 ※※