JAVASCPRIT寫的確認對話框不管是否是在AJAX狀態下，都和驗證控件有衝突。
因爲數據庫某個字段有半個漢字，在AJAX下的GRIDVIEW報Sys.WebForms.PageRequestManagerParserErrorException錯誤，只能去掉AJAX，倒也顯示正常。
最好的設計是在一個方法裏打開SqlConn.Open()和Close(),不要指望系統來自動釋放資源，這在用戶多的情況下是無效的。Return DATASET之前也必須SqlConn.CLOSE();更別說DataReader是一定得Close的。
try
{
}
catch
{
}
finally
{
}
不關在什們情況下FINALLY()裏的代碼總會執行，哪怕try裏有return。
安全心得
1）輸入框必須限制長度，最好用正則表達式限制內容；
2）禁止輸入<HTML>標記；
3）上傳文件要嚴格限制類型和文件後綴，最好讀取文件的頭字節來判斷；
4）數據庫帳號不要和服務器密碼相同，最好是有限權限；
5）不應該把系統提供的錯誤信息直接暴露給用戶，包括沒有捕捉的頁面錯誤和捕捉到的ex.Message；
最保守的錯誤顯示機制:在客戶端只能看到發生錯誤提示修改CustomError的默認信息，在服務器端會顯示具體的錯誤代碼位置，
只捕捉已知的錯誤，然後顯示給用戶友好的提示，其他錯誤讓系統拋出。
如果使用ex.Message直接顯示給用戶，可能暴露一些輸入數據庫帳號，表名，索引名稱等等的關鍵信息。
SQLServer回滾作爲死鎖犧牲品的事務，通知線程的應用程序（通過返回1205號錯誤信息），取消線程的當前請求，然後允許不間斷線程的事務繼續進行。SQLServer通常選擇運行撤消時花費最少的事務的線程作爲死鎖犧牲品。
2009-4-23 14:58:24 ★ 事務(進程 ID 70)與另一個進程被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品。請重新運行該事務。
2009-4-23 15:19:59 ★ 超時已過期
因爲有些查詢動態銷售的SQL語句耗時比較長，而定時進行動態銷售更新的數據庫操作是使用事務的:先刪除，後追加。估計這個原因導致了上述錯誤。