Results 1 to 15 of 15
  1. #1
    Join Date
    Feb 2011
    Posts
    36

    Unanswered: 32-bit DB2 ODBC DSN problem

    I installed DB2 on a new Windows 7 64-bit computer tonight. I can connect using my usual software, so I know my DB connection is correct. However, I need to configure 32-bit ODBC DSN (as I have on many of the other computers, which are also Windows 7 64-bit), but I have encountered a roadblock I have never seen before in my 11 years of managing DB2 systems, including creating and using DSNs extensively.

    Note that, since I am using my DSN with 32-bit MS Office, I must use the 32-bit ODBC AD here: C:\Windows\SysWOW64\odbcad32.exe, not the 64-bit one here: %windir%\system32\odbcad32.exe.

    I open the ODBC Data Source Administrator, go to the System DSN tab, click Add, select the IBM DB2 ODBC DRIVER, click Finish, enter the Data source Name and Description (the alias is already there--the name of the DB), and click OK. So far, so good. This is exactly what happens on a previously-configured station when I add a new 32-bit DSN.

    But here is where things diverge. I need to enter the DB username & password as well as set a couple of CLI parameters. So I highlight my newly-created DSN and click Configure. On any other station, I get a window having this in the title bar: CLI/ODBC Settings - [my new DSN name], and there is a Data Source tab (with a place for the username & password and a Bind CLI/ODBC support utilities button) and an Advanced Settings tab. This is normal behavior.

    But on this one station, I instead get a window having this in the title bar: ODBC IBM DB2 Driver - Setup, and there are only the same three boxes that were there when I added the DSN: Data source name, Database alias (now populated with my DB name but grayed out), and Description.

    I have been through ODBC.ini and ODBCInst.ini, db2cli.ini, and the relevant registry entries, as well as ensuring that the same versions of the ODBC driver files listed in the ODBC.INI and ODBCINST.INI nodes under HKLM\Software\Wow6423Node\ODBC in the registry (C:\PROGRA~1\IBM\SQLLIB\BIN\DB2CLI.DLL, C:\Program Files\IBM\SQLLIB\BIN\DB2CLI.DLL, and C:\Program Files\IBM\SQLLIB\BIN\DB2ODBC.DLL). All of these are the same when comparing this station to a working other station: version 9.7.900.250 (i.e. 9.7 FP9). And, of course, db2level is the same on both stations.

    I have added and removed the DSN many time from both stations, and the same difference persists, making it impossible for me to get my DSN fully configured on the new station. I have rebooted several times. I have uninstalled DB2, deleted the IBM folder and the C:\ProgramData\IBM folder, then reinstalled DB2. When I create the DSN, the entries properly appear in db2cli.cfg in the C:\ProgramData\IBM\DB2\DB2COPY1\cfg folder (except without the username & password, since the user interface will not let me do that).

    What would prevent one station from loading the CLI/ODBC settings form? If I use the 64-bit ODBC AD here: %windir%\system32\odbcad32.exe, it works as expected (brings up the configuration form for the DSN instead of the setup form). But that does not help me because I need the 32-bit DSN to remain compatible, and the 32-bit DSN works just fine on other stations.

    This does not seem to be a problem with storing the DSN information; it seems to be a problem with what form the ODBC driver presents me to configure the DSN after it is created.

    And to top it all off, it is my own management station that has this problem.

  2. #2
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    You have working-environments and a failing environment, at the same operating-system and db2-version-fixpack.
    Need to systematically compare the working and failing environment - some component will be different.

  3. #3
    Join Date
    Feb 2011
    Posts
    36
    Easy said...hard done. That is what I was attempting to do, file-by-file, at least with respect to the files that clearly relate to the ODBC driver (as per the registry indications of the ODBC driver files). And with the hundreds, if not thousands, of DB2 program-related files in place, it is not realistic to expect to ever get done comparing the versions of every single file.

    However, it finally did strike me that the Event Viewer could provide some help, and it does--except that I have no idea what to do with it. Every time I click Configure on the problematic computer, I get this SideBySide event 35:

    Activation context generation failed for "C:\PROGRA~1\IBM\SQLLIB\bin\DB2ODBCH.DLL".Erro r in manifest or policy file "C:\PROGRA~1\IBM\SQLLIB\bin\Microsoft.VC80.MFC\Mic rosoft.VC80.MFC.MANIFEST" on line 4. Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC80.MFC,processorArchitecture="x86",pub licKeyToken="1fc8b3b9a1e18e3b",type="win32",versio n="8.0.50727.762". Definition is Microsoft.VC80.MFC,processorArchitecture="amd64",p ublicKeyToken="1fc8b3b9a1e18e3b",type="win32",vers ion="8.0.50727.762". Please use sxstrace.exe for detailed diagnosis.

    So the problem is evidently here: C:\PROGRA~1\IBM\SQLLIB\bin\Microsoft.VC80.MFC\Micr osoft.VC80.MFC.MANIFEST. The "good" machine has no such folder (Microsoft.VC80.MFC)downline from C:\PROGRA~1\IBM\SQLLIB\bin, so perhaps the more basic question is this: why (even after removal/reinstallation), does the problematic machine get a MICROSOFT.VC80.CRT and MICROSOFT.VC80.MFC folder installed downline from \bin that are not installed on other computers?

  4. #4
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    Compare the microsoft fixes that are installed on the working and failing machine (especially the Visual C++ related stuff)
    Ensure they are the same. The VC redistributables are downloadable from MS.

    If that does not help, Maybe you can also compare the db2setup installation log files (between the working and the failing machines).

    You can also collect a trace file with the -t tracefile.log with db2setup and compare that between the working and failing machines (assuming you are installing the identical components from the same binary image, and using the same response-file or identical installation db2 options).

  5. #5
    Join Date
    Feb 2011
    Posts
    36
    Well, a couple more hours of post-midnight oil later, and I have my ODBC driver working correctly. I had to dig out and install the Visual C++ 2005 runtime distributable files and install those as a prerequisite for getting my DB2 9.7 FP9 32-bit ODBC driver to work correctly. ( A working machine had no less than 11 MS Visual C++ instances of various versions installed, so I instead went straight to MS and began working my way backward: installed VC++ 10.0.40219, when that did not work, removed DB2 client again and moved back to 9.0.3 something, eventually getting back to VC 2005 (x64: 8.0.61000, x86: 8.0.61001)--and now my ODBC driver works correctly.

    Do I understand that? Not a chance, especially when I consider that, even with Visual C++ 2005 runtime distributable pre-installed, DB2 still insisted on creating a MICROSOFT.VC80.CRT folder and a MICROSOFT.VC80.MFC folder downline from C:\Program Files\IBM\SQLLIB\BIN; but then, if I move/delete those folders, everything still seems to work correctly. I do not see those two folders on any of the other several machines I have checked that were installed in virtually the same manner. Maybe it is because this is the only machine that had Office 2013 and MapPoint on it before I installed DB2....or something like that. Or maybe it was just pure coincidence that in the last 12 years of managing these systems, I just never had the correct combination of bytes to result in DB2 not installing the correct prerequisite.

    So it is working, but I am still wondering why DB2 has a problem recognizing/installing the correct prerequisite VC and why, when I install that prerequisite manually, these two folders are put into place even though they seem to be irrelevant.

  6. #6
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    If you have a support contract, open a PMR and be patient...but they usually reach a conclusion / explanation.

  7. #7
    Join Date
    Feb 2011
    Posts
    36
    Thank you.

    Our third-party application provider that provides the front-end for our DB2 DB does have a support contract. I will open a support call with them and get them to run to IBM with the issue.

    I just found it very odd that I have never seen this in all the years I have been managing DB2, including literally hundreds of client installations on hundreds of computers...and that the issue was not an obviously-known issue.

  8. #8
    Join Date
    Feb 2011
    Posts
    36
    FYI: our third-party software provider says that, while he could open a PRM with IBM, I would probably never hear back. I will open a new thread here just to see if anyone has seen this odd behavior installing the DB2 client: failure to recognize Visual C++ 2005 as a prerequisite, combined with the installation of two VC-related folders inside my IBM...\bin folder.

  9. #9
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    That sounds like an unhelpful and misinformed vendor. Name and shame!

  10. #10
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by db2mor View Post
    That sounds like an unhelpful and misinformed vendor. Name and shame!
    To be fair, this is indeed a kind of problem that will be extremely difficult for IBM support to resolve. Firstly, it seems to lie outside the IBM software and secondly, it will be nearly impossible for them to reproduce. Add another uninterested link to the chain in the form of the software vendor, and you get a recipe for failure.
    ---
    "It does not work" is not a valid problem statement.

  11. #11
    Join Date
    Feb 2011
    Posts
    36
    Actually, I have now reproduced this on several workstations. I am into SxS far deeper than I ever hoped to go trying to determine the specific cause. In fact, I took an existing workstation that was otherwise working, removed the DB2 client, uninstalled the Visual C++ 2005 runtime redistributable, and now, when I reinstall DB2 client, it gets the two VC-related folders downline from the IBM...bin folder, and the ODBC driver generates SxS errors when attempting to configure the DB2 DSN.

    Also, this does affect 32- and 64-bit ODBC driver; that is, I get the SxS error on creating a DSN for either side, since I removed both the 32- and 64-bit VC installations. But the 64-bit DSN seems to work correctly (i.e. give me a fully functional DSN) even through it generates the SxS errors during setup.

    On the other hand, my own laptop, having no VC installation earlier than 2008, works just fine (no errors on beginning DB2 ODBC DSN-creation process)--even though installation does create the two folders downline from the IBM...bin folder.

    I thought at first that it was due to the fact that I have both March 2014-dated and September 2014-dated copies of the v9.7fp9_ntx64_rtcl_EN.exe package (both share the same file size as well as client version and file version), but I have tried both of those now on stations that work and stations that do not work.

    There is just something strange about the DB2 client responding differently to the same OS on different machines. There must be some subtle difference in the Win764-bit OS on these different machines.

    So I am still working on it.

  12. #12
    Join Date
    Feb 2011
    Posts
    36
    Two additional facts that a few more hours' trial-and-error have revealed:

    1. The problem also occurs with DB2 9.7 FP7 client (original testing was with DB2 9.7 FP9 client)
    2. The problem does not occur with DB2 10.5 FP3 client. (However, note that the solution is not as simple as just using this, since the application is not yet 10.5-ready).

    It occurs to me that perhaps I can see more detail on what is happening during installation if I can find the client installation logfile and hopefully find a way to make it verbose. Where is the DB2 client installation log file created, and can it be set to verbose mode? I have found instructions on this for the DB2 server, but not the client. When I run the setup from the command prompt with a /?, it shows nothing related to installation logging.

  13. #13
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Where is the DB2 client installation log file created, and can it be set to verbose mode?
    http://www-01.ibm.com/support/knowle.../r0022584.html This should be applicable to v 9.7 as well.
    ---
    "It does not work" is not a valid problem statement.

  14. #14
    Join Date
    Feb 2011
    Posts
    36
    I should have noted previously that there is no My Documents\DB2Log folder (the default location noted in the IBM client installation documentation) created during installation, nor does a search of the hard drive reveal any DB2*.log files.

    I already found instructions for the client, but I have tested several times and the -t option does not seem to work.

  15. #15
    Join Date
    Feb 2011
    Posts
    36
    I do have one small clue here: http://www-01.ibm.com/support/knowle....0%2F2-0-2-6-0

    Midway down that link is a discussion of the need to preinstall the VC2005 runtime library. However, this is supposedly required only if installing DB2 client using a non-administrator account. Now, I am using an administrator account, and even tried the installation under a different administrator account. But I supposed that, on the stations where I have the problems, there is something atypical with the local Administrators group, not with the individual user account.

    That does not really help solve the problem, but it does seem as though it may be related in some way.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •