VC中利用ATL OLE DB类开发Access数据库的技巧
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]
本文地址：http://com.8s8s.com/it/it3340.htm