Re: Help with Designer 2000 and Visual Basic FrontEnd

From: Chris Albright <calbright_at_email.com>
Date: Tue, 22 Jun 1999 11:49:21 -0500
Message-ID: <7koelh$42b$1_at_birch.prod.itd.earthlink.net>


It is my experience that 16-bit programs and 32-bit ODBC Drivers do not get along. I had a similar problem with MS Office for Windows. When I ran Access on Win95, I couldn't get it to talk to the database with the 32-bit drivers, so I installed 16-bit ones, and after that, I didn't have a problem. There is one caveat though, when you install both 16-bit and 32-bit Oracle products, there are two separate oracle homes created. If you accept the default, they are orawin and orawin95 (or orant). For the products in both locations to be able to access the same databases, the TNSNAMES.ORA file needs to be present in both directories. For expample, "c:\orawin\network\admin" *and* "c:\orawin95\network\admin". This allows the VB front-end program to access the database through the 16-bit odbc drivers and the 32-bit reports to access the database straight through SQL*Net. Although, this is really only a temporary solution. The best answer is to port your 16-bit VB program to 32-bit.

I don't think that the ODBC Administrator has anything to do with it. This program only configures the drivers and datasources in the registry.

CactusButt <CactusButt_at_righthere.com> wrote in message news:376fb1a1.24193382_at_news.cactus.butt.net...
> Here is the story:
>
> I have about 30 machines running a 16bit Visual basic frontend, maybe
> written in VB5? I am not sure, the guy who wrote thre frontend has
> left the company, and my VB experience is as a user only. The
> frontend connects using ODBC to my Oracle 7 database. Commands are
> then passed to the 16bit Oracle Reports 2.5 runtime engine. Although
> all the machines are now running WIN95, this was not always the case,
> hence the development in 16bit. No problems.
>
> I'm trying to switch to the 32bit version of Reports 2.5. On my
> machine, this went off without a hitch. I uninstalled the 16bit
> Oracle software, reinstalled the 32bit and setup the new ODBC source.
> Again, no problems. When I went to do the 2nd machine, the VB
> frontend refuses to connect to the database.
>
> All versions of the software on both machines are the same. I am
> using the Oracle73 driver, version 2.03.1.1, filedate is 2/4/97,
> 181,248 bytes. SQLNet is version 2.3.3.0.0. The tnsnames.ora file,
> which translates the ODBC sources to IP addresses, I think, are the
> same on both machines. The VB frontend uses an .ini file which points
> to the location of the Reports runtime engine, and contains the ODBC
> source names. This file is the same on both machines as well.
>
> I can connect to the Oracle database fine on the second machine using
> the ODBCTest utility, so I think the machine is setup correctly.
> However, for some reason, the VB frontend doesn't like the setup. It
> pukes immediately upon trying to connect to the Oracle database with a
> runtime 3151 error message, "cannot connect to datasource".
>
> Examining the two machines further, I notice only one glaring
> difference. On the machine that works, the ODBC Administrator appears
> to be an updated version. It has a bunch of tabs across the top. On
> the machine that doesn't works, ODBC Adminstrator is the "older"
> looking box with buttons. This does not surprise me as I have applied
> several Windows 95 and Office 97 updates to my machine which have not
> been applied to the second machine. Also, my machine runs IE5, the
> second machine runs IE4.
>
> So, my question is twofold. One, what did I install on my machine
> that gave me the "new" looking ODBC Adminstrator? Two, is it possible
> this is my problem? Was there something in the updated ODBC
> Adminstrator that allows 16bit apps to "talk better" to 32bit drivers
> and apps?
>
> Thanks for any ideas and/or pointers you may have.
>
> CactusButt
Received on Tue Jun 22 1999 - 18:49:21 CEST

Original text of this message