數據訪問
uca/udaUDA（universal data access,通用數據訪問，也叫全局數據訪問）是microsoft為企業套用範圍內各種類型信息存取所制定的一項新戰略，它提供對多種數據源進行存取的一致界面。說起數據存取界面，microsoft以前是最令人感到混亂和迷惑的了。從早期的db－library到廣為接受的
odbc，及至近年來基於對象的dao（data access obejct，數據存取對象），rdo（remote data object，遠程數據對象），dao/odbcdirect（dao/odbc直接存取），ado（activex data object，活動數據對象），給用戶的選擇帶來了麻煩，而各種技術之間互不通用，也使得每選擇一種存取界面都要重新學習，加重了開發人員的負擔。因此，uda技術的出現將會結束這種混亂局面。今後只要使用uda即可，而不必勞神費力地在那些存取界面上選擇了。
uda可以看作是應用程式和各種數據之間的一個中間層：uda一方面可以對各種類型的數據源進行高效存取，同時又提供一個獨立於程式語言、開發工具的統一編程界面。這樣，企業可以選用他們所熟悉的，容易使用的開發工具把分散的、完全不同的各類數據源集成起來，創建容易易維護，功能強大的應用程式。
技術
uda並不是一種全新的技術，它是由microsoft以前各種數據存取界面加以綜合發展而來的，並遵循microsoft最新的dcom規範。它的技術基礎是odbc、rdo、dao等這些成熟的，廣泛使用的技術。因此uda以得到業界廣泛支持的工業標準為基礎，所以能夠和目前各主要的資料庫平台一同工作，同時因而容易學習，便於使用。
uda實際是由microsoft的一些數據存取組件（data access components）組成的，它的各個組件用於各種特定的目的，而uda則定義了一種協同工作的機制。這些組件包括activex data object（remote data service（rds，以前稱為advanced database connector，adc），oledb和odbc，其中最重要的是oledb和ado。oledb提供了對底層各種數據源的存取界面，面向數據提供者；ado則向應用程式提供了統一的數據存取界面，面向應用程式開發人員。
綜述
微軟提供了UDA技術作為一個解決方案來解決從多個數據源中運算元據的問題。通過使用UDA技術，你可以通過一個公共的界面集合來到達不同的數據源，比如我們可以使用UDA來操作關係資料庫（比如SQL SERVER，ORALCE）、文本檔案、電子郵件、目錄服務中的目錄系統、OFFICE文檔等等。
UDA包括了一個軟體組件的集合用來和應用程式以及本身進行互動。UDA是基於COM之上的，所以UDA技術是和位置無關、語言無關，並且各個版本都是健壯的。MDAC是UDA的關鍵的實現。MDAC包括了ADO、OLE DB、ODBC、DAO、RDS等組件。ADO可以看成是OLE DB的上層，ODBC只能支持關係資料庫，可以認為是一種過時的技術，DAO主要是用來和ACCESS資料庫進行溝通，RDS是用來在伺服器和客戶機之間通過ADO進行記錄集的傳送，在基於Web的套用中大有作為。
如果大家經常從事在Windows下的資料庫方面的開發工作的話，對ADO、OLE DB、DAO等一定已經不陌生，但是對RDS不一定非常熟悉，因為它主要是用在基於Internet的體系架構上的，所以有必要介紹一下RDS。
當前最新的RDS的版本是2.0,如果你當前用的IIS是4.0版本的話，你的RDS的版本是1.5的，注意只有在安裝了IIS以後，系統才會帶有RDS組件。RDS的目的就是讓ADO的消費者能夠通過遠程的OLE DB提供者來獲取數據，ADO消費者實際上是通過HTTP或者DCOM協定和數據提供者進行聯繫的，客戶端套用可以選擇直接和遠程機器上的OLE DB提供者進行互動，或者是通過和遠程機器上的COM控制項進行互動，發出查詢，接收結果集合。
當採用和OLE DB提供者直接互動這種模式的時候，客戶端套用需要提供給數據提供者需要的所有信息，比如連線字元串和命令字元串。客戶決定需要工作的特定的數據源和需要執行的特定的命令，伺服器端把結果（一般是一個ADO Recordset結果集）返回給客戶.
當採用和COM組件（該組件使用ADO記錄集）互動的模式的時候，客戶端應用程式激活中間件暴露出來的方法，然後把ADO Recordset作為一個參數進行傳遞，這裡表示層和用戶界面層駐留在客戶端，業務邏輯層就駐留在中間件（COM組件）上，數據和引用一致性檢查就在數據源端進行。這是真正的基於多層的開發模式.
在RDS2.0中有了新的內容，那就是開發人員可以直接寫他們自己的伺服器端的商業邏輯，同時能夠使他們的客戶端直接和遠程OLE DB提供者相連而不需要通過商業對象層。 這樣，Web伺服器管理員能夠直接管理從RDS客戶端到來的要求和OLE DB數據源聯繫的請求、並且能夠通過定製的句柄(handler)進行商業邏輯檢查，所謂商業邏輯檢查包括數據有效性檢查等等，它們能夠通過RDS被加到應用程式上去。伺服器管理員可以很容易的編寫他們自己的定製的處理邏輯，為了幫助管理員使用這個定製的特徵，一個簡單的處理句柄(handler)已經被加到了所有基於SQL的OLE DB提供者上。句柄的行為是通過安裝在伺服器上的 ini檔案進行控制的。
當RDS被用來以客戶端應用程式和遠程OLE DB提供者之間直接通訊的模式操作的時候，WEB伺服器上的一個RDS DataFactroy對象用來處理客戶端請求。DataFactory對象實現一個稱為Query的方法來打開一個新的記錄集，它也能夠通過SubmitChanges方法改變記錄集。
在RDS2.0中，DataFactory方法能夠通過編寫一個客戶端對象的方法進行增強，它實現了一個特定的稱為IDataFactoryHandler的接口，開發人員可以建立他們自己的定製的對象來實現IDataFactoryHandler接口。然後這些對象能夠顯式的被DataFactory方法調用來擴展預設的功能。具體的示例代碼如下：
AdorRs ActiveConnection =
"Handler=MyHandler obj;Provider=MS Remote;Remote Server=網址;
DSN=TTMIS_CW;"
AdorRs Source = "Select * from Products"
AdorRs Open
在上面的代碼段中，開發人員可以指定在伺服器端的預設句柄對象為MyHandler obj。當這段代碼被執行的時候，伺服器預設的調用DataFactory對象。但是，在DataFactory對象的方法Query打開一個記錄集的時候，它通過調用接口IDataFactoryHandler來創建MyHandler obj對象，在這個接口中，它調用GetRecordset或者是Reconnect方法，傳遞連線和命令字元串。在句柄的客戶代碼部分能夠打開一個ADO連線或者是記錄集並把它傳遞給對象DataFactory,這樣用戶就可以使用句柄內部的ADO事件來定製連線或者是記錄集對象
當客戶端代碼使用RDS的時候，如果沒有指定句柄的話，DataFactory執行客戶查詢，DataFactory使用ADO和OLE DB提供者進行互動。當客戶端代碼指定了句柄的時候，客戶端請求仍然由DataFactory對象執行，然後DataFactory對象輪流使用指定的句柄來處理客戶的請求。
一個RDS伺服器的客戶端句柄是一個COM自動化對象用來實現IDataFactoryHandler接口，它必須由在註冊表中註冊的ProgID,註冊表的位置如下：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataFactory\HandlerInfo\safehandlerlist
客戶端代碼在打開一個ADO記錄集的時候，必須在連線字元串中包含標籤'handler=;'以便能夠使用指定的句柄。如果使用RDS.Datacontrol來打開記錄集的話，句柄屬性必須設定為句柄的ProgID。伺服器管理員可以強制RDS伺服器使用句柄，當然需要在註冊表的如下位置，插入HandlerRequired=1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataFactory\HandlerInfo
當該註冊項被插入後，所有不包括'handler=;'的RDS請求都會被拒絕。同時必須指向一個有效的定製的句柄對象，這些對象在註冊表的safehandlerlist處進行註冊，具體位置和上面一樣。
為了保證數據通訊的安全性，MDAC2.0安裝了一個預設的定製的句柄對象-MSDFMAP HANDLER。這個句柄的行為是由 ini檔案驅動的，稱為Msdfmap ini。該檔案被安裝在Windows目錄下，伺服器管理員能夠配置該 ini檔案，用來定製MSDFMAP HANDLER的行為。需要注意的是，管理員可以配置多個 ini檔案，如果使用一個不同的 ini檔案的話，在客戶端的連線字元串必須為如下的形式：
RDSCONTROL Handler = "MSDFMAP Handler,myOtherNameSpace ini"
或者也可以為：
Rs open "SQL命令", "Provider=MS Remote;Remote Server=MyWebServerSite;
Handler=MSDFMAP.Handler,myOtherNameSpace ini;Data Source=CustomerDatabase"
最後需要說明的是，用戶可以根據自己的需要定製句柄，句柄包含有兩個方法：
GetRecordset：該方法產生一個新的ADO記錄集，該記錄集必須用 adLockBatchOptimistic的加鎖類型打開，連線和記錄集對象必須把游標位置設定為 adUseClientBatch。
Reconnect:該函式用來產生一個新的ADO連線對象，並且把ADO記錄對象attach到它上面去。連線對象的游標位置必須為adUseClientBatch。
構想
下面是UDA的構想示意圖。
發展前景
uda作為microsoft企業範圍內信息存取的新戰略，得到microsoft的極大重視，有著廣闊的發展前景。最近，各大軟體廠商如sybase、informix、intersolv、ca等均表示支持microsoft的uda技術，說明有著廣泛的套用前景。
microsoft近來提出了“分散式internet應用程式結構”（windows distributed internet applications architecture，dna），作為創建能通過網路傳送的可伸縮的多層（multitier）分散式計算解決方案。uda結構的中心元素，它提供一致的、獨立於工具和程式語言的高級數據界面，統一了client/server、web和各種其他的數據存儲和讀取技術，支持用戶以統一的方式對結構化和非結構化進行存取。
對於應用程式開發人員來說，uda中的高級編程界面ado將成為他們存取各類格式信息的強有力工具。uda的發展，將導致一項新的數據存取結構。在這種結構下，前端應用程式是一致的、通用的，與後端資料庫的具體存取方法相分離；同時後端的信息源可以千差萬別，只要它們都遵循oledb規範，就可以被前端應用程式存取。
對於開發工具供應商，uda技術的採用可以使他們為他們的客戶提供廣泛的數據存取，幫助他們建立功能更豐富、更強健的套用。而dbms廠商更可以利用uda技術為他們的dbms引擎和資料庫提供額外的高效客戶端，從而擴大用戶的選擇範圍。
無疑，uda這種通用的存儲結構，對於降低應用程式開發成本，提供應用程式的可維護性，進而增強企業的競爭力，獲得最大的商業利益，具有極其重要的作用。那么，應當什麼時候轉向uda(或是ado)呢?是不是把現有應用程式都轉換為採用ado呢?在這裡筆者提出兩點建議：
(1)如果你現在正在遠行的應用程式採用的是rdo技術，那么採用rdo就行了，沒有必要把它們轉換到ado。因為microsoft會繼續支持rdo，而且對現在大多數套用來說，rdo是完全滿足需要的。
(2)如果你打算開發新的應用程式，那么就應該採用ado。採用新的具有廣闊發展前途的技術，會為你帶來巨大的收穫。
存取組件
下面具體介紹uda的數據存取組件。
oledb
oledb是uda結構中最重要的組件，它是整個uda技術的基礎。oledb是uda的底層的面向對象的數據存取界面，面向各種數據源，包括關係型資料庫、isam、jet或其他任何數據。它被設計為一種開放的規範，以存取各類數據源，包括從主機系統到桌面套用的各類數據。從這一點上說，它的作用類似於odbc。
oledb定義了數據存取、操縱的界面，這些界面主要供開發資料庫與資料庫引擎的數據提供者（data provider）使用，他們編寫出符合oledb規範的資料庫接口，使uda能對他們的資料庫進行存取。應用程式開發人員不必直接使用oledb，他們應該使用更方便的高層編程界面ado。
ado
ado是基於oledb上的高層編程界面，它提供了一致的，高執行效率的數據存取方法。實際上，對套用開發人員來說，uda就是ado，只需使用a?do就可以存取各種數據源了。
ado非常容易使用，因為調用它的方式是人們熟悉的ole automation界面。ado被設計為用來取代rdo和dao，因而它們之間是非常相似的，都是基於層次對象的，ado可以看作它們的超集。熟悉rdo、dao的開發人員可以很快學會ado。但有一點需要注意：ado不向後兼容rdo，它們不能在代碼里混合使用，但它們之間的差別是非常小的。
rds
rds就是以前的adc，現在被集成到了ado中。為了區分adc與ado的關係，adc改為rds，它與ado使用同一個編程模型。
rds是一種新的web數據存取技術，它允許開發者在支持activex的瀏覽器中創建以數據為中心的套用。rds創建這樣的框架，它允許與odbc數據源（包括企業內的intranet和整個inter?net）方便地互動。rds的工作原理是：首先把數據從資料庫伺服器中下載到本地的數據緩衝區，然後應用程式（或瀏覽器）通過rds操縱本地數據緩衝區中的數據，最後rds負責用緩衝區中的數據更新遠程資料庫中的數據，同時處理更新衝突。rds提供了下述優點：客戶端的數據快取、可更新的數據、並支持數據綁定的activex控制項。
odbc
odbc的歷史已經有十幾年了，大家非常熟悉，它也是套用最廣泛的關係型資料庫的界面，幾乎得到了所有資料庫廠商的支持。它是低層的界面，用來針對sql server、oracle等關係型資料庫系統提供統一的編程界面。在uda中，odbc通過oled bprovider for odbc集成到oledb中。
uda在internet/intranet上的套用
uda不僅能在企業內部的intranet上得到有效套用，而且在整個internet上也可大顯身手。不論internet還是in tranet，它們包含了各類信息源的複雜組合，所有的信息都能通過瀏覽器瀏覽，在這裡uda大有用武之地。以前在internet/intranet上開發資料庫套用比較困難，現在通過uda可以方便地進行開發。
存取方式
從uda的各組件在internet數據存取中可以看到，瀏覽器有兩種方式對遠程數據進行存取：
一種方式是：瀏覽器對數據的存取要求經過網路傳到相應站點的iss（internet information server）伺服器，然後由iis伺服器使用ado來完成對各類數據源的數據的存取。這實際上就是microsoft大力推廣的活動伺服器頁面技術（activex server pages，asp）。所謂asp技術，簡單地說就是對microsoft的iis在伺服器端的一種擴展，它允許基於web的應用程式的開發人員編寫伺服器端的腳本以擴展基於web的應用程式的能力。伺服器端的腳本可以用vb script來寫，也可以用別的腳本語言來寫。這些用高級語言編寫的腳本在伺服器端運行，所以它們不依賴於任何客戶端的作業系統或瀏覽器。
另一種方式是：瀏覽器對數據的存取要求直接通知給客戶端的adc（rds），然後由adc通過伺服器端的oledb把所需的數據下載到客戶端本地的數據緩衝區中，由adc管理本地的數據緩衝區中的數據，並負責與瀏覽器進行互動，最後adc使用本地的數據緩衝區中的數據對遠程數據源進行更新。這與傳統的客戶/伺服器結構模式是非常類似的。
相應地，使用uda開發internet/intranet資料庫套用，即可在客戶端進行（通過adc），也可在伺服器端進行（通過ado與oledb）。下面加以簡要介紹。
方法1：在伺服器端建立ado頁面。
建立ado頁面是基於vb script的，與visual basic for application的開發是非常相似的。步驟如下：
·要創建ado中的adodb對象；
·打開與adodb對象的連線；
·在打開的連線上創建數據結果集，對數據結果集裡的數據進行操作；
·關閉連線。
下面是一小段程式代碼，用以說明上述步驟：
setconn=server createobject
（″adodb connection″）
conn open ado samples
setrs=conn．execute（″select for mauthors″）
方法2：在客戶端建立adc頁面
建立adc頁面同樣是基於vb script的，但它是“重客戶端”結構，類似於傳統的客戶/伺服器結構模式，並且還需要客戶端的activex控制項。建立的過程與vb的form的設計過程非常類似；數據控制項用來管理連線；把別的對象綁定到數據控制項上；數據控制項處理數據集的移動。
建立adc頁面的步驟為：要增加adc對象；創建所需的數據綁定的控制項；編寫客戶的代碼。
MSDASDK新版本特點介紹
1 OLE DB和ADO可以被用來支持半結構化的數據，主要包括：
1．層次結構的數據存儲（比如檔案系統，郵件系統，目錄服務，文檔存儲等等）
2．能夠通過URL直接和對象進行綁定
3．增強了和XML的集成能力，主要包括：
1．把層次化的記錄轉換成XML格式形式保存
2．能夠把記錄集保存到一個流（stream）中而不僅僅是磁碟檔案中
3．和ASP的Response和Request對象相集成，保存ADO記錄集
2．增強了ADO錯誤報告能力
3. ADO MD用戶能夠提取通過模式對象而不需要初始化和遍歷CubeDe
