SqlException(0x80131904):已超過連接逾時的設定

昨天幫同事看一個問題，User反應網頁查詢某報表都會發生「SqlException(0x80131904):已超過連接逾時的設定」(問題一)，另外即使縮小查詢範圍到只有數百筆仍然會發生相同錯誤，但是過去不會發生(問題二)。他初步懷疑是SQL Server查詢的回應時間Timeout所致，網路上討論的文章也有人提供類似假設，都是建議開放更多的連線時間、connection pooling，這真是可怕的建議。 另外少數有良心的程式設計師的說法我就很讚同：「程式遇到問題不應該總是向伺服器索取更多資源，應該回頭檢視程式的邏輯是否合理？是否用錯演算法或查詢指令造成系統資源的浪費。」 用這樣的原則分析同事拋出的兩個問題，問題二「縮小範圍到只有數百筆仍會發生相同錯誤」這才是問題的核心，明顯是查詢指令有問題，最常發生都是JOIN TABLE的關係錯置所致。過去經驗，改善查詢指令後程式效能往往能提升30%~70%，這比任何硬體升級都能解決網站效能。不過大部分的IT主管似乎比較迷信硬體升級，以為花錢買設備解決問題最快，結果設備買了不到一個月問題照常發生，也只能用發生頻率變低安慰自己。 優化查詢指令後，如果仍發生「SqlException(0x80131904):已超過連接逾時的設定」。可以計算從aspx網頁下submit後response的時間。 System.Data.SqlClient 的connection timeout時間預設為30秒，網路上很多村民建議在web.config設定延長此時間，這是萬萬不可啊！預設的30秒的查詢回應足以應付大部分的需求。不得已向伺服器索取更多資源的「特殊需求」，應該只限於單一查詢指令。 於是我在程式碼中作了如下修改： Dim sqlConnection1 As New SqlConnection(connString & "Connect Timeout=60") ...... cmd.CommandTimeout=60 ...... reader.Close() 將connection及command Timeout時間都延長到60秒，增加一倍的時間已經很多，「前人」忘了釋放DataReader的資源看到後當然要順手處理。經此調校後同事的系統已經正常運作。 Debug的技術面不難，但是處理問題的「原則」跟「態度」會決定這個系統是否走向「暴斃」或延續。 完整的錯誤訊息如下： '/aspx' 應用程式中發生伺服器錯誤。 -------------------------------------------------------------------------------- 已超過連接逾時的設定。在作業完成之前超過逾時等待的時間，或者是伺服器未回應。 描述: 在執行目前 Web 要求的過程中發生未處理的例外情形。請檢閱堆疊追蹤以取得錯誤的詳細資訊，以及在程式碼中產生的位置。 例外詳細資訊: System.Data.SqlClient.SqlException: 已超過連接逾時的設定。在作業完成之前超過逾時等待的時間，或者是伺服器未回應。 ...(略)... 堆疊追蹤: [SqlException (0x80131904): 已超過連接逾時的設定。在作業完成之前超過逾時等待的時間，或者是伺服器未回應。] System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) +857146 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) +734758 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) +188 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) +1838 System.Data.SqlClient.SqlDataReader.ConsumeMetaData() +31 System.Data.SqlClient.SqlDataReader.get_MetaData() +62 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) +297 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) +886 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) +132 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) +32 System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) +122 System.Data.SqlClient.SqlCommand.ExecuteReader() +84 ...(略)

JavaScript 恩仇錄

1998年的夏天，烈日穿透頂樓的瓦片，把我的小小書房變成一部超大的微波爐。我的膝蓋上攤著一本FrontPage97的網頁教學，艱辛地用一陽指敲打鍵盤學做網頁。 我的同學早已收到兵單開始當大頭兵，我卻仍在學校裡暑修大一英語。雖然面臨大學畢不了業的窘境，我卻日以繼夜在學習製作網頁、嘗試架網站，與JavaScript這個冤家相識就是發生在那個時候。 JavaScript提供用戶端的瀏覽器執行許多特效，網路上有很多範例，如何套用在自己製作的網頁上，是學做網頁必備的知識。 當完兵後我自知不是做財務的料，於是進了軟體公司寫VB。那時公司接了一個銀行的案子，需要製作一個網站，我的程式底子最弱，所以使用者介面設計的工作便落在我頭上。可是網頁不比Window應用程式那樣有便利的操作介面，許多細微的動作有賴JavaScript控制。我與JavaScript不熟，但是被送作堆在一起半年，整天捧著博碩的「JavaScript語法參考辭典」參悟，總算由一知半解到熟稔。後來有幸到銀行工作，寫網路銀行的JSP、Servlet程式總算脫離JavaScript魔掌。 問我為什麼不喜歡JavaScript？理由是debug太難了。常常花了一個小時替User寫了一個效果，卻需要兩三倍時間去debug，沒有開發工具是我不喜JavaScript的主因。 但是那半年與JavaScript艱辛的擁抱也不是沒有收穫，我debug能力因此進步神速，也大大縮短日後寫程式需花費的時間。 一個網站程式設計師要躲過寫JavaScript似乎不可能，後來我換工作到研訓院寫e-learning的網站，頭痛的JavaScript又隨著SCROM 1.2、SCROM 2004大舉入侵。雖然是拿別人寫好模組應用，但是時間卻仍耗在debug上面。 Debug是程式設計論壇最多的問題，而JavaScript偏偏又缺乏強力的開發工具。很多程式設計師有志一同，預到JavaScript的問題腦袋就特別腫。 我現在的工作已經不是程式設計師，但是這次為了清清書架上的電腦書，撫摸它們的時候JavaScript噩夢又浮現腦海中。 這些書就要送人了，在此之前我還會再翻閱一次，也許做做筆記把一些內容寫在blog上，免得哪天又換工作需要用到它們。

「~MSSETUP.T」 是什麼資料夾？

最近有朋友問到資料夾中發現一個「~MSSETUP.T」資料夾，這是什麼檔案呢？
會不會對電腦造成什麼影響呢？

這是安裝應用程式時留下的暫存目錄，一般安裝完成後會動刪除，但是部份應用程式安裝完成必須重開機，此時就會留下這個暫存的目錄。

用新增移除程式uninstall應用程式時，這個目錄是不會被刪除。如果系統中任何地方發現它，可以用「檔案總管」直接刪除。