PRB: Conflict with EOF When Using #import with ADO

With #import, it is possible to generate classes that encapsulate the typelib of database API's, such as ActiveX Data Objects (ADO), within a windows application. For example: When doing so, you may receive the following errors from the #import for ADO on the Recordset.EOF property: The DLL Universal Problem Solver tool (DUPS.exe) is a sample that contains all the utilities documented in the January 2000 Microsoft Developer Network (MSDN) News article "The End of DLL Hell." Please review that MSDN article before reading this article.

The DUPS package is a set of utilities that you can use to track and compare DLL versions on multiple Windows-based computers. The maximum number is governed by your SQL Server or Microsoft Access installation. The Dlister client that enumerates the DLLs on a system runs on Windows 95 or Windows 98, Windows NT 4.0, and Windows 2000. The viewing utilities were developed on Windows NT 4.0 and Windows 2000, and require either Microsoft Access or Microsoft SQL Server. It was tested with Microsoft Access 97 and later versions and SQL Server 6.5 and later versions.

Within an application that uses Stdio.h, Ios.h or Streamb.h (including Afxwin.h), EOF has already been defined as a constant (-1). The #import then attempts to define the EOF property for ADO's Recordset or RDO's Resultset objects, and generates the C2629/C2238 errors on the following line of generated code in the msado15.tlh (or msado10.tlh if ADO 1.0 is used) file: This line is attempting to define a variable, but EOF has already defined it as -1. As a result, this line of code parses to: This does not compile because -1 is not a valid variable name.

To correct this, you can use the rename attribute of #import as follows: Rename changes the name of any "EOF" string that #import finds in the specified typelib to a new value.

Another fix is to undefine EOF before importing ADO follows:

This behavior is by design.

The following file is available for download from the Microsoft Download Center:

Release Date: Jan-14-2000

For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base: Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file. This article and its accompanying code will be updated periodically. All comments are welcome and will be considered in future updates. (Use the submit hotlink in the right frame for commenting.)
Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This article assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific needs.
If you have limited programming experience, you may want to contact a Microsoft Certified Partner or Microsoft Advisory Services. For more information, visit these Microsoft Web sites:

Microsoft Certified Partners - https://partner.microsoft.com/global/30000104

Microsoft Advisory Services - http://support.microsoft.com/gp/advisoryservice

For more information about the support options that are available and about how to contact Microsoft, visit the following Microsoft Web site:http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS The DUPS package can be used on a single computer or used to track the DLL history of every DLL on the network. It runs on Windows 95 to Windows 2000 and in its simplest mode has no dependencies. The DUPS package consists of the three C++ utilities and several Visual Basic viewers.

If you just want to compare the DLLs an application is using on two computers (computer A and computer B), run the Dlister.exe program. By default Dlister creates a file in the C:\ directory with the name Comp_DLL.txt where Comp is the name of the computer running Dlister. You can also specify that Dlister write to a database, or you can specify another directory in which the file should be created.

There are two ways to override Dlisters attribute defaults. Dlister and the Visual Basic viewers get this registry key: And the following values: You can use the Visual Basic applet DllHell\C_clients\ATL4VB\VbregSetup to set these values or you can simply run Dlister and it creates default values. For example, setting the ConnectString to: causes Dlister to write values to the SQL Server dllHell database, while: uses a local Microsoft Access database.

The second way to override default values is by setting the attributes in the file DllHell.ini in the Dlister.exe directory. These files are unzipped into the DllHell\C_clients\Dlister\Release\ directory.

A file named xdllHell.ini is included in the sample with a connection string that you can modify. (Rename this dllHell.ini if you want to use it.)

If computer A and computer B both have ActiveX Data Objects (ADO) installed, the simplest approach to populate the dllHell database is to set the connection string to the SQL Server or Jet database. Alternatively, you can run Dlister in text file mode then use the C++ utility DllHell\C_clients\Dlister\readtxttbl\Release\DlgDtxt2DB.exe to read the output text file into the DllHell database. The ReadTxtTbl MFC application is also useful for reading in the text that data clients e-mail you. You must register the COM servers DUPS\C_clients\ATL4VB\r1RegMon\ReleaseMinDependency\r1RegMon.dll and DUPS\C_clients\ATL4VB\readDlls\R1readTxtMod\ReleaseMinDependency\R1readTxtMod.dll to use the Visual Basic viewers.

You can enable CRC checksums by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\KB Samples\r1dllHell ComputeCRC to 0x1 on systems running Windows 2000. Once you navigate to this key, you can add it to your favorites. Windows NT 4 users must navigate manually to this key.

Creating the DllHell Database

SQL Server 7.0 is recommended, but Microsoft Access 2000 also works. To create the DLLhell database you can use SQL Server Enterprise Manager to create an empty database named DLLhell. From the SQL Server Query Analyzer window, select DLLhell from the database drop-down listbox. Run the DllHell\SQL\dllHellSchema.sql script in this window and it creates all the tables needed for Dllhell.

Alternatively, you can run the following command in the SQL Server Query Analyzer: The code creates the database and all the tables.

Comparing the DLLs on Two Systems

To compare all the DLLs on two systems use the cmpWithList Visual Basic utility in the Dllhell\VBviewers\VBcmpList2 directory.

To limit the DLL comparisons (typically to only those DLLs a target application loads) you must also have a text (.txt) file containing the DLLs you want to compare. You can create this list with Depends or one of several tools (such as ListDLLs and Process Explorer) from the following Web site:

Using cmpWithList

When cmpWithList starts it shows a list of computers in the DLLhell database in the computers listbox. By default, the first two computers in the list are selected for comparison. To change the target computer, select it in the listbox and then select the Change button. The Comp1 and Comp2 edit boxes show which computers you will compare.

Use the directory navigation control to select the text file that will contain the names of all the DLLs you wish to compare on the two systems. Double clicking on the text file selects it.

If you do not want to compare DLLs in some directories (typically you do not care about DLLs in winnt\system32\dllcache and WINNT\$NtServicePackUninstall$) double-click on the row in the grid. You will be prompted to add the directory to the _skipDir table. DLLs in the _skipDir are not considered for comparison.

Installing Automatic Network DLL Auditing

Setting up the at schedule on Windows 2000 systems:

Start with the dllHell\rcomp.cmd command file. Change the following environment variables to reflect your system:

1. Dpath: The directory on the client where Dlister creates the text file list of dlls on the client. The default is C:\temp\DLLhell\
2. COMP: The name of the client computer.
3. ChangeFileLocation: The full network path where the DLL differences file should be copied. This is the directory that the HellsMonitor service watches.
4. ServerLst: The network path where the C_clients directory of the DLLhell package is located.

On the taskbar, click the Start button, point to Programs, point to Accessories, point to System Tools and then click Scheduled Tasks.

Activate the Add Scheduled Task applet. Browse to the local directory containing the rcomp.cmd file and select it. After selecting the options the wizard presents, the rcomp.cmd file is added to the scheduled jobs. The first time you set up the scheduled job, select the start time 2-5 minutes in the future so you can test your settings. It is often convenient to uncomment the pause command so that you can see any errors that occur.

Register the File Monitoring Service

From the Dllhell\C_clients\HellsMonitor\ReleaseUMinDependency directory run this command, which registers the service: The most important part is the monitor client. This is a GUI that allows you to add or remove which directories to monitor. It also allows you to specify the application to run (with a handy browse button). For the DUPS monitoring system, the application is Dllhell\C_clients\Dlister\ReadTxtTblCmdLine\Debug\ReadTxtTblCmdLine.exe.

To add a directory to monitor, click Add. This opens a directory browse dialog box where you can browse to the directory you want to monitor. To remove a directory or directories select the directories you want to remove and then click Remove. In order to specify the application to run either type it in or browse to it. If you do not specify a path it has to be in the system path somewhere. Next, click Set to set the monitor to run that application when a change is detected.

NOTE: The set button is only enabled when you change the application to run from what it is currently set. The remove button is enabled only when you have directories selected to remove.

For more information, see the following: