I have no problems creating ODBC dataset connections to Oracle 7.x and MS/SQL 6.5 in OI 3.6.1 (with NLM 1.5). (I have followed the instructions to edit the ODBC.INI file as mentioned in the knowledge base).

Recently, the company acquired NetWare 5, which comes with a free Oracle 8 system (version 8.0.3) for 5 users. However, when I try to create a ODBC dataset connection to the SCOTT database in this NetWare 5 Oracle system, OI will freeze and the PC must be rebooted.

I have applied the OI 3.7 and 3.7.1 upgrade/patch, but this problem is still happening.

Has anyone come across this same problem? How did you resolved it?

Thanks,

N J

N.J,

Based on what you have said i would guess you are trying this from a Win95/98 machine.

I have not tried the Oracle8 connectivty, but i have experienced the same symptoms when connecting to 32 bit data sources using a Win95/98 workstation. If we use a Windows Nt workstation it works fine.

The following is our experience

Both Oracle7 and Sql Server 6.5 have 16 bit drivers so these can work fine on 95/98 workstations. However, if we attempt to connect to a 32bit data source, such as access97, using the 'ODBC thunking' described in 'seeing 32 bit data sources', it OI will freeze and the PC must be rebooted.

I am certain that this is not an OpenInsight problem.

I can duplicated the same freezing when connecting to the datasource from other 16 bit applications. The same datasource on an NT machine works perfectly.

So try it on NT.

I hope this helps.

Cheers

Sam McDonald

Tristalee

Sam@tristalee.com.au

Dear Sam,

Thanks for your inputs. Sorry for not acknowledging you earlier. I checked the thread daily for 10 days after I released my original message, but did not see any responses to it, and thought it had become an orphaned thread. I only checked it again today, and saw that you had actually composed a response on the 25th of last month.

For your info, I had actually gone ahead to reformat a Win95 system, reinstalled the Netware 5 client, Oracle 8 for Netware 5 client, and OI 3.61 in the process. After this was completed, I found that I could create a Connection Object via ODBC to the Oracle 8 database. It seems that the Win95 system must have been "corrupted" in some form earlier.

However, I am still unable to create a Dataset object!

When you create a Dataset object, you need to specify the Oracle table and select some columns from it. Although the drop down lists all the available Oracle tables, on selecting any table, none of the table's columns are shown! Hence, I cannot create and save a Dataset object!

This is just as frustrating as my original problem. I had thought all my ODBC problems were licked when I resolved the original Connection Object problem through reinstalling a clean Win95 system. I did not expect to encounter this new Dataset Object problem.

As I mentioned in my original posting, Oracle's SQLPlus monitor, Oracle's SQL Worksheet, and Microsoft Query work FINE with the ODBC connection to the Oracle 8 on Netware 5 database. Hence, I don't think there is anything wrong with the ODBC connectivity. It's more likely that OpenInsight, being 16 bit, cannot work very resiliently with the 32 bit ODBC drivers for this Oracle 8 on Netware 5 database.

During my evaluation testing of OpenInsight earlier in June, I have found that OpenInsight's ODBC client/server connectivity works fine with MS SQL Server 6.5 and Oracle 7.2 databases on Windows NT 4.0, as you have mentioned.

I am really frustrated that OpenInsight is failing with all the new drivers (i.e. Netware 5, Oracle 8) simply because of the 16 bit problem. Very soon, OpenInsight will not be able to communicate properly with any new release of the major relational databases (ie. Oracle, MSSQL, DB2, Sybase etc) through ODBC.

My customer is a Netware shop, and there are some corporate reasons for using Oracle 8/Netware 5 and not using MSSQL 6.5/NT 4 (their Unix and SAP systems are on Oracle). Hence, I can't switch them to an NT platform on this aspect.

NJ

njwong@cyberway.com.sg

View this thread on the forum...