I am a twist experience of my ATLADO programming

zhaozj2021-02-11  156

I work with VC6 ATL to make a component, and I access the Access database through the ADO. Because ADO itself is also a series of components, the ATL project is to introduce the ADO type library, I am introduced by the following statement (assuming Windows installed in C): # import "C: / Program Files / Common files / system / ADO / Msado15.dll "NO_NAMESPACE NAMED_GUIDS RENAME (" EOF "," AdoEOF ") This is a standard method of reference ADO in Microsoft's official textbooks (1015 Mastering COM Development Using Visual C 6.0), the textbook said that you can make you Can use the latest ADO version. Please note that this is the first trouble. The Access database is built on Access 97, so I used Jet 3.51 OLE DB Provider, that is, the Connection string is: "provider = microsoft.jet.Oledb.3.51; ..." This is the second caused trouble . My development environment is Win2K, this is the third trouble. Please listen to me slowly. Ok, debugging everything on Win2K. I have been trusting 2k because I am very stable in the 2K up-tuning system, and the speed is better than in 98. The most important thing is that many errors that cannot be tracked with Debug on 98, can track it on 2K! I am giving to the user a hundred times. The user machine is Win98SE, and the Access 2000 is installed. But the user machine is reported: "Create AdoDb.Recordset Failed"! Of course, 98 is not so intelligent. This error message is I left a heart, let it report in the program: _RecordSetPtr PRS = NULL; if (Prs.createInstance (CCOMBSTR ("AdoDb.Recordset"))! = S_ok) { Error ("Create AdoDb.Recordset Failed"); return e_fail;} 98 Will not support ADO! I first thought that it would be an access2000 problem? However, it should not, although the Access97's database structure cannot be modified in the Access 2000 execution interface, but because Access2000 is driver, it should be compatible down! If ADO can modify the structure, let alone I have no modification, I have no modification of the data! One pass in the box, in the MDAC 2.5 help file I found: Jet4.0 Ole DB Provider provided from Ado2.1 will disable some Jet3.5x files, the dead Microsoft! I have to change the connection string to: "provider = microsoft.jet.Oledb.4.0; ..." After all, the user machine is now upgraded to office2000, and there are not many people with Access 97. But still report that fault! Convection to another installed operation on the WinMe machine, run normal! How is this going? I almost doubt that there is a problem with the 98 machine system. So I checked its registry, HKEY_CLASSES_ROOT / CLSID is AdoDb.Recordset.

On the occasion, I found this: #import msado15.dll generated file msado15.tlh, _Recordset's IID is "00000556-0000-0010-8000-00aa006d2ea4" and the hkey_classes_root of the registry of the unlucky 98 machine There is no IID under Interface! I quickly viewed the Msado15.dll on 98 with Ole View, but I saw the _recordset interface, all Interface, Coclass should have. Interestingly is interesting! Holding so many years, let me have long remembulatory: Never doubt system problems, compiler has problems, and always believe is the problem of their own procedures. Fortunately, I still have a little observer, I found this 98 machine Msado15.dll _Recordset interface IID is: "000555-0000-0010-8000-00Aa006d2ea4" Seeing no, one is 556, one is 555, they are not One interface! Ok, take a closer look at the msado15.dll: _Recordset derived in RecordSet20, Recordset20, Recordset15 is derived from RecordSet15, and RecordSet15 is almost rooted (blame file name is Msado15 instead of MSADO20 or else), each of them each IID Not the same. I looked at the Msado15.dll on 2K, _Recordset was derived from Recordset21, and RecordSet 21 was derived from Recordset20, the following derived trees and 98 were the same. I noticed that the version attribute of the 2K msado15.dll's library section is 2.5, that is, the TypeLib version is 2.5, and 98 is 2.1. I finally understood that the original ADO version I developed is different from the user version on the user machine. It is developed by ADO2.5, and the user machine is ADO2.1. The Recordset named the ADO version version 21, 2.0 named RecordSet is named RecordSet20, and the ADO always names the latest version of the Recordset interface to _Recordset. So when using the #import with VC, the generated _recordsetptr is the highest version of the highest version supported by Msado15.dll. So how can I know which ADO version is installed by the user machine? There is no direct way in MSDN to find this information, or I am not working. I have to use the "Search" function. Search for "MDAC" topics have greatly beyond my imagination - there are 500 pages! Fortunately, I didn't check "ADO", which will be more. After watching the three five topics, I have some heads, Microsoft's data inventory is too confusing! After the bite is insisted, after reading the topic, I finally got some shortprues. First, M $ BLESS ME! ​​This topic is more brought by the search results, making me know some basic concepts in time, can insist on reading the subject: Info: What Are MDAC, DA SDK, ODBC, OLE DB, ADO, RDS, AND ADO / MD? ID: Q190463MDAC is the general name of ODBC, OLE DB, ADO, RDS four-class data inventory. The comparison of the like's MDAC packet begins with version 1.5. It includes ODBC 3.5, OLE DB 1.5, ADO 1.5, RDS 1.5.

2.0 MDAC once named Data Access SDK 2.0, including ODBC 3.51, OLE DB 2.0, ADO 2.0, RDS 2.0. The subsequent ADO versions are basically consistent with the version of MDAC. In addition to the large version, there are small versions such as 1.5B, 1.5 (PDC), but the function of the large version is almost the same. Ok, I care about how to determine the ADO version of the user machine, and then I can know which files to be released. The TypeLib version of Msado15.dll is not a way to get to the user machine. This topic seems to be a bit: howto: determine the version of MDAC ID: Q269490 But this is to download a software software, or rely on an unreliable registry key. I would like to know more: The software configuration of a user machine can determine the smallest version it supported. M $ BLESS ME AGAIN! The following topics are more brought before: Info: Microsoft Data Access Components (MDAC) Release History ID: Q231943 See OLE DB / ADO tortuous development processes and confusion release: MDAC 1.5 in the following products Install Beta version: NT Options Pack (IIS 4) / IE4 / WIN98, officially published in IE4 at 08/01/1997, that is, Win98 or Win95 IE4 guarantees the existence of ADO1.5. In the operating system of the NT core, NT4 / OP / IIS4 can also use the 1.5. In the NT4 of 07/01/1998, MDAC 2.0 is included. This back NT core exceeds 98 kernels. In the 3/15/1999 IE5, MDAC 2.1, we know that Win98SE is bound to IE5. This is ahead of the 98 core. 4/1/1999, BackOffice 4.5 on NT rushed up and support MDAC 2.1. 2/17/2000, Windows 2000 has a big one, simply binding MDAC 2.5. Oh, I used MSDN January 2001, and there was no place. I have seen WinMe's default installation, which is supported by MDAC 2.5, and the 98 kernel is coming together with NT core. The later released also MDAC 2.6, I estimate that it is released independently. I have an XP machine already installed vs.net, and VS.NET requires MDAC 2.7. I have been unclear 2.6 and 2.7 which one is binding to XP. However, later you will see that MDAC 2.5 and 2.6 / 2.7 are not big for the programmer mainly using the ADO.Recordset object. Let's take a look at what changes in the Recordset object in the ADO versions. Recordset15 has no perfect Clone and RESYNC methods, and it is likely to not support asynchronous method. These are all implemented in Recordset20, and the CANCEL method of RecordSet20 supports termination of asynchronous methods. ADO 2.0 also implements RecordSet's persistance, but only supports ADO-specific ADTG (Microsoft Advanced Data TableGram) format. Recordset21 adds the SEEK method and Index property. In addition, partial XML formats are also supported in the Persistance. From ADO 2.5, Persistance has been greatly improved.

The RecordSet object fully supports the persistance to XML format, but this depends on Microst XML Parser, which is Msxml.dll, which is available from IE5. The RecordSet object can also personSistance to any object that implements the ISTREAM interface, and ADO 2.5 also provides a Stream object. Therefore, ADO 2.5's Recordset can directly PersiStance to IIS5 (Windows 2000 binding) ASP RESPONSE / REQUEST object, providing great convenience for ASP data access programming. The 2.6, 2.7 version after ADO 2.5 has no change in the interface of the Recordset, and the other ADO objects are enhanced, such as the Command 2.7 objects in ADO 2.7. For developers primarily using Recordset objects, 2.5 and 2.6, 2.7 are not large. Ok, I broke up the ADO's development history and various versions of the ADO. The discussion of how to release the ADO application. It should be noted that the MDAC packet is not only published as an operating system and IE, but it is often used as a separate package release, such as on the PDC (Professional Developer's Conference). It also publishes some application systems such as BackOffice, SQL Server, etc., especially it is also released with Visual Studio. The VS6 includes MDAC 2.0, and the VS6 SP3 contains MDAC 2.1. However, these are not the main problems we have considered by our developers. I think if you write "this software requires you to install MDAC XX" in your software installation requirements, most users don't understand, including many MCSE (BTW: I Is MCSD, because D is before e, so I have superior sense). "This software requires you to install VS6 or SQL Server" often makes users feel unfair, and "requires Win98se / Winnt IE5 / Win2K" more clear. The user is clear about the version of the operating system and IE, which is also required, so when I determine the MDAC environment of the user machine, I think it is still mainly based on the judgment of this. The MDAC package has a installer MDAC_typ.exe, you can add it to your application installation project, when the User's ADO version is lowered by your requirement, use it to install high version of MDAC. You can find this program in the VS6 installation disk. This topic of MSDN can help: Redistributing MDAC, but this is a lot of articles in the installation project, and the installation package will become big, and you may also confer the lawsuit with M $, if you use a D version. So I am more willing to minimize my procedure to the system, in other words, I want my program to use the ADO version as low as possible. How to do it? First of all, I thought I want to find a Win98 or Win95 IE4 machine, copy its msado15.dll #import, or simply develop it on this. But now I have to find a Win98 first edition or Win95 machine is very difficult, and it is too difficult to run VS6 above. Copy a msado15.dll is also easy to get migrated with the development machine. Suddenly I thought VC6 had a header called Adoint.h, I guess it is ADO Interfaces.

There are ADO objects here, the interface definition! I opened AdOint.h, IId it's _Recordset's IID is: "0000054F-0000-0010-8000-00Aa006D2EA4" again check Msado15.dll, this is the IID of Recordset20, that is, VC6 AdOint.h provides It is an object and interface of ADO 2.0. This is very well understood that the VS6 comes with MDAC2.0. Take a look at the lowest operating system that supports ADO 2.0: WIN98SE / NT SP4 / 2K / XP, which is satisfied with most users, so the use of ADO is ideal according to this Adoint.h. If you still want to use Smart Pointer, such as _recordsetptr, then #imouth "c: / program files / commit / system / ado / msado15.dll" NO_NAMESPACE NAMED_GUIDS RENAME ("EOF", "AdoEof ") Replace: #include #include

转载请注明原文地址:https://www.9cbs.com/read-5769.html

New Post(0)