Microsoft公司提供的最新數據開發技術OLE DB，是建立在COM接口上。由於OLE DB開發數據庫十分方便，並且對數據庫訪問速度很快，所以成為很多商業軟件首選技術。作為一個程序員，我有幸參加成都天下視訊網絡有限責任公司互動電視節目的開發。在開發“股票點播”系統中，我們選用了由ATL封裝的OLE DB類來開發股票數據庫，由於股票數據庫往往上100MB，並且程序不斷往數據庫追加或修改數據，所以在開發過程有我們遇到不少難題，幸而能一一解決。現將我在開發中的一些經驗和技巧與大家共同探討：
一、OLE DB Jet 4.0不能使用
開發之初，由於我們選用了桌面數據庫Access，本來打算用Access 2000數據庫格式，但在插入OLE DB Jet 4.0時卻不能通過。我們嘗試用ADO技術和直接使用最底層的COM接口，程序能正常運行。這說明OLE DB 4.0引擎沒有bug，問題一定出在ATL向導生成的文件上。
幸而我對COM技術還比較了解，經過艱苦摸索後，終發現了問題：關鍵在由ATL向導生成數據庫的頭文件中，在OpenDataSource()函數中，有下面一行語句:
dbinit.AddProperty(DBPROP_AUTH_PERSIST_SENSITIVE_AUTHINFO, false);
如果我們將之刪除，程序就能正常運行了。
查看DBPROPSET_DBINIT屬性：DBPROP_AUTH_PERSIST_SENSITIVE_AUTHI
NFO表示意思：“true 或 false表示數據庫對象堅持需要加密形式的敏感認證信息如密碼和其他加密信息”。但是我們將之設置為true和false都不能通過，只有將之刪除才行。這也許是微軟ATL模板庫的一個bug吧!
二、有時需要重新用向導生成頭文件
在開發過程中我們還遇到：如果用ATL向導生成的數據庫的頭文件用久了，則程序操作數據庫時就可能發生錯誤！但用ATL向導重新生成頭文件後，程序就正常運行了。不過這發生在使用OLE DB Jet 3.5.1引擎中，用ADO和直接用底層COM接口均不存在上述問題，這可能也是ATL的一個bug吧!但這不是時常發生，用戶一般不易發現。而我們開發的數據庫比較大，並且程序不斷往數據庫追加或修改數據，所以在開發過程中發現了此問題。
三、如何判斷移到數據庫頭或尾
因為ATL中沒有提供判斷數據庫指針是否移到數據庫頭或尾的函數，所以只有根據移動函數來判斷是否移到頭或尾。
ATL類提供了兩個函數MovePrev和MoveNext來移動指針，其返回值為HRESULT類型，HRESULT是一個OLEDB調用返回的32位代碼，其代碼的位的作用和含義讀者可查閱相關書籍。如果返回值為S_OK，表示指針沒有移到數據庫頭或尾，否則就表示移到數據庫頭或尾了。如下例子將遍歷數據庫記錄：(info代表數據庫記錄集對象)
HRESULT hr = Info.MoveFirst();
While( hr != S_OK )
{
//處理該記錄
hr = info.MoveNext()
}
四、如果改動了ATL向導生成的數據庫的頭文件，最好Rebuild All一次，因為您的改動可能影響一些OLE注冊信息，而由於ATL的緣故，可能須重新全編譯一次以更新所有文件信息，否則，可能會導致程序不正常運行。
五、處理大於255字符字段。
Access數據庫中規定字符型字段最多存放255個字符，如果我們要處理大於255個字符的字段該怎麼辦呢?
我們可以將字符字段改成備注字段，而在ATL向導生成的字段的綁定變量如下：
TCHAR m_FileName[1024]; //多個文件名的組合
可以看出ATL自動為我們綁定的數據庫Mem型字段是一個字符串型變量 ，但字符的長度限定為1024個字符。那麼，我們可不可以處理大於1024個字符的變量呢？答案是肯定的，我們只須將1024改成您需要的值即可，如：TCHAR m_FileName[10000]，程序照樣能正常運行。但建議用戶謹慎使用，否則將造成不必要的內存開銷，這在大型商業數據庫的開發中尤其重要。
另外需要說明：在調試版本中，變量使用字符大小不能超過255個，如果程序使用了大於255個字符的變量，在調試版本中可能得不到正確結果，這是正常的。如果改成發行版本，便會一切正常。
本文僅膚淺介紹了在用ATL OLE DB類開發數據庫技術中遇到的問題，及解決辦法，希望能對讀者有所幫助。VC6集成的ATL3.0版本還存在一些Bug，相信在以後的版本中會得到解決。同時歡迎編程愛好者與我共同探討VC6編程技巧。Email: [email protected]
