Techniques for developing Access databases using ATL OLE db classes in VCs

Microsoft Corporation provides the latest data development technology for OLE DB, which is built on COM interfaces. Because the OLE DB development database is convenient and fast to database access, it is a preferred technology for many commercial software. As a programmer, I was fortunate to participate in the development of interactive TV programs of Chengdu World Video Network Limited liability company. In the development of "stock on demand" system, we chose the ATL encapsulated OLE DB class to develop the stock database, because the stock database is often 100MB, and the program continues to append or modify data to the database, so in the development process we encountered a lot of difficulties, fortunately can be solved. Now I am in the development of some of the experience and skills to discuss with you: One, OLE DB Jet 4.0 cannot be used At the beginning of the development, because we chose the desktop database access, originally intended to use the Access 2000 database format, but when inserting OLE DB Jet 4.0 does not pass. We try to use ADO technology and directly using the lowest-level COM interface, the program can run normally. This indicates that the OLE DB 4.0 engine does not have a bug and the problem must be on the ATL Wizard-generated file. Fortunately, I know more about COM technology, after hard groping, eventually found the problem: key in the ATL Wizard to generate the database header file, in the OpenDataSource () function, the following line of statements: <?xml:namespace prefix = o ns = "Urn:schemas-microsoft-com:office:office"/> Dbinit. AddProperty (Dbprop_auth_persist_sensitive_authinfo, false); If we remove it, the program will work. View Dbpropset_dbinit Properties: Dbprop_auth_persist_sensitive_authi NFO means: "True or false means that database objects adhere to sensitive authentication information, such as passwords and other cryptographic information, that require encryption." But we set it to true and false to pass, only to delete it. This is probably a bug of Microsoft ATL Template Library! Second, sometimes need to re-use the wizard to generate the header file We also encountered during development: if the header file of the database generated by the ATL Wizard is used for a long time, errors can occur when the program operates the database. However, after you rebuild the header file with the ATL Wizard, the program runs correctly. But this happens when using the OLE DB Jet 3.5.1 engine, with ADO and directly with the underlying COM interface, this is probably a bug for ATL! But this is not always happening, users are generally not easy to find. The database we developed is larger, and the program continues to append or modify data to the database, so this problem was discovered during development. Third, how to decide to move to the database header or tail Because ATL does not provide a function to determine whether a database pointer is moved to the head or tail of a database, it is only possible to determine whether to move the head or tail based on the move function. The ATL class provides two functions MovePrev and MoveNext to move the pointer, its return value is the HRESULT type, and the HRESULT is a 32-bit code returned by an OLE DB call, and the bits of its code function and meaning the reader can consult the relevant books. If the return value is S_OK, the pointer is not moved to the database header or footer, otherwise it is moved to the database header or tail. The following example iterates through the database record: (info represents the database Recordset object) HRESULT hr = Info.movefirst (); while (hr! = S_OK) { Process the record hr = info. MoveNext () } Iv. If you change the header file of the ATL Wizard-generated database, it is best to rebuild all at once, because your changes may affect some OLE registration information, and because of ATL, it may be necessary to compile all the files again to update all the file information, otherwise, it may cause the program to run unhealthy. Handle more than 255 character fields. A character field in an Access database holds a maximum of 255 characters, what if we are dealing with fields larger than 255 characters? We can change the character field to a Memo field, whereas the binding variable for the field generated by the ATL Wizard is as follows: TCHAR m_filename[1024]; Combination of multiple file names You can see that ATL automatically binds us to the Database Mem field is a string variable, but the length of the character is limited to 1024 characters. So, can we handle variables that are larger than 1024 characters? The answer is yes, we just have to change the 1024 to the value you need, such as: TCHAR m_filename[10000], the program can still function normally. However, it is recommended that users use caution, otherwise it will cause unnecessary memory overhead, which is especially important in the development of large commercial databases. It is also necessary to note that in the debug version, the variable uses a character size of no more than 255, which is normal if the program uses a variable greater than 255 characters and may not get the correct result in the debug version. If you change to a release version, everything will be fine.        This article only superficial describes the problems encountered in developing database technology with the ATL OLE DB Class, and the solution, hoping to help readers. There are still some bugs in the VC6 integrated ATL3.0 version, which I believe will be resolved in future releases. At the same time, I welcome programming enthusiasts to discuss VC6 programming skills with me. Author Blog: http://blog.csdn.net/i_like_database/