.NET 資料存取架構導覽

相關連結

樣本與實例索引

.NET 應用程式架構 : 設計應用程式與服務

Alex Mackman，Chris Brooks， Steve Busby，Ed Jezierski，Jason Hogg，Roberta Leibovitz (模組化計算 ) 和 Colin Campbell (模組化計算 )

Microsoft Corporation

2001 年 10月

2003 年 6 月更新

適用於 :
SQL Server 2005 Analysis Services

摘要 : 這份文件說明如何在多層式 .NET應用程式中使用 ADO.NET 實作資料存取層。內容著重於一般的資料存取工作及其方案，以及指導你選擇最適合的解決方法與技術。

本頁內容

	簡介
	簡介 ADO.NET
	錯誤處裡
	效能
	透過防火牆連結
	處理 BLOB
	用 DataSet 來進行資料庫更新
	使用強型別DataSet物件
	處理 Null 資料欄位
	交易
	資料分頁
	附錄

簡介

如果你想為 .NET 應用程式設計資料存取層，你應該要使用 Microsoft 的 ADO.NET 作為資料存取模式。 ADO.NET 功能強大而且可以支援鬆散藕合，網路應用程式，以及 Web service 的資料存取需求。跟其他功能強大的物件模組一樣，ADO.NET 可以為單一特定問題提供眾多的解決方案。

本文內含的資訊可以幫助你選擇最合適的資料存取方式。裡面介紹了大部分的資料存取方案，關於效能提昇的訣竅，以及相關的最佳實例。本文中也解答了一些常見的問題，如 : 資料庫連接字串應該安置在哪裡最好 ? 我應該如何實作連接共用 ? 我應該如何處理交易 ? 我應該如何製作分頁功能好讓使用者能捲動瀏覽大量紀錄 ?

本文內容著重於如何使用 ADO.NET 及其隨附的SQL Server .NET data provider 來存取 Microsoft SQL Server 2000。本文將會特別標明當你使用 OLE DB .NET data provider t 去存取其他 OLE DB-aware 資料來源時應該要注意的事項。

如果想取得按照本文內容跟實例開發出的資料存取元件之具體實作，請參考 Data Access Application Block。 Data Access Application Block 的內容包含原始碼讓你可以直接在 .NET 應用程式中使用。

誰應該閱讀這份文件

本文件為應用程式架構以及想建置 .NET 應用程式開發人員提供了良好介紹。如你想要設計及開發多層式的 .NET 應用程式，請閱讀此份文件。

使用須知

想使用本文件來建置 .NET應用程式，你必須要有使用 ActiveX Data Objects (ADO) 或是 OLE DB ，以及 SQL Server 來撰寫資料存取程式碼的經驗。你必須了解如何使用 .NET 平台開發管理程式碼，以及了解 ADO.NET 資料存取模組的基本架構上有什麼樣的改變。更多.NET 開發相關資訊，請至 http://msdn.microsoft.com/net。

更新紀錄

本文更新的章節包括進行資料庫更新，使用型別資料集以及使用 Null 資料欄位。

正如前面所述，本文的部分內容僅適用於 Microsoft Visual Studio 2003 development system 及 .NET Framework SDK version 1.1。

下載 .NET 資料存取架構導覽

點擊連結以下載本文 MS.com 下載中心

回到頁首

簡介 ADO.NET

ADO.NET 是 .NET 應用程式中的資料存取模組。它是用來存取關聯式資料庫系統，如 : SQL Server 2000， Oracle， and 以及其他許多是 OLE DB 或是 ODBC provider 的資料來源。就某種層面而言，ADO.NET 代表了 ADO 技術的最新變革。然而，ADO.NET 是著眼於鬆散耦合—通常是離線狀態—的網路應用程式，而作了許多重大的改變與革新。有關 ADO and ADO.NET 的比較，詳見 MSDN 的文章 "ADO.NET for the ADO Programmer" 在以下連結 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/adonetprogmsdn.asp。

ADO.NET 的重大變革之一，就是將 ADO 中的 Recordset 物件的功能分配給 DataTable， DataSet， DataAdapter，與 DataReader 物件。 DataTable 代表的是從單一資料表中而來的資料列集合，而就這方面而言很像 Recordset。DataSet 代表的是 DataTable 物件的集合，用其中的關聯性及約束性將資料表細節在一起。就功能上來說，tDataSet 是一個位於記憶體中擁有 XML 功能的關聯式結構。

DataSet 的重大特色之一就是基礎資料來源的資訊可能從來沒有填入其中。它是一個用來代表資料集合的離線獨立實體，而且可以在多層式應用程式的眾多層面的元件中互相傳遞。它還可以被序列化為 XML 資料流，所以它也很適合進行異質平台間的資料傳輸。ADO.NET 使用 DataAdapter 物件來引導資料進出 DataSet 以及基礎資料來源。DataAdapter 物件也可以提供以前 Recordset 的批次更新功能。

圖 1 顯示 DataSet 物件模組。

Figure 1.1 DataSet 物件模組

.NET Data Providers

ADO.NET 必須有 .NET data providers 的協助。.NET data providers 提供對基礎資料來源的存取，其是由四個主要物件構成 (Connection， Command， DataReader，以及 DataAdapter)。

目前 ADO.NET 隨附了兩種 providers : bridge providers and native providers。 Bridge providers，是由 OLE DB 和 ODBC 等提供的，讓你可以使用早期資料存取技術的函式庫。 Native providers，像是 SQL Server 和 Oracle providers，通常是為了效能的改善而將抽象層減少。

•	SQL Server .NET Data Provider。Microsoft SQL Server 7.0 的 provider 和較新的資料庫。它對存取 SQL Server，以及使用 SQL Servery 的資料傳輸協定來與 SQL Server 溝通的功能都進行了最佳化。永遠使用 provider 來連結 SQL Server 7.0 或 SQL Server 2000。
•	Oracle .NET Data Provider。用於 Oracle 的 .NET Framework Data Provider 能透過 Oracle 用戶端連結軟體來存取 Oracle 的資料來源。這個 data provider 支援 Oracle 用戶端連結軟體 8.1.7 版及之後的版本。
•	OLE DB .NET Data Provider。這是一個 OLE DB 資料來源 managed provider。它的效率比 SQL Server .NET Data Provider 略差，因為它是透過 OLE DB 層來與資料庫溝通。需要注意的是，這個 provider 不支援 ODBC， MSDASQL 的 OLE DB provider 。對 ODBC 資料來源，要用 ODBC .NET Data Provider ( 容後描述 ) 來取代。如於取得相容於 ADO.NET 的 OLE DB providers 清單，請至 http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconadonetproviders.asp。

其他尚在測試中的 .NET data providers 包括 :

•	ODBC .NET Data Provider。ODBC 的 .NET Framework Data Provider 使用 ODBC 驅動程式管理員 (DM) 透過 COM 的互相作用來存取資料。
•	一個 managed provider 用來從 SQL Server 2000 中擷取 XML。 XML for SQL Server Web update 2 ( 目前尚在測試中 ) 包含一個 managed provider 特別用來從 SQL Server 2000 中擷取 XML。如欲獲得更多相關資訊，請至以下網址 http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001300。

如果想獲得更詳盡 data provider 的資訊，請參閱在 .NET Framework 開發人員指南中的 ".NET Framework Data Providers"，可點以下連結進入 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconadonetproviders.asp。

命名空間組織

關於每一個 .NET data provider 的型態 ( classes， structs， enums，等等 ) 都在下列的命名空間中 :

•	System.Data.SqlClient。包含 SQL Server .NET Data Provider 的型態。
•	System.Data.OracleClient。包含 Oracle .NET Data Provider 的型態。
•	System.Data.OleDb。包含 OLE DB .NET Data Provider 的型態。
•	System.Data.Odbc。包含 ODBC .NET Data Provider 的型態。
•	System.Data。包含與 provider 無關的型態，如 DataSet 和 DataTable。

在相關的命名空間中，每一個 provider 提供了關於 Connection， Command， DataReader，以及 DataAdapter 的物件實作。SqlClient 實作開頭都是用"Sql" 而 OleDb 的實作開頭都是用 "OleDb" 。舉例來說，SqlClient 實作 Connection 物件的是 SqlConnection，而在 OleDb 中則是 OleDbConnection。以此類推，在這兩個大類中的 DataAdapter 物件應該是 SqlDataAdapter 和 OleDbDataAdapter。

在本文中，這些範例都是從 SQL Server 物件模組而來。雖然在這裡並沒有舉例，不過類似的情況也出現在 Oracle/OLEDB 和 ODBC。

泛用程式設計

如果你可能會使用到不同的資料來源並且希望你的程式碼可以在其中自由套用，考慮使用在 System.Data 命名空間中的 IDbConnection， IDbCommand， IDataReader，和 IDbDataAdapter 介面。所有實作 Connection， Command， DataReader，和 DataAdapter 的物件一定支援這些介面。

如欲取得更多關於 .NET data providers 實作的相關資訊，請至以下網址 http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconimplementingnetdataprovider.asp。

還有一個值得注意的就是，如果應用程式想使用一個物件模組去存取複數個資料庫，OLE DB 和 ODBC bridging provider 是個不錯的選擇。在這種狀況下，比起應用程式的效能，更應該思考應用程式的靈活性，以及資料庫所需功能的範疇。

圖 2 以資料存取堆疊來說明 ADO.NET 與其他資料存取技術間的關聯，包括 ADO 和 OLE DB。它也展示出這兩個 managed provider s and the principal objects within the ADO.NET model。

圖 1.2. 資料存取堆疊

如果想知道更多關於 ADO 到 ADO.NET 之間的改變，請閱讀 2000年 11月號的 MSDN 雜誌中的 "Introducing ADO+: Data Access Services for the Microsoft .NET Framework" ，該文位於以下網址 http://msdn.microsoft.com/msdnmag/issues/1100/adoplus/default.aspx。

愈存程序 vs. 直接使用 SQL

在本文中所出現的程式碼區塊使用 SqlCommand 物件呼叫預存程序來進行資料庫操作。在某些狀況下，你不會看到 SqlCommand 物件因為預存程序的名稱已經直接導 SqlDataAdapter 物件。在內部運作中，依然還是會創建一個 SqlCommand 物件。

以下是關於為何應該使用預存程序來取代嵌入的 SQL 敘述的幾個理由 :

1.	因為資料庫可以透過快取及重複使用預存程序來進行資料存取最佳化，所以預存程序通常可以改善效能。
2.	在資料庫中預存程序可以維持個別的安全性。用戶可以被授權執行預存程序卻不必擁有任何直接存取資料的權限。
3.	修改預存程序通常是比修改寫死在元件中的 SQL 敘述來得容易的，所以預存程序可以減輕維護的負擔。
4.	預存程序為基礎的資料庫結構描述增加了一個新的抽象層。預存程序的用戶是與跟預存程序的實作細節及基礎的結構描述隔開的。
5.	因為在預存程序可以批次執行不必反覆進行多次的傳送，所以預存程序可以減低網路流量負擔。

SQL Server 線上說明文件強烈建議不要用 "sp_" 作為你預存程序名稱的開頭因為這樣的名稱已經保留給系統預存程序了。 SQL Server 會按照如下的順序從 sp_ 開頭的預存程序開始搜尋：

1.	找尋主要資料庫中的預存程序。
2.	找尋由辨識符號 ( 資料庫名稱或所有者 ) 提供的預存程序。
3.	如果沒有指定所有者，則以 dbo 為所有者來找尋預存程序。

屬性 vs. 建構函式引數

你可以透過建構函式引數或是直接設定來設定 ADO.NET 物件的屬性值。舉例來說，下列程式碼在功用上是相等的。

// Use constructor arguments to configure command object
SqlCommand cmd = new SqlCommand( "SELECT * FROM PRODUCTS"， conn );

// The above line is functionally equivalent to the following
// three lines which set properties explicitly
sqlCommand cmd = new SqlCommand();
cmd。Connection = conn;
cmd。CommandText = "SELECT * FROM PRODUCTS";

就效能的觀點而言，這兩種方法的差距微不足道。因為取得及設定 .NET 物件屬性通常是比 COM 物件來得有效率。

至於要選哪一個基本上是依個人喜好及程式碼風格。然而，對屬性值進行直接設定，通常讓程式碼更容易解讀 ( 特別是當你對 ADO.NET 物件模組不太熟悉的時候) 而且更方便除錯。

附錄 : 在過去，Microsoft Visual Basic 的開發人員開發系統時，通常是希望避免使用 "Dim x As New…" 這樣的敘述來創建物件。在 COM 的世界中，這樣的程式嗎會造成一個 COM 物件創建的小迴路，產生一些很細微或不細微的錯誤。然而，在 .NET 的世界中，這將不再是個問題。

管理資料庫連結

資料庫連結代表的是一個重要，昂貴，而且相當有限的資源，尤其是在多層式網路應用程式當中。It is 正確地管理你的連結是勢在必行的，因為你所採用的方法將會嚴重地影響應用程式的可調整性。當然，要謹慎思考在何處儲存你的連結字串。你需要的是一個有調整性又安全的地方。

當你要管理資料庫連結與連結字串時，你應該要顧慮到 :

•	為了增加應用程式的延展性，應該建立資料庫連結共用以供多個使用者使用。
•	採用可調整及高效能的共用連結策略。
•	存取 SQL Server 時使用 Windows 驗證。
•	不要在中間層進行模擬。
•	將連結字串安全存放。
•	儘晚開啟資料庫連結儘早關掉。

本章節討論連結共用以及幫你選擇最合適的連結共用策略。本章節也交會你如何管理，儲存，以及管理資料庫連結字串。最後，本章節提供兩個程式碼樣本讓你可以確定連結正確結束並回到連結集合中。

使用連結共用

資料庫連結共用讓應用程式從一個連結集合中使用已存在的連結，而不必重複地與資料庫建立新連結。這個技術大幅地增加了應用程式的延展性，因為資料庫的連線上限變得大多了。這個技術也改善了效能，因為節省了許多原本用來建立連結的時間被。

資料存取技術像是 ODBC 和 OLE DB 都提供了多種連結共用，都是可以按照各種程度來作調整。兩種方法對資料庫用戶端來說都太透明了。 OLE DB 連結共用通常是被來當作 session 或是資源共用。

想取得更多關於 Microsoft Data Access Components (MDAC) 的共用議題討論，請看 "Pooling in the Microsoft Data Access Components" 這篇文章，網址如下 http://msdn.microsoft.com/library/en-us/dnmdac/html/pooling2.asp。

ADO.NET data providers provide 提供了清晰的連結共用，其內部的機制是依每個 provider 而不同。本章節所討論的連結共用是關於有 :

•	SQL Server .NET Data Provider
•	Oracle .NET Data Provider
•	OLE DB .NET Data Provider
•	ODBC .NET Data Provider

SQL Server .NET Data Provider 進行共用

如果你使用 SQL Server .NET Data Provider，請使用它所提供的連結共用。在 provider 的內部的管理馬有實作高效率的共用機制。連結集合是依每個應用程式定義域來創建的，應用程式定義域結束以前連結集合都會存在。

你可使用它所內附的連結共用，但是你還是應該了解其中的共用機制在各式各樣的設定下是如何運作，以進行連結共用的微調。

在許多情況下，你的應用程式中使用 SQL Server .NET data provider 的連結共用預設設定可能已經就夠好了。在開發及測試 .NET應用程式時，建議你模擬一下完成後的資訊交流情境以決定是否應該修改連結共用的大小。

開發人員為了能建置具延展性，高效能的應用程式，應該盡可能縮短維持連線的時間，只有再取得或更新資料時才進行連線。當連線關閉時，應該將其傳回連結共用集合讓這個連結可以再利用。在這種狀況下，與資料庫的實際連結並沒有中斷 ; 然而，如果連結共用關閉了，與資料庫的實際連結也就都關閉了。

開發人員應該要小心不要依賴系統來釋放連結因為當連結使用結束以後不見得一定會被關閉。這通常會造成連結的遺漏，使得建立新連結時產生錯誤。

設定SQL Server .NET Data Provider 連結共用

你可以使用名稱值組來設定連結共用，這提供了連結字串的功能。舉例來說，你可以設定是否使用共用集合 ( 預設是使用 )，共用集合大小的最大與對小值，以及開啟連結所需的等待時間或等待的工作數。下面是一個連結字串的範例用以調整共用集合大小的最大與對小值。

"Server=(local); Integrated Security=SSPI; Database=Northwind; 
Max Pool Size=75; Min Pool Size=5"

當連結開啟而共用集合也建好後，許多連結就會加入連結共用以達到共用集合大小的最小設定值。而系統可以持續共用集合大小的上限。當共用集合已達上限時，建立新連結的要求就會先行擱置。

選擇共用集合的大小

對大規模的系統而言建立一個最大臨界指標是很重要的，這樣才會方便管系統中的工作還有成千上萬的用戶。你必須要監控應用程式中連結共用的效能，才能為你的系統選擇最佳的連結共用大小。這個最佳大小也會執行 SQL Server 的硬體的影響。

在開發過程中，你可能需縮小共用集合的預設最大值 ( 目前是 100 ) 來有效的發覺連結遺漏。

如果你為連結共用設定了最小值，你可能會在連結共用初始時，為了要達成共用連結的最小值造成輕微的效能浪費，雖然這對剛開始使用連結的用戶來說是很好的。值得一提的是創建新連結的動作是序列化的，這代表說你伺服器不會因為連結共用的初始化而造成系統無法負擔大量的即時連結需求。

如果想取得更多關於監控連結共用的資訊，請至本文中監控連結共用的章節。如果想取得連結共用中連結字串關鍵字的完整資訊，請參閱在 .NET Framework Developer's Guide 中的 "Connection Pooling for the .NET Framework Data Provider for SQL Server" 一文，網址如下 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconconnectionpoolingforsqlservernetdataprovider.asp。

用 OLE DB .NET Data Provider 進行連結共用

OLE DB .NET Data Provider 的連結共用是透過 OLE DB 地層的資源共用來進行。你有下列幾個選項可以在資源共用中設定 :

•	你可以使用連結字串來調整，啟用或是關閉資源共用。
•	你可以使用系統登錄。
•	你可以用程式碼來調整資源共用。

為了避免遭遇系統登錄相關的開發問題，請不要使用系統登錄來調整 OLE DB 資源集區。

如果想知道 OLE DB 資源集區的詳情，請參閱 OLE DB Programmer's Reference 中的 "Resource Pooling"，"OLE DB Services"，網址如下 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledb/htm/olprcore_chapter19.asp。

使用集區物件來管理共用連結

身為 Windows DNA 開發人員，你會被建議放棄使用 OLE DB 資源管理或是 ODBC 連結共用而使用 COM+ 物件集區來進行資料庫連結共用。這主有兩個理由 :

•	共用集合的大小與上限可以被精準地控制 (在 COM+ 類別中)。
•	效能的改善。集區物件的做法可以比直接進行提高一半的效能。

然而，因為 SQL Server .NET Data Provider 是在內部進行集區，你不需要再去開發自己的集區物件 ( 當你使用這個 provider 的時候 )。你可以不必理會這個複雜的運作機制。

但如果你使用 OLE DB .NET Data Provider 而又進行更進一步的調整及改善效能的話，哪你可以考慮使用 COM+ 物件集區來進行。如果你使用了集區物件來進行，那你一定要關閉 OLE DB 資源集區和和自動交易編列 ( 舉例來說，在連結字串中加入 "OLE DB Services=-4" )。你必須要用自行設計的集區物件來作交易編列。

監控連結共用

為了監控你的應用程式對連結共用的使用，你可使用 SQL Server 中搭載的 Profiler 工具，或是 Microsoft Windows 2000 的 Performance Monitor 工具。

用 SQL Server Profiler 監控連結共用

•	點擊 Start，選擇 Programs，選擇 MicrosoftSQLServer，然後點擊 Profiler 以啟動 Profiler。
•	在 File 選單上，選擇 New，並且按 Trace。
•	提供關於連結的細節，然後點擊OK。
•	在 Trace的 Properties 對話方塊中，選擇 Events 標籤頁面。
•	在 Selected event classes 清單中，確認 AuditLogin 還有 AuditLogout 在 SecurityAudit的項目下。為了能夠讓這個追蹤提供更精準的資訊，請移除清單中的其他事件。
•	點擊 Run 來開始追蹤。當連結建立時，你將會看見 Audit Login 事件，而當連結關閉時則會出現 Audit Logout 事件。

用 Performance Monitor 監控連結共用

•	點擊 Start，選擇 Programs，選擇 AdministrativeTools，然後點擊 Performance開始 Performance Monitor。
•	在背景點擊右鍵，然後點擊 Add Counters。
•	在 Performanceobject 的下拉式選單中，點擊 SQL Server: General Statistics。
•	在出現的選單中，點擊 User Connections。
•	點擊 Add，然後點擊 Close。

安全性管理

雖然資料庫連結共用僅僅是改善了你應用程式的全面延展性，但這意味者你不必再去進行資料庫的安全管理。這是因為為了支援連結共用，所以連結字串必須都是不同的。如果你需要以每一使用者為基礎來追蹤資料庫的運作，那就可以考慮加入一個參數，你可以透過這個參數來紀錄使用者在資料庫中的運作。你必須在每向操作中都加入這個參數。

當你連結到 SQL Server 時應該使用 Windows 驗證，這樣做的好處如下 :

•	資訊安全變得易於管理。因為你在單一的 (Windows) 安全模式下工作而不是在分開的 SQL Server 安全模式下。
•	你不必在連結字串中寫入使用者名稱與密碼。
•	使用者名稱與密碼不必以明文的方式進行網路傳輸。
•	透過密碼使用期限，最短長度，以及數次無效登入後進行帳號鎖定等功能來提高登入的安全性。

儲存連結字串

為了儲存連結字串，你有許多不同層級的靈活度及安全性設定可以選擇。雖然直接使用原始碼進行連結字串的硬式編碼擁有最佳的效能，而檔案系統快取可以讓因為將連結字串進行外部儲存所造成的效能落差幾乎感受不到。外部的連結字串還可以提供額外的靈活度，在幾乎所有的狀態下都支援管理者組態。

當你選擇儲存連結字串的方法的時候，最重要的考量莫過於安全性與易於調整，緊接著才是效能。

你可以在下列位置中選擇存放資料庫連結字串 :

•	在應用程式的設定檔中 ; 例如，ASP.NET 網路應用程式的中 Web.config
•	在 Universal Data Link ( UDL ) 檔案中 (只有 OLE DB .NET Data Provider 支援)
•	在 Windows 系統登錄檔中
•	自訂檔案
•	COM+ 類別中，使用建構字串來進行 (只有在相關元件中)

藉由使用 Windows 驗證來存取 SQL Server，你可以不必在連結字串中儲存使用者名稱與密碼。如果你有更高等級的安全性需求，可以考慮用加密模式儲存連結字串。

就 ASP.NET 網路應用程式而言，在 Web.config 檔案中儲存加密後的連結字串是一個安全又易於調整的解決方案。

附錄 : 你可以在 SqlConnection 或 OleDbConnection 物件回傳的ConnectionString屬性中，對連結字串中設定 Persist Security Info 的值為 false 以避免洩漏資訊安全相關重要訊息洩漏，如密碼一類， s。

接下來的段落將要討論如何使用各種方法來儲存連結字串，其中還為每個方法的優點和缺點作了剖析。能夠讓你依照應用程式狀況的不同而作出最好的選擇。

附錄 : Configuration Application Management 區塊能夠讓你管理從簡單資料庫連結到複雜的階層式資料的組態設定。如果想了解更多，請至以下網址 http://msdn.microsoft.com/practices。

使用 XML 應用程式組態檔案

你可以使用應用程式組態檔案中自訂設定的 <appSettings> 項目來儲存資料庫連結字串。該項目支援t supports arbitrary key-value pairs，就如同以下區塊的範例:

<configuration>
 <appSettings>
  <add key="DBConnStr"
     value="server=(local);Integrated Security=SSPI;database=northwind"/>
 </appSettings>
</configuration>

附註 : <appSettings> 項目是在 <configuration> 項目下而不是在 <system.web>項目下。

優點

•	開發容易連結字串透過正規 .NET xcopy 而在組態檔來開發
•	程式存取容易透過在 ConfigurationSettings 類別中的AppSettings屬性使得執行時讀取資料庫連結字串組態容易不少。
•	支援動態更新( 只有在 ASP.NET )。如果管理者更新了 Web.config 檔案中的資料庫連結字串，這個改變將會在下次存取的時候立即生效。

缺點

•	安全性雖然 ASP.NET Internet Server Application Programming Interface (ISAPI) dynamic-link library (DLL) 禁止用戶端直接存取 .config 格式的檔案而且在 NTFS 可以更進一步地限制存取，你還是可能會不想把資料以明文方式存在前端的網路伺服器上。為了增加安全性，應該要以加密方式將連結字串儲存在組態檔中。

使用 UDL 檔案

OLE DB .NET Data Provider 支援 Universal Data Link (UDL) 檔案格式來儲存連結字串。你可以使用 OleDbConnection 物件的建構式引數來傳遞連結字串，或是你可以利用物件的 ConnectionString 的屬性直接設定。

附註 : SQL Server .NET Data Provider 並不支援用 UDL 檔案來存放連結字串。因此，這個方法只有在你使用 OLE DB .NET Data Provider 時才能使用。

在 OLE DB provider 中，使用 UDL 檔案來獲得連結字串，只要使用像這樣的指令 "File Name=name.udl."

優點

•	標準格式。你可能已經在使用 UDL 檔案作為連結字串的管理了。

缺點

•	效能。每次開啟連結的時候都要開啟 UDL檔案解讀連結字串。
•	按全性。 UDL 檔案是以明文儲存。你可以使用 NTFS 的檔案權限管理來增加安全性，但這是跟 .config 檔案一樣的問題。
•	SqlClient 不支援 UDL 檔案。用來存取SQL Server 7.0 及更新版本的 SQL Server .NET Data Provider並不支援 UDL。

使用在 Windows 系統登錄檔

你可以在 Windows 系統登錄檔中使用自訂鍵值來儲存連結字串，不過因為會造成開發上的問題所以並不推薦這種方法。

•	安全性你可以使用 access control lists (ACLs) 來存取選定的系統登錄檔。這擁有更高度的安全性也可以對資料加密。
•	程式設計存取簡化 .NET 類別中有支援讀取登錄檔的功能。

缺點

•	部署。相關的登錄系統設定必須隨著你的應用程式移動，失去使用 xcopy 的優點。

使用自訂檔案

你可以使用自訂檔案來儲存連結字串。然而，這種作法並沒有任何優點所以也不推薦。

優點

•

無。

缺點

•	額外的程式碼撰寫這個方法必須撰寫額外的程式碼而且讓使用者處理同時執行的問題。
•	部署這種檔案必須隨著 ASP.NET 應用程式檔案一起複製。不可將這種檔案放置在 ASP.NET 應用程式的目錄或是子目錄中以免直接從網路上被下載。

使用建構式引述跟 COM+ 類別

你可以將資料庫連結字串儲存在 COM+ 類別中並且透過物件建構式字串將它傳遞至物件中。 COM+ 在初始化物件後會呼叫物件的 Construct 方法，接收物件建構式字串。

附註 : 這種方法只能在某些服務元件中使用。所以只能在你的管理元件使用其他服務時使用，像是分散式交易支援或是物件集區。

優點

•	管理管理者可以使用 Component Services MMC snap-in 輕鬆修改連結字串。

缺點

•	安全性 COM+ 類別是一個不安全的儲存區域 ( 雖然你可以用 COM+ 身分限制存取) 所以因此不能將連結字串用明文儲存。
•	部署 COM+ 類別中的的項目都必須隨著 .NET應用程式變動。 I如果你使用了其他企業服務，像是分散式交易或物件集區，使用這個方法就沒有什麼開發上的優勢，因為 COM+ 類別必須要用來支援其他服務。
•	必須是服務元件你只能在服務院件中使用建構式字串。你不應該只為了能使用建構式字串就用 ServicedComponent 為基礎來開發元件類別。

重點提示 : 維護連結字串的安全是很重要的。使用 SQL 驗證，連結會包含使用者名稱跟密碼。如果攻擊者瞭解網路伺服器中的弱點用以取得相關原始碼或是組態存放的位置，資料庫就會飽受威脅。為了防範未然，連結字串應該要接受加密程序。如果想要深入了解各種在連結字串上加密的方法，請參閱 Improving Web Application Security: Threats and Countermeasures，請至以下網址閱覽 http://www.microsoft.com/practices。

連結使用範例

不論你使用的是哪一種 .NET data provider，你都一定要按照以下原則進行 :

•	僅可能晚點開啟資料庫連結。
•	使用連結的時間盡可能的短。
•	儘快的關閉連結。連結如果沒有被 Close 或 Dispose 方法關閉是不會回傳給共用集合的。就算你偵測到連結已經中斷還是應該進行關閉的動作。這回讓它傳回共用集合並確認失效。共用集合會定時的進行掃描確認物件是否已經失效。

為了確保在方法回傳前連結就已經關閉，請參考如下的兩個範例。第一個使用 finally 程式區塊。第二個使用 C# 的 using 敘述，用以確保物件的 Dispose 方法有被呼叫。

下面的程式碼中 finally 程式區塊確認連結有被關閉。值得一提的是這個方法只能在支援結構例外處理的 Visual Basic .NET 和 C# 中使用。

public void DoSomeWork()
{
  SqlConnection conn = new SqlConnection(connectionString);
  SqlCommand cmd = new SqlCommand("CommandProc"， conn );
  cmd。CommandType = CommandType。StoredProcedure;

  try
  {
    conn。Open();
    cmd。ExecuteNonQuery();
  }
  catch (Exception e)
  {
    // Handle and log error
  }
  finally
  {
    conn。Close();
  }
}

下面的程式碼是另外一種使用 C# using 敘述的方法。值得一提的是 Visual Basic .NET 並不提供 using 敘述或是相同的功能。

public void DoSomeWork()
{
  // using guarantees that Dispose is called on conn， which will
  // close the connection。
  using (SqlConnection conn = new SqlConnection(connectionString))
  {
    SqlCommand cmd = new SqlCommand("CommandProc"， conn);
    fcmd。CommandType = CommandType。StoredProcedure;
    conn。Open();
    cmd。ExecuteQuery();
  }
}

你可以把這個範例套用在其他的物件上，例如， SqlDataReader 或 OleDbDataReader 在對現有連結進行任何處理之前都必須先關閉連結。

回到頁首

錯誤處裡

ADO.NET 的錯誤是透過 .NET Framework 基礎結構中的的例外處理功能而產生的。因此，你在資料存取程式碼中進行錯誤處理跟在應用程式的其他部分進行錯誤處理的方法都是一樣的。透過標準的 .NET 例外處理語法跟技術，例外可以很順利地被偵測及處理。

這個章節告訴你如何開發功能強大的資料存取程式嗎並解釋其中如何處理資料存取的錯誤。還提供了關於 SQL Server .NET Data Provider 錯誤處理功能的導覽。

.NET 的例外

.NET data providers 將資料庫的錯誤轉換成標準的例外型態，所以你可以在資料存取程式碼中直接處理。資料庫的錯誤細節你可以透過相關的例外物件屬性而得知。

所有的 .NET例外型態都是由System命名空間下的基本 Exception 類別衍生而來。 .NET data providers 傳回 provider 的特定錯誤型態。舉例來說，當SQL Server 傳回錯誤訊息，SQL Server .NET Data Provider會傳回 SqlException 物件。同樣地， OLE DB .NET Data Provider 也會傳回 OleDbException 形態的例外，裡面包含了OLE DB provider底層的錯誤細節。

圖 3 顯示出 .NET data provider 的例外階層架構。注意其中 OleDbException 類別是繼承ExternalException類別，而那是所有 COM Interop 例外的基礎類別。此物件的ErrorCode 屬性儲存了由 OLE DB 產生的 COM HRESULT。

Figure 1.3. .NET Data Provider exception hierarchy

圖 1.3. .NET Data Provider 例外階層

捕捉與處理 .NET 例外

為了處理資料存取的例外，請將你的資料存取程式碼放在 try 程式區怪中並使用 catch 程式區塊放至例外處理程式碼，當然請別忘了加上合適的例外型態來過濾。舉例來說，使用 SQL Server .NET Data Provider 撰寫資料存取程式碼的時候，你應該捕捉 SqlException 型態的錯誤，就如同下方的程式碼一般 :

try
{
  // Data access code
}
catch (SqlException sqlex) // more specific
{
}
catch (Exception ex) // less specific
{
}

如果你撰寫了超過一個的 catch 敘述並使用了不同的錯誤型態過濾，請記得依發生的機率按順序排好。這樣的做法，會讓最常發生的錯誤型態的 catch 區塊在所有的例外型態都會執行。

而 SqlException 類別的屬性中包含了例外狀況的細節。這裡面包括 :

•	Message 屬性內容是錯誤的文字敘述。
•	Number 屬性內容是錯誤代碼，這是用來辨別錯誤的型態用的。
•	State 屬性內容是引發錯誤的狀況之相關資訊。這通常都是用來指出特定錯誤的發生位置。舉例來說，一個預存程序可能不只一行引發了同樣的錯誤，這時 state 屬性就能幫忙指出錯誤的位置。
•	Errors集合，這裡裡面包含了 SQL Server 傳回錯誤的詳細資訊。Errors 集合裡面至少會有一個型態為SqlError 的物件。

下面的程式碼區塊是用來說明用 SQL Server .NET Data Provider 如何處理 SQL Server 錯誤 :

using System.Data;
using System.Data.SqlClient;
using System.Diagnostics;

// Method exposed by a Data Access Layer (DAL) Component
public string GetProductName( int ProductID )
{
  SqlConnection conn = null;
  // Enclose all data access code within a try block
  try
  {
    conn = new SqlConnection(
        "server=(local);Integrated Security=SSPI;database=northwind");
    conn.Open();
    SqlCommand cmd = new SqlCommand("LookupProductName"， conn );
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Add("@ProductID"， ProductID );
    SqlParameter paramPN = 
         cmd.Parameters.Add("@ProductName"， SqlDbType.VarChar， 40 );
    paramPN.Direction = ParameterDirection.Output;

    cmd.ExecuteNonQuery();
    // The finally code is executed before the method returns
    return paramPN.Value.ToString();  
  }
  catch (SqlException sqlex)
  {
    // Handle data access exception condition
    // Log specific exception details
    LogException(sqlex);
    // Wrap the current exception in a more relevant
    // outer exception and re-throw the new exception
    throw new DALException(
                  "Unknown ProductID: " + ProductID.ToString()， sqlex );
  }
  catch (Exception ex)
  {
    // Handle generic exception condition . . .
    throw ex;
  }
  finally
  {
    if(conn != null) conn.Close(); // Ensures connection is closed
  }
}

// Helper routine that logs SqlException details to the 
// Application event log
private void LogException( SqlException sqlex )
{
  EventLog el = new EventLog();
  el.Source = "CustomAppLog";
  string strMessage;
  strMessage = "Exception Number : " + sqlex.Number + 
               "(" + sqlex.Message + ") has occurred";
  el.WriteEntry( strMessage );

  foreach (SqlError sqle in sqlex.Errors)
  {
    strMessage = "Message: " + sqle.Message +
                 " Number: " + sqle.Number +
                 " Procedure: " + sqle.Procedure +
                 " Server: " + sqle.Server +
                 " Source: " + sqle.Source +
                 " State: " + sqle.State +
                 " Severity: " + sqle.Class +
                 " LineNumber: " + sqle.LineNumber;
    el.WriteEntry( strMessage );
  }
}

在 SqlExceptioncatch 程式區塊中，程式碼一開始使用 LogException 協助程式函式來紀錄例外的細節。這個函式使用了一個 foreach 敘述來列舉 provider特定的Errors集合的細節並且將錯誤的細節紀錄在錯誤紀錄檔中。在 catch 程式區塊中的程式碼用DALException的例外型態來包裝 SQL Server 的特定例外，使這個訊息在 GetProductName 方法中更具有意義。例外處理常式中使用了 throw 這個關鍵字來來把例外傳回給呼叫者。

預存程序衍生的錯誤

Transact-SQL ( T-SQL ) 提供了一個 RAISERROR ( 注意拼法 )函式，你可以用它來產生自定錯誤並傳回給用戶端。對 ADO.NET 的用戶而言，SQL Server .NET Data Provider 攔截這些資料庫錯誤並將它們轉換成 SqlError 物件。

使用 RAISERROR 函式最簡單的辦法就是把傳回訊息內容作為其第一個參數，然後接下來指定嚴重程度跟狀態的參數，如同下面的程式區塊所示。

RAISERROR( 'Unknown Product ID: %s', 16, 1, @ProductID )

在這個範例中，我們傳回了一個替代參數Ȅ現在的 product ID 作為錯誤訊息的一部分。第二個參數是關於嚴重程度的訊息，第二個參數是關於狀態的訊息。

如何適當的描述嚴重程度

必須慎選錯誤的嚴重程度並了解其所帶來的影響。錯誤嚴重程度的範圍是從 0 到 25 是用來指出 SQL Server 2000 所遭遇到的問題。在用戶端的程式碼中，應該可以在 SqlException 類別中的 Errors 集合裡的 SqlError 物件中 Class 屬性裡找到關於錯誤嚴重程度的訊息。表格 1 列出了各種錯誤嚴重程度的意義跟影響。

表格 1. 錯誤嚴重程度意義跟影響

嚴重程度	連結是否關閉	產生 SqlException	意義
10 或以下	否	否	回報資訊訊息不一定是錯誤狀況。
11-16	否	是	可以被使用者更正的錯誤，例如 : 重複操作已修改的輸入資料。
17-19	否	是	資源或是系統錯誤。
20-25	是	是	嚴重的系統錯誤 (包括硬體錯誤)。用戶端連結關閉。

控制自動交易

SQL Server .NET Data Provider 當任何錯誤嚴重程度大於 10 時，都會傳回 SqlException。當元件是偵測到 SqlException的自動 ( COM+ ) 交易的一部分時，元件必須確認是再中止交易 transaction。這可能是自動化的程序也可能不是，主要是看方法是否有標明 AutoComplete屬性。

如果想取得更多關於自動化交易如何處理 SqlException的資訊，請至本文中的決定交易結果章節查閱。

取得資訊訊息

嚴重程度 10 或是以下通常都是代表資訊訊息而不會引發 SqlException 。

如何取得資訊訊息:

•	建置一個事件處理常式用來處理 SqlConnection 物件的 InfoMessage事件。事件的傳遞正如以下程式碼區塊所述 public delegate void SqlInfoMessageEventHandler( object sender， SqlInfoMessageEventArgs e );

訊息資料可以透過 SqlInfoMessageEventArgs 物件傳遞到你的事件處理常式。這個物件有Errors 屬性，內容包含一個 SqlError 物件的集合—一個物件對應一個資訊訊息。以下的程式碼區塊說明如何註冊一個事件處理常式用來紀錄資訊訊息。

public string GetProductName( int ProductID )
{
  SqlConnection conn = null;
  try
  {
    conn = new SqlConnection(
        "server=(local);Integrated Security=SSPI;database=northwind");
    // Register a message event handler
    conn.InfoMessage += new SqlInfoMessageEventHandler( MessageEventHandler );
    conn.Open();
    // Setup command object and execute it
    . . .
  }
  catch (SqlException sqlex)
  {
    // log and handle exception
    . . .
  }
  finally
  {
    if(conn != null) conn.Close();
  }
}
// message event handler
void MessageEventHandler( object sender, SqlInfoMessageEventArgs e )
{
  foreach( SqlError sqle in e.Errors )
  {
    // Log SqlError properties
    . . .
  }
}

回到頁首

效能

這個章節介紹一些資料存取的案例，而對每一個案例，我們都會詳細介紹它使用 ADO.NET 資料存取程式碼撰寫的，具調整性而且效能提升到極致的解決方案。並且比較其中的適合度，效能\公共能性，以及開發所需的一切。這個章節主是要介紹下列幾的方案：

•	擷取結果集合並且以其中的資料列進行計算。
•	使用特定的主索引鑑擷取單列資料。
•	從特定資料列中擷取單一項目。
•	檢查具有特定主索引鍵的資料列是否存在。這是一個單一項目查找方案的變化只要傳回布林值即可。

擷取多列資料

在此案例中，你想要擷取出一個表格化的資料集合然後計算擷取出的資料列來進行操作。舉例來說，可能想擷取出一個資料集合，在離線狀態下處理它，並且把它當成 XML 文件 ( 或是透過 Web service) 來傳遞給用戶端應用程式。或者，你可能想把資料用 HTML 的表格將其呈現出來。

為了幫助你了解什麼是最適合的資料存取方法，考慮你需要的究竟是高靈活度的 ( 離線 ) DataSet 物件，或是提供原始效能的 SqlDataReader 物件，哪一個才是最適合在 business-to consumer (B2C) 網路應用程式中作資料呈現。圖 4 展示出兩個基本案例。

附註 : SqlDataAdapter用來填入在 DataSet 內部，以使用 SqlDataReader 來存取資料。

Figure 1.4. Multiple row data access scenarios

圖 1.4. 多列資料存取案例

比較可供選擇的方案

當你想要從資料來源擷取出多個資料列，總共有以下幾種選擇 :

•	使用 SqlDataAdapter物件來產生 DataSet 或是 DataTable。
•	使用 SqlDataReader 來提供一個唯讀的，順向類型資料流。
•	使用 XmlReader t來提供一個唯讀的，順向類型XML資料流。

在 SqlDataReader 和 DataSet/DataTable之間的選擇是個很基本的效能對功能性的抉擇。 SqlDataReader 提供了最佳效能 ; DataSet 提供了額外的功能及變動性。

資料繫結

這三個物件對資料繫結控制項都而言都是資料來源，雖然可以用DataSet 和 DataTable 作為資料來源的控制項，比用 SqlDataReader的多。這是因為DataSet 和 DataTable 有實作 IListSource ( 產生 IList)，而 SqlDataReader 是實作 IEnumerable。而許多的能使用資料繫結的WinForm 控制項都需要實作 IList的資料來源。

這兩者間的差異是因為在設計時所預想的使用案例型態就不同。 e DataSet ( 這是包含了 DataTable) 是個同時適用網路跟桌上型 ( WinForm ) 案例的內容豐富的離線架構。而另一方面， data reader 則是用來進行網路應用程式的最佳化還需要最佳化順向類型資料存取。

確認你想要進行資料繫結的控制項的資料來源需求。

在應用程式層次中傳遞資料

DataSet 提供了資料的關聯式檢視還可以選擇要如同 XML 般地操作，並且可以對資料作離線快取複製以用來在在應用程式層次及元件中中傳遞。然而，SqlDataReader提供的則是最佳的效能因為它可以避免為了創建DataSet所造成的效能與記憶體的浪費。還記得創建DataSet物件會造成許多子物件的產生嗎 — 包括 DataTable， DataRow，還有 DataColumn 物件 — 還有作為這些物件的容器的集合物件。

使用 DataSet

在下列的狀況下，用SqlDataAdapter物件來更新DataSet :

•	你需要資料的離線常駐型快取，好讓你可以在應用程式中將其傳遞到其他的元件或層次。
•	你需要在記憶體內作出資料的關聯式檢視以進行 XML 或是非 XML的操作。
•	你想處理由多種資料來源，如: 多個資料庫，資料表，或檔案擷取出來的資料
•	你想使用 SqlDataAdapter的批次更新功能來更新擷取出來的資料列。
•	你想要在資料來源上支援 IList的控制項上進行資料繫結。

附註 : 如果想要更詳細的資訊，請到 MSDN 網站閱讀 "Designing Data Tier Components and Passing Data Through Tiers" 網址如下 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp。

使用 SqlDataReader

在下列的狀況下，請使用SqlCommand 物件呼叫 ExecuteReader 方法以獲得SqlDataReader物件 :

•	你要處理很大量的資料 Ȅ 大多是在同一個快取裡。
•	你想減少應用程式佔用的記憶體。
•	你想避免因為創建 DataSet物件而造成的資源浪費。
•	你想要在資料來源上實作IEnumerable的控制項上進行資料繫結。。
•	你希望能將資料存取合理化與最佳化。
•	你所讀取的資料列包含二進位大型物件 ( BLOB ) 欄位。你可以用 SqlDataReader 把 BLOB 資料從資料庫移至可管理區塊，不必一次讀取全部資料。如果想知道如何處理 BLOB 資料，請詳閱本文中處理 BLOB 章節。

使用 XmlReader

在下列的狀況下，請使用SqlCommand 物件呼叫 ExecuteXmlReader 方法以獲得使用XmlReader 物件 :

•	你想要用 XML 的方式來處理擷取資料，但你不想因為創建 DataSet 而造成效能浪費也不想進行資料的離線快取。
•	你想精確使用 SQL Server 2000 的 FORXML 子句，使從資料庫擷取出來的資料用 XML 區塊 (就是 XML 文件沒有 root 項目 ) 。例如，這個方法可以讓你精準地指定項目名稱，所以應該有項目或是 attribute-centric 的結構描述，所以應該有結構描述應該以 XML 資料的格時回傳等等。

擷取單列資料

在此案例中，你想從資料來源的特定的資料欄位集合中擷取單列資料。舉例來說，你有一個顧客 ID 然後希望找到該顧客的相關資料，或是你有一個產品 ID 然後想擷取產品資訊。

比較可供選擇的方案

如果你想從資料庫中擷取單列資料，你可以使用之前討論的多列資料擷取與整合案例中的做法，用 SqlDataAdapter 來更新 DataSet 或是 DataTable 。然而，除非你特別需要 DataSet/DataTable的功能，否則應該儘量避免創建這些物件。

如果你想擷取單列資料，請於下列方法中擇一進行 :

•	使用預存程序輸出參數。
•	使用 SqlDataReader 物件。

兩種選擇都能避免因為在伺服器上創建結果集以及在用戶端上創建 DataSet 物件而造成的無謂效能浪費。兩種方法的效能比較基本上是由資料庫的負荷程度以及是否啟用連結公用來決定。當資料庫開啟連結共用並在高負荷程度狀態下 ( 有 200 個連結同時進行 )，效能測試證明使用預存程序的方法比使用 SqlDataReader 提高 30% 的效能。

使用預存程序輸出參數

當你想要在啟用連結共用的多層式應用程式中擷取單列資料，請使用預存程序輸出參數。

使用 SqlDataReader

在下列的狀況下，請使用SqlDataReader :

•	你需要資料值以外的中繼資料。你可以使用 data reader 中的 GetSchemaTable 來取得欄位中繼資料。
•	你沒有使用連結共用。在連結共用關閉的情況下，不論資料庫的負荷狀況如何，使用 SqlDataReader 都是一個好的選擇 ; 在一樣有 200 個連線的狀況下，效能測試證明這種方法會比使用預存程序的方法提高 20% 的效能。

擷取單一項目

在此案例中，你想要擷取資料中的單一項目。舉例來說，你也許會想用產品 ID 查找單一產品的名稱，或是某位顧客的信用程度，或是某位顧客的姓名。這樣的案例中，通常不會想用 DataSet 或是 DataTable。

你也可能單純地只是想確認某個資料行是否存在於資料庫中。舉例來說，當新的使用者在網站上註冊時，你需要去確認他所選定的使用者名稱是否已經存在。這是一種單一項目查找的特例，但在這種狀況下回傳值只需要是一個布林值。

比較可供選擇的方案

當你想要擷取資料中的單一項目時，請考慮以下方案 :

•	使用 SqlCommand 物件中的 ExecuteScalar 方法以及預存程序。
•	使用預存程序輸出或回傳參數。
•	使用 SqlDataReader 物件。

ExecuteScalar 方法會直接回傳資料項目，因為它本來就是為了只回傳單一資料值的查詢而設計。它所需要的程式碼比其他的兩個方法都要少。

就效能的觀點而論，你應該使用使用預存程序輸出或回傳參數。因為測試結果證明，使用預存程序的方法不論資料庫是在低'負荷狀態或高負荷狀態( 從少於100個連結到200個連結 ) ，效能都變動不大。

透過防火牆連結

你將常常需要設定網際網路應用程式以透過防火牆連結 SQL Server 。舉例來說，許多網路應用程式有一個重要的架構元件，而它們的防火牆是周邊網路 ( 也被稱作 DMZ 或是非軍事區域 )，其功用是隔離前端網頁伺服器跟內部網路。

透過防火牆連結 SQL Server 需要對防火牆，用戶端，以及伺服器進行特別的設定r。SQL Server 特別提供了用戶端網路公用程式和伺服器網路公用程式用來進行設定。

選擇網路函式庫

透過防火牆連結 SQL Server時，使用 SQL Server TCP/IP 網路函式庫可以簡化設定工作。在 SQL Server 2000 中安裝時就預設好了。如果你使用的是之前版本的 SQL Server，確認你可以使用用戶端網路公用程式和伺服器網路公用程式，透過用戶端及伺服器端的網路函式庫，設定 TCP/IP。

除了設定上的方便外，使用 TCP/IP 函式庫還有以下的好處 :

•	處理大量資料的效能提升以及增加了延展性。
•	不用處理關於具名管道的安全性問題。

你必須進行用戶端跟伺服器的 TCP/IP 設定。因為大部分的防火牆都會限制可用來作為網路流通的連接埠，你也必須謹慎思考 SQL Server 要使用的連接埠。

SQL Server的預設是使用連接埠 1433。UDP 連接埠 1434 也可以用來讓 SQL 用戶端在區域網路內連結 SQL servers 。然而，實際執行 SQL Server 2000時，可以在剛啟動時動態指定連接埠。你的網路管理員大概不會答應在防火牆中打開某個範圍的連接埠 ; 因此，當你同時使用 SQL Server 與防火牆時，要使用伺服器網路公用程式來這設定專用的t連接埠。你的網路管理員就可以設定防火牆允許特定的 IP 和連接埠進行網路傳輸。

附註 : 用戶端網路應用程式所使用動態指定連接埠，通常是從 1024 - 5000。這是標準的 TCP/IP 用戶應用程式，但這也意味者你的防火牆必須允許這麼大範圍的連接埠使用。如果想取得更多關於 SQL Server 使用的連接埠資訊，請參閱 Microsoft Knowledge Base article 287932，點選右方連結進入 "INF: TCP Ports Needed for Communication to SQL Server Through a Firewall。"

命名執行個體的動態探索

如果你改變了 SQL Server 連接埠，設定你的用戶端透過該連接埠進行連結。關於其中細節，請參閱本文中的設定用戶端章節。

如果你改變了 SQL Server 2000 的預設執行個體的連接埠，沒有修改用戶端設定將會造成連結錯誤。如果你有多個 SQL Server 執行個體，最新版的 MDAC 資料存取堆疊 ( 2.6 ) 可用動態探索並且使用 User Datagram Protocol (UDP) negotiation ( 透過UDP 連接埠 1434 ) 來找到命名執行個體。雖然這在開發環境中是可行的，但在生活環境中應該不大可能，因為防火牆通常都是封鎖 UDP negotiation 的傳輸。

為了避開這個問題，只能設定你的用戶端用目標所開放的連接埠連結。

設定用戶端

你應該正確設定用戶端以使用 TCP/IP 網路函式庫來連結 SQLServer，而且你應該確認用戶端有設定正確的連接埠來連結。

使用 SQL Server 用戶端網路公用程式來進行用戶端設定。有的時候，這個公用程式並沒有安裝在用戶端 (例如，你的網頁伺服器 )。在這種狀況下，你可以使用下列方法 :

•

在連結字串中，使用 "Network Library=dbmssocn" 這樣的名稱值組，來指定所使用的網路函式庫。關鍵字"dbmssocn" 就是用來識別 TCP/IP (sockets) 函式庫的。

附註 : 使用 SQL Server .NET Data Provider 時，網路函式庫的預設值是 "dbmssocn"。

•

修改用戶端中的系統登錄檔，讓 TCP/IP 成為預設函式庫。如果想取得更多關於設定 SQL Server 網路函式庫的資訊，請至以下網址 HOWTO: Change SQL Server Default Network Library Without Using Client Network Utility (Q250550)。

指定連接埠

如果你的 SQL Server 的執行個體不是使用預設的 1433 連接埠，你可以用下列方法指定連結用的連接埠 :

•

使用用戶端網路公用程式。

•

使用在連結字串中 "Server" 或是 "Data Source" 的名稱值組，來指定連接埠。字串的格式如下 :"Data Source=ServerName， PortNumber"

附註 : ServerName 也可以是 IP 位址或是 Domain Name System (DNS) 所給的名稱。就效能的最佳化而言，應該要使用 IP 位址以避免 DNS 的查找。

如果你有開發過服務元件使用 COM+ 分散式交易跟 Microsoft Distributed Transaction Coordinator (DTC) 的服務，你也需要設定你的防火牆好讓 DTC 的不同實體間，以及 DTC 跟資源管理者如 SQL Server 間，可以互相傳輸。

如想取得更多關於開啟連接埠以供 DTC 使用的相關資訊，請至以下網址 INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall。

回到頁首

處理 BLOB

當今，許多應用程式除了傳統的字元及數據資料之外，還需要處理資料格式，像是圖形和聲音，甚至是更精緻的資料格式，如影像一類的。這些圖形，聲音，以及影像的格式有著多種不同的型別。然而，從儲存的角度來看，這些通通可以被視為二進位資料，通常被稱為二進位大型物件，或是 BLOB。

SQL Server 提供了 binary， varbinary，和 image 資料型別來儲存 BLOB。盡管它應該是二進位資料，不過 BLOB 資料也可以被視為文字資料。舉例來說，你也許會想要一個可以儲存任意長度的筆記欄位並且用某個特定資料列來與其聯繫。SQL Server 提供了ntext 和 text 資料型別來達成這個目的。

一般而言，當二進位資料小於 8 KB，使用 varbinary。超過這個大小的二進位資料，使用 image。表個 2 標明了每個型別的主要特色。

表格 2。 Data Type Features

資料型別	大小	描述
binary	從 1 byte 到 8，000 bytes。儲存時的大小是指定長度再加 4 bytes。	固定長度的二進位資料
varbinary	從 1 byte 到 8000 bytes。儲存時的大小是資料的實際長度再加 4 bytes。	長度不定的二進位資料
image	長度不定的二進位資料，大小從 0 到 2 GB。	大規模，長度不定的二進位資料
text	長度不定的二進位資料，大小從 0 到 2 GB。	字元資料
ntext	長度不定的二進位資料，大小從 0 到 2 GB。	Unicode 字元資料

附註 : ®Microsoft SQL Server 2000 支援在資料列中儲存小型到中型的 text，ntext 和 image 的資料值。這項功能在資料表的 text， ntext以及 image 資料欄位都是一次以一單位進行讀寫而且大部分在此資料表執行的敘述都會使用此三型別的時候，相當地有用。您可以在 SQL Server 線上說明文件中的 "text in row" 項目下，找到更清楚的資訊。

BLOB 資料應該存放在何處

SQL Server 7.0 及之後的版本提高了處理資料庫中BLOB 資料的效能。這樣做的理由之一是因為資料庫的分頁檔增大為 8 KB。因此，文字或圖片資料小於 8 KB 的不需要將其儲存在不同分頁中，而是可以儲存在單一資料列中。這意味著讀寫 text， ntext，或 image資料可以跟讀寫字元跟二進位字串一樣快。超過 8 KB的話，則是在資料列中存入指標，而實際資料存放在二元樹結構的不同分頁檔中，當然這必然會造成效能上的影響。

如果想知道更多關於將 text， ntext以及image資料存入單一資料列的相關資訊，請參考 SQL Server線上說明文件的 "Using Text and Image Data" 主題。

一個通常用來處理 BLOB 資料的方法是將 BLOB 資料存放在檔案系統中，然後在資料庫欄位中紀錄所存放檔案的指標 (最好是用 Uniform Resource Locator [URL] 連結 ) 。在 SQL Server 7.0 以前的版本，將 BLOB 存放在資料庫外部的檔案系統中可以改善效能。

然而，在 SQL Server 2000 中改善了對 BLOB 的支援性，加上 ADO.NET 支援讀寫 BLOB 資料，讓直接把 BLOB 資料儲存在資料庫中成為可行方案。

BLOB 資料儲存在資料庫的優點

BLOB 資料儲存在資料庫中會有下列的幾項優點 :

•	在資料列中進行 BLOB 資料與其他項目的同步比較容易。
•	BLOB 可以用資料庫備分。只使用一個儲存系統可以減輕管理上的負擔。
•	可以透過 SQL Server 2000中所支援 XML 來直接存取BLOB 資料。SQL Server 2000 可以用 XML 資料流回傳 64 位元編碼資料。
•	SQL Server Full Text Search (FTS) 操作可以用來搜尋欄位中的固定長度字元 ( 包括 Unicode ) 資料。你也可以在 image 欄位中使用 FTS 來找編碼後的文字資料。例如，Microsoft Word 或是 Microsoft Excel 文件。

BLOB 資料儲存在資料庫的優點的缺點

仔細思考什麼樣的資源應該是儲存在檔案系統中比儲存在資料庫中好。最好的例子就是圖片，通常是用 HTTP HREF 來作為位置參考的。這是因為:

•	從資料庫中擷取圖片絕對是比從檔案系統中擷取來得耗費資源。
•	資料庫 SAN 上的磁碟儲存裝置通常是比網頁伺服器的磁碟儲存要來得貴。

附註 : 一個精心策劃的中繼資料策略可以除去將資源如 : 圖片，電影， Microsoft Office 文件存入資料庫的需求。中繼資料是可以索引化的還包含對檔案系統上資源的指標。

將 BLOB 資料寫入資料庫

下列程式碼示範了如何使用 ADO.NET 將檔案中的二進位資料寫入 SQL Server 中的 image 欄位。

public void StorePicture( string filename )
{
  // Read the file into a byte array
  using(FileStream fs = new FileStream(filename, FileMode.Open, FileAccess.Read))
  {
    byte[] imageData = new Byte[fs.Length];
    fs.Read( imageData, 0, (int)fs.Length );
  }

  using( SqlConnection conn = new SqlConnection(connectionString) )
  {
    SqlCommand cmd = new SqlCommand("StorePicture", conn);
    cmd.CommandType = CommandType.StoredProcedure;
    cmd.Parameters.Add("@filename", filename );
    cmd.Parameters["@filename"].Direction = ParameterDirection.Input;
    cmd.Parameters.Add("@blobdata", SqlDbType.Image);
    cmd.Parameters["@blobdata"].Direction = ParameterDirection.Input;
    // Store the byte array within the image field
    cmd.Parameters["@blobdata"].Value = imageData;
    conn.Open();
    cmd.ExecuteNonQuery();
  }
}

將 BLOB 資料從資料庫讀出

當我們透過 ExecuteReader 方法，使用 CommandBehavior.SequentialAccess 列舉型別值，來創建 SqlDataReader 物件以讀取含有 BLOB 資料的資料列。如果不用列舉型別值，reader 會由伺服器一次取一列資料到用戶端。如果資料列中有 BLOB 欄位，這很可能會佔用大量的記憶體空間。藉由使用列舉型別值，你可以進行較佳的階層控制，因為 BLOB 資料將只有在使用到時才會載入 ( 舉例來說，藉由使用 GetBytes 方法，你可以控制每次讀取的 Bytes 數目 )。這將在下列的程式碼區塊中示範。

// Assume previously established command and connection
// The command SELECTs the IMAGE column from the table
conn.Open();
using(SqlDataReader reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess))
{
  reader.Read();
  // Get size of image data?#8364;“pass null as the byte array parameter
  long bytesize = reader.GetBytes(0, 0, null, 0, 0);
  // Allocate byte array to hold image data
  byte[] imageData = new byte[bytesize];
  long bytesread = 0;
  int curpos = 0;
  while (bytesread < bytesize)
  {
    // chunkSize is an arbitrary application defined value 
    bytesread += reader.GetBytes(0, curpos, imageData, curpos, chunkSize);
    curpos += chunkSize;
  }
}
// byte array 'imageData' now contains BLOB from database

附註 : 使用 CommandBehavior.SequentialAccess 你必須要按照嚴格序列順序來存取欄位資料。舉例來說，如果 BLOB 資料在欄位 3，而你也需要欄位 1 跟欄位 2 的資料，你在讀取欄位 3 之前一定得先讀取欄位1 跟 2。

回到頁首

用 DataSet 來進行資料庫更新

資料庫更新的架構隨著 ADO.NET 的問世而有了重大變革。ADO.NET 是設計出來幫助開發可以讓大量用戶及大型資料庫使用的多層式應用程式。而在這方面有些值得注意的重點，特別是:

•	ADO.NET 應用程式通常是將用戶端的應用程式邏輯分開，把商務部分交由中央層，資料整合計算部分交由資料庫層。在實用面來說，這樣的應用程式應該會有較多的批次工作而相對的與資料庫互動的次數變少( 但規模較大 )。
•	ADO.NET 應用程式對更新如何進行有更精準的控制 ( 跟 ADO 以及之前的產品相較之下 ) 。
•	ADO.NET 允許應用程式透過後台資料庫的預存程序來傳遞資料變化，而不是直接操作資料表中的資料列。這是推薦使用的方法。

更新的執行樣本

使用 ADO.NET 從 DataSet 更新資料的過程大致上如下所述:

1.	創建一個 DataAdapter 物件然後將資料庫查詢的結果填入 DataSet 物件。這些資料將成為本地端的快取。
2.	更動本地端的 DataSet 物件。這些更動包括在本地端快取的 DataSet 物件中，更新，刪除，以及插入一個或以上的資料表。
3.	初始化 DataAdapter 的update-related 屬性。這個步驟精準地設定了更新，刪除，或是插入的動作要如何進行。因為這個步驟有很多種方法來處理，至於我們所推薦的方法將在下面的章節 "初使化DataAdapters 以更新" 中討論。
4.	觸發 DataAdapter 的 Update 方法來送出這些擱置的變更。本地端快取的 DataSet 中的每一項變動紀錄都會處理。 ( 沒有造成任何改變的紀錄將會自動被 Update 方法忽略。 )
5.	處理由 DataAdapterUpdate 方法傳出的例外。當要求的變更無法在資料庫中實行時，就會引發例外。

( 還有另外一個方法可以進行更新。你可以用 ExecuteNonQuery 方法直接執行 SQL UPDATE 指令。當你想用程式更新特定資料列時，這個方法就很適合，因為不需要用到 DataSet 物件。)

初使化DataAdapters 以更新

在 ADO.NET 中，你必須要自己撰寫程式碼用來送出資料庫的更新到 DataAdapter 物件上。有下列三種方法可以作到 :

•	你可提供自己的更新邏輯。
•	你可以使用 Data Adapter Configuration Wizard 來產生更新邏輯。
•	你可以使用 CommandBuilder 物件來產生更新邏輯。

建議你你提供自己的更新邏輯。為了節省時間，你可以使用 Data Adapter Configuration Wizard，但是如果你用了，請試著不要在執行階段產生更新邏輯。除非你真的非用不可否則不要用 CommandBuilder 物件，因為它將會嚴重影響效能而且你無法控制物件產生的更新邏輯。此外， CommandBuilder 不能讓你使用預存程序送出更新。

你可以應用程式需要動態產生資料存取邏輯時，使用 CommandBuilder ，例如報表或是資料 extraction 工具。使用 CommandBuilder 可以避免讓這些工具都撰寫自己的程式碼產生模組。

使用預存程序

使用預存程序更新讓資料庫管理員獲得更高等的安全姓以及複雜的資料完整性檢查，而這是動態 SQL 做不到的。舉例來說，預存程序可能可以再執行更新的時候同時在稽核紀錄中插入項目。靠著它的離線查詢最佳化功能，預存程序能夠提供最好的效能。最後，因為預存程序將資料庫結構及應用程式隔離，使得系統維護方便。

因為 ADO.NET 應用程式使用預存程序有相當多的優點而實作的過程也不會直接更動資料庫來得困難，所以幾乎在所有的狀況下都推薦使用這個方法。唯一的例外是如果你必需處理多個後端資料庫，如 : Microsoft Access，而預存程序無法在這些資料庫上使用。在這種狀況下，必須使用查詢命令更新。

同步執行管理

DataSet 物件是設計來支援需要長時間執行的運作進行開放式同步，例如 : 使用者在使用資料時，而你在更新資料。當我們透過 DataSet 向資料庫進行更新時 to the database server，總有下列四種方法管理開放式同步:

•	只包含主索引鍵欄位
•	包含在 WHERE 子句中的所有欄位
•	包含唯一索引鍵以及時間戳記欄位
•	包含唯一索引鍵以及修改的欄位

值得一提的是後面的三個辦法維持資料完整性 ; 而第一個沒有。

這個方法會造成最後的更新會將之前所作的更動都覆蓋掉。 CommandBuilder 並不支援這個方法，但是 Data Adapter Configuration Wizard 就可以。想使用這個方法，須先進入 Advanced Options 標籤頁面然後情除 Use Concurrency 核取方塊的選擇。

這個方法在實際上是不建議使用因為使用者無法得知是否會覆蓋了其他使用者的更動，破壞其他使用者更新的完整性。(所以這個方法只適合在單一使用者的資料庫。)

包含在 WHERE 子句中的所有欄位

這個方法可以讓你的程式碼擷取的資料列或是進行資料更動的資料列，避免因為其他使用者的更動而造成資料被覆蓋。這個方法是 Data Adapter Configuration Wizard 以及SqlCommandBuilder 產生的 SQL 程式碼中預設的使用方法。

但是因為下列因素，這個方法在實際上是不建議使用 :

•	如果資料表增加了新欄位，查詢就必須修改。
•	一般而言，資料庫不會允許你比對兩個 BLOB 值，因為BLOB 的大資料量會造成比對的低效率。 ( 而像 CommandBuilder 與 Data Adapter Configuration Wizard 這個的工具不應該在 WHERE 子去中包含 BLOB 欄位。)
•	比較資料表中所更新資料列的所有欄位會造成多餘的效能浪費。

包含唯一索引鍵以及時間戳記欄位

i使用這個方法，資料庫會在每次的資料列更新後更時間戳記為唯一值。 ( 所以你一定要再資料表中加入時間戳記欄位。) 目前，不論是 CommandBuilder 或是 Data Adapter Configuration Wizard 都不支援這種作法。

包含唯一索引鍵以及修改的欄位

一般而言，這個方法並不建議使用，因為如果你的應用程式邏輯使用過時的資料欄位或是欄位沒有更新都會造成錯誤。舉例來說，使用者 A 更動了訂單數量而使用者 B 更動了單價，這會造成總價 ( 訂單數量乘上單價 ) 的計算錯誤單價。

正確地更新 Null 欄位

當資料庫的欄位不含資料值，通常把這個空的資料欄位是視作擁有一個特別的 null 值。然而，這種想法可能就會是程式設計錯誤的根源，因為資料庫的標準中是需要對 null 值進行特別處理的。

關於 null 欄位的主要問題是在於如果其中一個運算子是 null 值，SQL的 = 運算元會回傳 false 。運算元 IS NULL 是唯一在 SQL 查詢中確認欄位是否為 null 值的方法。

如果你的應用程式使用了前述指定 WHERE 子句的作法來進行同步管理，你就必須在可能出現 null值的欄位精準地使用 IS NULL 運算式。舉例來說，下列的查詢在 OldLastName 是 null 的時候一定會失敗 :

SET LastName = @NewLastName WHERE StudentID = @StudentID AND 
                                  LastName = @OldLastName

應該要被改寫成 :

SET LastName = @NewLastName WHERE (StudentID = @StudentID) AND
                                  ((LastName = @OldLastName) OR
                                   (OldLastName IS NULL AND LastName IS NULL))

閱讀由 CommandBuilder 工具所產生的輸出，是學會如何撰寫出如上所述的的更新邏輯的好方法。

使用強型別DataSet物件

強型別 DataSet 物件將資料庫中的資料表與欄位以物件與其屬性的方式呈現。存取是透過名稱來進行，而不是使用集合中的索引。這意味著你可以了解，強型別 DataSet 物件跟 DataSet 物件在存取資料欄位上的差異 :

string n1 = myDataSet.Tables["Students"].Rows[0]["StudentName"];  // untyped
string n2 = myDataSet.Students[0].StudentName;           // strongly typed

使用強型別DataSet物件，有下列幾項優點 :

•	存取資料欄位的程式碼提高了可讀性而且更為精簡。
•	在 Visual Studio .NET 程式碼編輯器中的 Intellisense capability 功能，可以幫你自動完成你想要輸入的整行程式碼。
•	編譯器可以捕獲強型別 DataSet 中的型別不符錯誤。而在編譯階段偵測錯誤是比在執行階段偵測錯誤來得更好的。

何時使用使用強型別 DataSet 物件

使用強型別 DataSet 是很方便的，因為它能簡化應用程式的開發並減少錯誤發生。特別是在在用戶端的多層式應用程式中，尤其有用。因為該應用程式，主要是著重於圖形化使用者介面以及資料的有效性，所以需要許多欄位的存取操作。

然而，如果資料庫的架構改變了，使用強型別 DataSet就會變得很麻煩，例如欄位和資料表的名稱改變。在這種狀況下，強型別 DataSet 類別比須重新產生而且所有的相關類別都需要修改。

在同一個應用程式中有可能同時使用強型別跟無型別的存取方式。舉例來說，一些開發人員在用戶端使用強型別 DataSet 而在伺服器端使用非型別。強型別 DataSet 的Merge 方法可以用來導入非型別 DataSet 中的資料。

產生 DataSet 類別

.NET Framework SDK 和 Visual Studio.NET 都有提供公用程式以幫助你產生必要的 DataSet 子類別。.NET Framework SDK 中是使用命令列工具與直接撰寫程式碼。而 Visual Studio .NET 的方法，很顯然地是在 Visual Studio .NET 開發環境中，不需要額外的命令視窗。

不論 DataSet 的類別是如何產生的，新的類別都必須參考型別DataSet並部署在所有的應用程式層次中。( 這並不是典型案例，但考慮是否可以用遠端方式在層次間傳遞型別 DataSet也是很重要的。)

.NET Framework SDK 包含了一個命令列公用程式名為 XML Schema Definition Tool，它能夠用 XML 結構描述檔 (.xsd) 幫助你產生類別檔。結合此公用程式與 DataSet 物件的 WriteXmlSchema 方法能把一個非型別 DataSet 轉換成強型別 DataSet。

下列指令了示範如何用 XML 結構描述檔案產生一個類別檔。開啟一個命令列視窗並輸入 :

C:\>xsd MyNewClass.xsd /d

第一個參數是 XML 結構描述檔的路徑。第二個參數是你創建由 DataSet 衍生出來類別檔。這個工具預設是會產生 Visual C# .NET 類別檔，但它也可以加上適當的參數而產生 Visual Basic .NET 類別檔。如果想列出所有可用的選項，請輸入:

xsd /?

類別檔產生完成後，將其加入你的專案中。然後就可以創建你的強型別 DataSet 類別的實體，使用下列 Visual C# .NET 程式碼來進行 :

MyNewClass ds = new MyNewClass();

使用 Visual Studio .NET

要在 Visual Studio .NET 中產生強型別 DataSet，先在表單設計視窗中點擊滑鼠右鍵，然後按下 Generate Dataset。然後就會產生一個 .xsd ( XML Schema Definition ) 檔，以及一個類別檔，然後把他們加入你的專案中。但在這之前請先確認一個或以上的 DataAdapters 已經加入你的視窗表單。注意那個類別檔是隱藏的。想看到類別檔，按下方案總管視窗中工具列上的 Show All Files 。

要在強型別 DataSet 中加入關聯，先在方案總管視窗中的.xsd檔上按兩下開啟 XML 結構描述設計工具，然後在你想加入的資料表上點右鍵。在快顯功能表中，選擇 Add New Relation。

在 Visual Studio .NET 中產生強型別 DataSet 的另外一個方法是在專案總管中專案上點擊右鍵，選擇 Add Files，然後選擇 dataset。就會建立一個新的 .xsd 檔。然後你可以在伺服器總管中聯結至資料庫並且把資料表拖曳至 xsd 檔上。

回到頁首

處理 Null 資料欄位

以下是關於如何在 .NET 資料架構中使用 null 欄位的技巧:

•	一定要用System.DBNull類別來設定資料欄位值為 null 。不要使用 C# 或 Visual Basic .NET 所提供的 null 值。如以下範例所示 : rowStudents["Nickname"] = DBNull。Value // correct!
•	強型別 DataSets 在每個 DataRow含有兩個額外的方法。一個是用來確認欄位是否有為 null 值，另外一個則是將欄位值設為 null。就如同以下的程式碼區塊所示 : If (tds.rowStudent[0].IsPhoneNoNull()) { ..., } tds.rowStudent[0].SetPhoneNoNull()
•	一定要用 DataRow 類別( 或是在之前項目中的同等類別 )中的 IsNull 方法來測試資料庫中的 null 值。這個方法只支援測試資料庫的 null 值。
•	如果資料欄位可能含有 null 值，在使用資料內容時應該先行確認 ( 用 IsNull 方法 ) 。典型的例子是 Integer 資料欄位可能是 null。順帶一提，.NET run time 的 Integer 資料型別是不包含 null 值的。以下是範例 : int i = rowStudent["ZipCode"]; // throws exception if null!
•	使用強型別 DataSet 中的 nullValue 註解來設定資料庫中的 null 值應該如何對應。預設是回傳例外 ; 然而為了達到更佳的程式控制，你可設定將 null 值轉換為特定值，如 String.Empty。

回到頁首

交易

實際上，所有的商務導向應用程式在更新資料時都需要交易的支援。交易，透過提供有名的 ACID : 不可部分完成(atomicity)，一致性( consistency )，隔離( isolation )以及耐久性(durability ) 的四種基本保障，而使得系統的整合狀態可以包含一個或以上的資料來源。

舉例來說，一個用以處理購買訂單的網頁型零售應用程式。每個訂單都需要三個不同的操作並進行三個資料庫的更新 :

•	庫存數量因為訂單而減少了。
•	客戶的信用額度因為購買行為而減少。
•	一個新的訂單必須加入訂單資料庫。

基本上這三個不同的操作必須當作一個單位來執行，不能只有部分完成。它們必須都能成功執行，或是全都失敗，其他的狀況都會引起資料整合上的問題。交易可以提供這樣及其他的保障。

有關交易處理的基礎相關資訊，請至以下網址 http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpcontransactionprocessingfundamentals.asp。

有很多方法可以將交易管理併入資料存取程式碼中。每個方法都有一到兩種適合的程式設計模式 :

•	手動交易。你使用支援交易功能的 ADO.NET 或是 Transact-SQL 直接在元件中撰寫程式碼或預存程序。
•	自動 (COM+) 交易。你在執行階段指定物件交易需求的 .NET 類別中加入宣告式屬性。這個模式可以讓你簡單地設定多個元件處理同樣的交易。

雖然自動交易模式能有效簡化分散式交易的處理，但這兩種技術都有被用來處理本地交易 ( 交易只在單一資源管理者如 SQL Server 2000 上執行 ) 或分散式交易 ( 交易在遠端電腦上的多重資源管理者間執行 )。

你可會因為程式設計模式的方便而使用自動 (COM+) 交易。當你再系統中有很多元件要執行資料庫更新時，這個優點就特別的明顯。然而，在很多案例中，你應該避免使用這種交易模式以免造成多餘的資源浪費及效能下降。

這個章節將要幫助你依照應用程式的需求而選擇最合適的方案。

要選擇交易模式，你應該首先考慮你是否需要使用交易。交易是會讓伺服器應用程式耗費最多資源的運作，如果在非必要的狀況下使用將會降低程式的可延展性。請藉由下列的指南來思考如何使用交易 :

•	只有在你需鎖定一群操作並且需要強制執行ACID原則時，才使用交易。
•	儘量把交易的時間縮短以減少對資料庫的鎖定。
•	在控制交易生命週期中絕對不要放置用戶端。
•	不要對單一的 SQL 敘述使用交易。SQL Server 會自動把每個敘述是為獨立交易。

自動交易 vs. 手動交易

雖然自動交易的程式設計模式是比較簡化的，特別是當多個元件在執行資料庫更新的時候，但手動的本地交易很明顯是比較快的，因為它不需要與 Microsoft DTC 互動。即使你在本地的單一資源管理者 ( 如 SQL Server) 上進行自動交易，但是因為本地的手動交易會避免使用 DTC 進行任何非必要的程序之間通訊 (IPC)，所以前述狀況還是成立 ( 雖然效率間的差距有縮小 )。

在下列狀況請使用手動交易:

•	你要對單一資料庫執行交易。

在下列狀況請使用自動交易:

•	你需要在多個遠端資料庫間執行單一交易。
•	你需要一個交易來包含多個資源管理者。例如，一個資料庫和 Windows 2000 Message Queuing ( 通常被稱為 MSMQ )資源管理者。

附註 : 不要將交易模式混用。請只使用其中一種。

在一般應用程式案例中，自動交易的效能已經足夠，所以我們應該使用自動交易來簡化程式設計模式 ( 即使是要在單一資料庫上使用 )。自動交易讓使用者可以輕易地使多重元件執行同一交易中的部分操作。

使用手動交易

使用手動交易，你使用支援交易功能的 ADO.NET 或是 Transact-SQL 直接在元件中撰寫程式碼或預存程序。在大部分的狀態下，你應該在預存程序中進行交易控制。因為這種做法提供了高等封裝，而且從效能的角度來看也不遜於用 ADO.NET 程式碼執行交易。

用 ADO.NET 執行手動交易

ADO.NET 支援交易物件，讓你用來開始新交易並且能準確控制何時要送出或復原交易。交易物件會透過連結物件的 BeginTransaction 方法來取得資料庫的連結。呼叫這個方法時不需包含接下來要交易中執行的命令。你只需要透過設定命令物件 Transaction 屬性，就可以準確地連結交易跟每個命令。既然你能連結交易物件跟多個命令物件，所以就能將複數個操作包成單一交易對單一資料庫運作。

如果想取得使用 ADO.NET 交易的範例程式碼，請到附錄中的如何撰寫 ADO.NET 手動交易。

用預存程序執行手動交易

你可以使用預存程序中的 Transact-SQL 敘述直接控制手動交易。舉例來說，你可以在預存程序中使用BEGIN TRANSACTION， END TRANSACTION，和 ROLLBACK TRANSACTION這幾個 Transact-SQL 交易敘述來執行手動交易。

使用自動交易

自動交易簡化了程式設計模式，因為你不需要自行開啟新交易或是送出或放棄交易。然而，自動交易最重要的優點是可以與 DTC 結合，這讓單一交易可以在多個分散式資料來源間執行。在大規模的分散式應用程式中，這項優點特別有意義。雖然可以透過 DTC 的程式設計來直接手動控制分散式交易，但自動交易大幅地簡化了這樣的作業並且是為了以元件為基礎的系統設計的。舉例來說，它可以很容易地設定多個元件執行同一交易中的不同工作。

自動交易主要是靠 COM+ 提供的分散式交易支援功能，也因此，只有服務元件 (就是由 ServicedComponent 類別衍生出來的元件 ) 可以使用自動交易。

如何設定一個自動交易類別 :

•	用 System.EnterpriseServices 命名空間中的 ServicedComponent 類別衍生類別。
•	使用 Transaction 屬性定義類別的交易需求。由 TransactionOption 列舉型別中定義的值可以決定在 COM+ catalog 中該類別應該要如何設定。用這個屬性也可以進行其他相關設定，如交易隔離層和等待時間。
•	為了避免必須直接處理交易產生的結果，你可以用 AutoComplete 屬性來加註在方法上。如果這些方法回傳例外，交易可以自動取消。當然如果有需要你還是可以直接處理交易結果。關於其中的細節，請參閱下面的 Determining Transaction Outcome 章節。

設定交易隔離層

COM+ version 1.0 ( 在Windows 2000 上執行的 COM+ ) 的交易隔離層是 Serialized。雖然這樣提供了高度的隔離，換來的卻是效能上的犧牲。因為資源管理者( 通常是資料庫 ) 在交易進行中必須同時維持讀取和寫入鎖定，所以導致系統的整體效能下降。在這種時候，其他的交易都是被封鎖的，這會對你的應用程式的延展性造成很大的影響。

COM+ version 1.5，是搭載在 Microsoft Windows .NET 中，允許在 COM+ catalog 以元件為單位設定交易隔離層。T其中關於根元件的交易隔離層設定就會決定該交易的隔離層。此外，在同一交易中的內部子元件的隔離層不能設定得比根元件的隔離層還高。如果真的這樣設定，在子元件初始化時將會引發錯誤。

對 .NET 管理類別而言，Transaction 屬性支援公開的 Isolation 屬性。你可以用這個屬性來宣告特定的隔離層，就如以下程式碼所述。

 [Transaction(TransactionOption.Supportedm, Isolation=TransactionIsolationLevel.ReadCommitted)]
public class Account : ServicedComponent
{
  ...
}

決定交易結果

自動交易的結果是由 transaction abort flag，跟 consistent flags，以及交易過程中所有相關元件的內容來決定。交易結果是在交易中的根元件停止運作時 ( 會把控制權回傳給呼叫者 )決定。在圖 5 中，展現出的是典型的銀行基金傳輸交易。

Figure 1.5. Transaction stream and context

圖 1.5. 交易過程與內容

交易結果是在根物件 (在範例中，是 Transfer 物件 ) 停止運作時決定，然後用戶端的方法將會回傳。如果交易內容中有任何的 consistent flags 被設為 false，或是 transaction abort flag 被設為 true，實際上的 DTC 交易會被取消。

你可以用 .NET 物件透過下列兩種方法之一來控制交易結果 :

•

你可以用 AutoComplete 屬性來加註方法，然後讓 .NET 自動處理交易結果。透過這個屬性，如果方法回傳例外，consistent flag 會自動被設為 false ( 這最後會導致交易取消 )。如果方法沒有回傳例外，consistent flag 會被設為 true，這代表交易應該要被送出。這個方法其實不太有保障，因為它要透過同一交易中其他物件的參與。

•

你可以呼叫 ContextUtil 類別中的 SetComplete 或是 SetAbort 靜態方法，這可以直接設定 consistent flag 為 true 或 false。

SQL Server 錯誤嚴重程度大於 10 會造成 managed data provider 回傳 SqlException 型別的錯誤。如果你的方法捕獲並處理了這個例外，確認你有手動取消這個交易，或是對有標明 [AutoComplete] 的方法，確認這個例外有回傳給呼叫者。

[AutoComplete] 方法

對有標明 AutoComplete 屬性的方法，請進下列動作之一 :

•	回傳 SqlException 到呼叫堆疊。
•	把 SqlException 包裝成一個外部例外並且回傳給互較者。你可能會想把原來的例外包裝好讓呼叫者更好處理。

回傳例外失敗會造成物件沒有正確地取消交易，儘管資料庫已經發生錯誤。這代表由其他物件執行的成功操作可能已經送出。

下列程式碼會捕獲 SqlException ，並且將其直接回傳給呼叫者。而交易最後會被取消。因為當物件停止運作時，物件的 consistent flag 會自動被設為 false。

 [AutoComplete]
void SomeMethod()
{
  try
  {
    // Open the connection, and perform database operation
    . . .
  }
  catch (SqlException sqlex )
  {
    LogException( sqlex ); // Log the exception details
    throw;                 // Rethrow the exception, causing the consistent 
                           // flag to be set to false.
  }
  finally
  {
    // Close the database connection
    . . .
  }
}

非 [AutoComplete] 方法

對沒有加註 AutoComplete 屬性的方法，你必須 :

•	在 catch 程式區塊中呼叫 ContextUtilSetAbort 方法以取消交易。這會讓 consistent flag 設為 false。
•	如果沒有發生例外，則呼叫 Call ContextUtil.SetComplete 以送出交易。這會讓 consistent flag 設為 true ( 這是它的預設狀態 )。

下列程式碼就是示範。

void SomeOtherMethod()
{
  try
  {
    // Open the connection, and perform database operation
    . . .
    ContextUtil.SetComplete(); // Manually vote to commit the transaction
  }
  catch (SqlException sqlex)
  {
    LogException( sqlex );   // Log the exception details
    ContextUtil.SetAbort();  // Manually vote to abort the transaction
    // Exception is handled at this point and is not propagated to the caller
  }
  finally
  {
    // Close the database connection
    . . .
  }
}

附註 : 如果你有很多 catch 程式區塊，方法的開始處呼叫的 ContextUtil.SetAbort 一次就好，並且在 try 程式區塊的結尾呼叫 ContextUtil.SetComplete。這樣做的話，你就不需要在每個 catch 程式區塊中重複呼叫 ContextUtil.SetAbort。這些方法所設定的 consistent flag 只有在方法回傳時才具有意義。

你一定得把例外 ( 或是包裝過的例外 )回傳到呼叫堆疊，因為這樣才能讓呼叫的程式碼知道交易失敗了。這樣才能讓呼叫的程式碼進行調整。舉例來說，在銀行基金傳輸案例中，如果扣款操作失敗，傳輸元件可以決定不要執行信用操作。

如果你把 consistent flag 設為 false 可是沒有回傳任何例外，呼叫的程式碼就無法得知交易失敗了。雖然你可以回傳一個或一些布林參數，你還是應該回傳例外以指出錯誤狀況。這是用標準的例外處理方法讓程式碼更清晰且具備一致性。

回到頁首

資料分頁

資料分頁是分散式應用程式中的常見需求。舉例來說，使用者可能會想看到書籍清單，但不能一次顯示整個清單。使用者會想要對資料顯示進行人性化的處理，比如說觀看下一頁或上一頁或是跳至清單的開頭或結尾。

這個章節討論的是如何實作這樣的功能，以及各種方案對效能與延展性的影響。

比較可供選擇的方案

進行資料分頁的選擇有 :

•	使用 SqlDataAdapter 中的 Fill 方法將查詢結果中的部分內容填入 DataSet 中
•	透過 COM 的互通性使用 ADO 以及並且使用一個伺服器端的游標
•	用預存程序手段實作資料分頁

要使用什麼樣的方式進行資料分頁，應該要取決於以下因素:

•	延展性的需求
•	效能的需求
•	網路頻寬
•	資料庫伺服器的記憶體與電源
•	中介層伺服器的記憶體與電源
•	你想在一個頁面中回傳多少資料列
•	資料分頁的大小

效能測試證實，使用預存程序手動進行，在各種的負荷狀態下都能擁有良好效能。然而，當你在伺服器上使用這個方法執行工作時，如果你網站上的功能都跟分頁功能相關，伺服器的負荷程度就會成為很重大的問題。為了確定哪個方案適合你的系統環境，最好能每個方法都在你的系統上測試一下。

以下有幾個選擇方案可供討論。

使用 SqlDataAdapter 的 Fill 方法

正如之前所提的，SqlDataAdapter 是用來將資料庫中資料填入 DataSet。多載的 Fill 方法中的一種( 如下列程式碼所述 ) 使用兩個整數索引值。

public int Fill(
   DataSet dataSet,
   int startRecord,
   int maxRecords,
   string srcTable
);

startRecord 是從何處開始紀錄的索引。maxRecords 是從 startRecord 開始，後儲存的紀錄的最大值，然後將這樣內容複製進 DataSet。

內部運作中，SqlDataAdapter 使用 SqlDataReader 來執行查詢並回傳結果。SqlDataAdapter 得到結果後創建 DataSet 準備把回傳後的資料填入。SqlDataAdapter copies 透過 startRecord 和 maxRecords 參數將資料複製當剛產生的 DataSet 並且把不需要的結果資料捨棄。這代表說可能會有很多不必要的資料從伺服器傳輸到用戶端，這是本方法的主要缺點。

舉例來說，如果你有 1000 筆紀錄而你想要第 900 筆到 950 筆，那之前的 899 筆都會透過網路傳到用戶端然後再捨棄。這種資源浪費在小規模的結果回傳時也許還好，但如果是大規模的資料就很嚴重了。

使用 ADO

另外一個方法是用 COM 為基礎的 ADO 來實作。這個方法中的重點是透過伺服器端游標來進行存取，然後將資料導出至 ADO 的 Recordset 物件。你可以設定 Recordset 的游標位置為 adUseServer。如果你的 OLE DB provider 支援這種做法 ( SQLOLEDB 支援 )，就會啟用伺服器端游標。你可以透過這個游標來找尋要開始存取的紀錄，而不用將任何資料透過網路傳到用戶端。

這個方法主要有兩個缺點 :

•

在大多數的情況下，你會想要用管理程式碼把 Recordset 物件中回傳的資料轉會填入 DataSet 中。雖然 OleDbDataAdapter 有 Fill 方法把 ADO 的 Recordset 物件轉換瑱入 DataSet，不過並不能由特定的紀錄開始或結束。實際上只能把手動選擇 Recordset 物件中的開始紀錄，透過迴圈手動把資料複製到 DataSet中。這樣作法所造成的效能浪費，特別是透過 COM 互通呼叫造成的，可能比透過網路傳輸多餘資料還多，尤其是在小型的 DataSet。

•

在你要的資料從伺服器傳輸到用戶端時，你都必須維持連結狀態並開啟伺服器游標。而在資料庫伺服器上使用及維持值這個游標是很耗費資源的。雖然使用這個做法可能會提高你的效能，但卻可能降低程式的延展性以及浪費太多伺服器資源。

使用手動實作

最後所要討論的這種方法是使用預存程序來在你的應用程式中手動實作分頁功能。對有唯一鍵的資料表，你使用預存程序來實作相對上是比較容易。對沒有唯一鍵的資料表 ( 這樣的資料表應該不多 )，相對上就比較困難。

對有唯一鍵的資料表進行分頁

如果你想進行分頁的資料表具有唯一鍵，你可以在 WHERE 使用該索引鍵來建置從特定資料列開始的回傳結果。並配合 SET ROWCOUNT 敘述使用以限制回傳資料集的大小，提供一個有效率的分頁機制。這個方法就如以下的預存程序範例所示 :

CREATE PROCEDURE GetProductsPaged
@lastProductID int,
@pageSize int
AS
SET ROWCOUNT @pageSize
SELECT *
FROM Products
WHERE [standard search criteria]
AND ProductID > @lastProductID
ORDER BY [Criteria that leaves ProductID monotonically increasing]
GO

這個預存程序的呼叫者只要維護 lastProductID 值，並且在連續的程序呼叫間，加減分頁大小的數值。

對不具唯一鍵的資料表進行分頁

如果你想進行�

•	Volume I， Building Secure ASP.NET Applications: Authentication， Authorization， and Secure Communication，位於以下網址http://www.microsoft.com/practices
•	Volume II， Improving Web Application Security: Threats and Countermeasures，位於以下網址 http://www.microsoft.com/practices

•	為了能更有效的管理，要先確認管理者有讀寫 UDL 檔案的權限以及應用程式只有讀取權限。在 ASP.NET 網路應用程式中，應用程式的工作程序預設是以 SYSTEM 帳號運作，雖然你可以透過全機器組態設定檔 (Machine.config)中的<processModel> 項目來改寫。你也可以選擇用 Web.config 檔案中的<identity>項目來模擬指定帳號。
•	在網路應用程式中，確認你沒有把 UDL 檔案放在虛擬目錄下，這會造成該檔案可以透過網路下載。
•	如果想取得更多關於 ASP.NET 功能的資訊安全相關資訊，請參閱 "Authentication in ASP.NET: .NET Security Guidance，" 網址如下http://msdn.microsoft.com/library/en-us/dnbda/html/authaspdotnet.asp。

•	想了解 SqlException 類別的內容細節，請至以下網址 http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDataSqlClientSqlExceptionMembersTopic.asp。
•	如果想知道如何更進一步開發自定例外，紀錄即包裝 .NET 例外，以及使用更多種方式來進行例外傳播，請至以下網址http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp。

•	你不需要明確地進行資料庫連結的開啟或關閉。 SqlDataAdapter 的Fill 方法會開啟資料庫連結並在回傳前關閉。如果連結已經開啟， Fill就會讓連結繼續保持開啟。
•	如果你因為其他的需求而要進行資料庫連結，請儘量使用 Fill 方法。因為這樣你可以避免不必要的開啟 / 關閉連結的動作才能獲得較好的效能。
•	雖然你可以重複使用相同的 SqlCommand 物件以多次執行相同的命令，但請不要重複使用相同的 SqlCommand 物件執行不同的命令。
•	如果想取得用 SqlDataAdapter 更新 DataSet 或 DataTable的範例程式碼，請參閱附錄中的如何使用 SqlDataAdapter 來擷取多列資料。

•	當 data reader 在作用時，會與資料庫保持連結，而且該連結也不能轉作它用。所以不需作用時，請儘快呼叫SqlDataReader的Close 以關閉連結。
•	一個連結只有一個 data reader能用。
•	當你結束 data reader 時，或是 SqlDataReader 物件中連線的生命週期已至，就會藉由傳送 CommandBehavior.CloseConnection的列舉資料型別值到 ExecuteReader 方法中，而將資料庫連結確實關閉。這意味著只有在 SqlDataReader 關閉時，連結才會關閉。
•	當使用 reader 來存取資料時，如果知道資料庫中的欄位資料型態，請使用指定型別存取方法 ( 如 : GetInt32 和 GetString )，因為這樣可以有效減少處理型別轉換問題的時間，提高讀取效率。
•	為了避免無用的資料從伺服器傳送到用戶端，如果你想要關閉 reader 並放棄剩下的資料，請在呼叫 reader 的 Close 方法前先呼叫命令物件的 Cancel 方法。Cancel 可以確保在伺服器端的資料會被棄置而且不會再傳輸多餘的資料到用戶端。相對地，如果直接呼叫 Close 則會造成 reader 傳送多餘的資料。
•	如果你想取得預存程序的輸出結果或是傳回值，請使用 SqlCommand 物件中的 ExecuteReader 方法，而在取得輸出結果或傳回值之前請先呼叫 reader 上的 Close 方法。
•	如果想藉由範例程式碼來了解如何使用 SqlDataReader，請參閱附錄中的如何使用 SqlDataReader 來擷取多列資料。

•	當你使用 XmlReader 讀取資料時，會與資料庫保持連結。而SqlCommand 物件中的 ExecuteXmlReader現在並不支援 CommandBehavior.CloseConnection 的列舉資料型別值，所以你必須在結束reader使用前，自行進行Close。
•	如果想藉由範例程式碼來了解如何使用 XmlReader，請參閱附錄中的如何使用 XmlReader 來擷取多列資料。

•	如果你知道查詢結果只會是單列資料，當你呼叫SqlCommand 物件中的 ExecuteReader方法時，請使用 CommandBehavior.SingleRow 的列舉資料型別值。一些 providers 如 OLE DB .NET Data Provider 可以使用這個訣竅來進行效能的最佳化。舉例來說，這個 provider 使用 IRow 介面來來執行資料繫結一定是比使用 IRowset。１不過這個參數在 SQL Server .NET Data Provider 上無效。
•	如果你的 SQL Server 命令含有輸出參數以及回傳值，在 DataReader 關閉前是無法取得的。
•	當你使用 SqlDataReader 物件時，一定要用 SqlDataReader 物件的指定型別存取方法來擷取輸出參數，例如 GetString 和 GetDecimal。這可以避免無謂的型別轉換。
•	.NET Framework version 1.1 包含了額外的 DataReader 屬性，名為 HasRows，這是用來讓你在 DataReader 讀取資料前決定是否要傳回結果。
•	如果想藉由範例程式碼來了解如何使用 SqlDataReader 物件以擷取單列資料，請參閱附錄中的如何使用 SqlDataReader 來擷取單列資料。

•	I如果查詢正常回傳複數個欄位或資料列，透過 ExecuteQuery 執行只會回傳一個欄位或資料列。
•	如果想藉由範例程式碼來了解如何使用 ExecuteScalar，請參閱附錄中的如何使用 ExecuteScalar 來擷取單一項目。
•	如果想藉由範例程式碼來了解如何使用使用預存程序輸出或回傳參數以擷取單一項目，請參閱附錄中的如何使用預存程序輸出或是回傳參數來擷取單一項目。
•	如果想藉由範例程式碼來了解如何使用 SqlDataReader 物件來擷取單一項目，請參閱附錄中的如何使用 SqlDataReader 來擷取單一項目。

•	ADO.NET 手動的的預設隔離層是 Read Committed，這是當資料被讀取時資料庫對資料進行共用鎖定，但資料在交易結束前可以更動。這可能會造成無法重覆讀取，或是錯覺資料。您可以透過設定交易物件的 IsolationLevel 屬性為 IsolationLevel 定義的列舉型別值來改變隔離層。
•	你必須要在交易謹慎選擇合適的隔離層。這其實是一種效能與資料一致性的權衡。最高等的隔離層 ( Serialized ) 提供絕對的資料一致性，但代價是系統的所有效能。比較地的隔離層可以應用程式更具延展性，但相對的，也會增加資料不一致的錯誤發生機率。對需要大量讀取，少量寫入的系統，較低的隔離層應該是比要適合。
•	如果想獲得有關如何選擇適合的隔離層的珍貴資運，請參閱 Microsoft 出版的書籍 Inside SQL Server 2000，作者是 Kalen Delaney。

•	如果有需要，你可以在預存程序中使用 SET TRANSACTION ISOLATION LEVEL 敘述來控制隔離層。Read Committed 是 SQL Server 的預設隔離層。如果想取得更多 SQL Server 隔離層的資訊，請參閱 SQL Server 線上說明文件的 "Accessing and Changing Relation Data" 章節。
•	如果想藉由範例程式碼來了解如何使用 Transact-SQL 交易敘述執行交易更新，請參閱附錄中的如何使用 Transact-SQL 執行交易。

•	如果想取得更多關於 COM+ 自動更新的資訊，請在 SDK 平台說明文件中搜尋 "Automatic Transactions Through COM+"。
•	如果想要 .NET 交易類別的範例，請參閱附錄中的如何撰寫交易用的 .NET 類別。

.NET 資料存取架構導覽

本頁內容

簡介

誰應該閱讀這份文件

使用須知

更新紀錄

下載 .NET 資料存取架構導覽

簡介 ADO.NET

.NET Data Providers

命名空間組織

泛用程式設計

愈存程序 vs. 直接使用 SQL

屬性 vs. 建構函式引數

管理資料庫連結

使用連結共用

SQL Server .NET Data Provider 進行共用

設定SQL Server .NET Data Provider 連結共用

選擇共用集合的大小

更多相關資訊

用 OLE DB .NET Data Provider 進行連結共用

使用集區物件來管理共用連結

監控連結共用

用 SQL Server Profiler 監控連結共用

用 Performance Monitor 監控連結共用

安全性管理

更多相關資訊

儲存連結字串

使用 XML 應用程式組態檔案

優點

缺點

更多相關資訊

使用 UDL 檔案

優點

缺點

更多相關資訊

使用在 Windows 系統登錄檔

缺點

使用自訂檔案

優點

缺點

使用建構式引述跟 COM+ 類別

優點

缺點

更多相關資訊

連結使用範例

錯誤處裡

.NET 的例外

捕捉與處理 .NET 例外

更多相關資訊

預存程序衍生的錯誤

更多相關資訊

如何適當的描述嚴重程度

表格 1. 錯誤嚴重程度意義跟影響

控制自動交易

取得資訊訊息

效能

擷取多列資料

比較可供選擇的方案

資料繫結

在應用程式層次中傳遞資料

使用 DataSet

更多相關資訊

使用 SqlDataReader

更多相關資訊

使用 XmlReader

更多相關資訊

擷取單列資料

比較可供選擇的方案

使用預存程序輸出參數

更多相關資訊

使用 SqlDataReader

更多相關資訊

擷取單一項目

比較可供選擇的方案

更多相關資訊

透過防火牆連結

選擇網路函式庫

命名執行個體的動態探索

設定用戶端

指定連接埠