Personal Oracle 7/Reports 2.0 install problems

We ve been installing Personal Oracle 7.1 on a number of PCs and have had lots of troubles either with the installation or with integrating this new database with our other network instances or Oracle Reports 2.0 for windows.
To preface: We have several copies of PO7.1 on CDROM. The copies were installed on a total of 5 different PC's. The PC's were configured as follows:
All PC's using MS DOS 5.0 (#1 has DOS 6.22) Windows 3.1 with minimum of 20mb swap file (virtual memory).
1. 386/25 with 8mb RAM, standard VGA graphics card, IDE disk controller, CD ROM.
2. 486/33 with 20 mb RAM, Stealth PRO AT bus graphics card, wollongong network drivers, ESDI hard drive, Oracle Reports 2.0 installed 3. 486/33 with 20 mb RAM, Stealth PRO AT bus graphics card, wollonggong network drivers, QEMM 7.5 memory manager, Norton Desktop/Windows desktop, ESDI hard drive, Ultrastor controller, Oracle Reports 2.0 installed, Boca I/O 2 by 4 serial/parallel card (4 serial, 2 parallel ports). 4. 486/50 with 20 mb RAM, Paradise Accelerator AT bus graphics card, no network, Adaptec 1542C SCSI disk controller, CD ROM , QEMM 7.5, Norton Desktop/Windows
5. 486/100DX4 with 32mb RAM, Stealth VLB graphics card, wollongong network drivers, Adaptec VLB SCSI disk controller, Oracle Reports 2.0 installed

Oracle salespeople have claimed they ve heard of no problems with personal Oracle 7. Is this for real? Are there any others out there having problems? None of these installations went without trouble EXCEPT the 386/25 (PC 1). This was the only one that was underconfigured per the minimum requirements, yet it worked with no problems!

PCs 2 and 3 had similar difficulties at first. The WIN32S installation locked up the computer when we tried to run the FREECELL program. This was resolved by removing the Stealth drivers and using the generic SVGA drivers. I called Stealth to get new drivers. They never arrived so I dialed up Compuserve and downloaded them from the support service. After installation, I find that I can now use Oracle7 using 1024X768 256 colors. #4 with Paradise had no trouble and #5 with VLB (and apparently already had the updated version of the Stealth drivers) had no trouble at this level.

PCs 2,3 and 5 then successfully performed the installation of PO7.1. The tools installed and the database could start up.

#4 continually locked up on the installation. The lockup occurred most often while trying to start up the default instance after copying in the files. It had to be rebooted (trying to abort the windows job only locked it up harder - the bitmapped image disappeared as did all the icons, yet control did not return). It was suggested that I increase swap file size and defragment the disk drive. I also removed RAMDRIVE and reduced SMARTDRIVE memory so the total available RAM was over 17mb with a 24mb swap file (non-permanent). Installation continued to hang, except once
(I did many installations to try to settle upon the real problem). Even
then, the following happened: Trying to start the database with the Database Manager always locked up the system. I could start up the database using SQLDBA successfully, however. Discovering that, and looking around, I noticed an INSTALL2.SQL script that rebuilt control files after out-of-memory problems. I ran that and, for a couple of times the Database Manager program could then start up the instance. However, MANY times while trying out the tools, the system just intermittently locked up and had to be rebooted (soft reboot, CTRL-ALT-DELETE worked to reboot windows). I am still attempting to resolve the conflicts on this PC. I've tried using SVGA driver rather than paradise drivers, to no avail. I've tried excluding A000-CFFF from my QEMM manager, this doesn't help. Quarterdeck technical notes recommends several options, such as excluding F000-FFFF to handle things, which I ve also attempted to no avail. VCPI memory, which Oracle originally required, does not seem to be relevant for windows
(Quarterdeck s Manifest program says VCPI is installed under DOS but is
not installed under Windows).

I've increased swap space to 24MB from 12MB. This is one thing that helped for one time, this is when the installation worked and the Database Manager worked. But later, it locked up frequently and eventually these things no longer worked, even after reinstall.

After juggling a lot, I've concluded that the Norton Desktop for Windows
(NDW) and Paradise drivers do not seem to affect the outcome. Taking them
out of the picture does not affect the results on PC #4.

What does seem to affect the system is the memory manager and the amount of memory allocated to XMS.

I get the same type of errors if I boot to DOS 6.22 and use the 6.22 version of EMM386. This manager, in conjunction with HIMEM, auto-senses the memory so I don't reduce the amount allocated to XMS. Among the errors I get are:
R20DES - General Protection Fault - TK2WIN.DLL at 0030:0DF1 R20DES - GPF - R20DES.EXE 0006:BFAC
R20DES - GPF - VGS7WIN.DLL 000D:597B
WIN32S - Unhandled exception Code 0xC00001D - ORACLE71.EXE:5F001 (this reboots the system)
In addition, with QEMM, I intermittently get the system to lock up when starting the database using Database Manager. When Database Manager works, the green light comes on after 20 seconds or so but the disk drive keeps working for 40-50 seconds after that. After moving the swap file to another disk, I discovered that this is time windows is taking to do swapping. After loading 7.1 (and terminating Database Manager) I check available memory, which is now reduced by 12mb.

However, if I run DOS 5.0 HIMEM and EMM386 (which only seems to recognize 16mb of my 20mb RAM) then I can use the Database Manager successfully. I occassionally still get lockups intermittently, so this is not a perfect fix. It seems that other tools which require lots of memory (such as Reports 2.0 and Forms 4.0) can still cause the PC to lock up but I can get a lot farther.

PCs #2,3,5, we found, did not successfully run Reports 2.0 against the PO7.1 instance. if you start up reports designer and try to connect to scott/tiger database oracle7 or database 2: you get the error message ORA-03121: no interface driver connected - function not performed. Using a blank database name and we were informed that this only worked in Standard Mode - obviously a bogus message. These 3 PCs had previously installed SQLNET for windows and we were connecting Reports 2.0 to an instance on a server.

We began experimenting with the ORACLE.INI file and configuration options. PO7.1 seems to have overwritten our ORACLE.INI file for Reports 2.0, which was installed months ago. So, we combined the two files into one and tried again, making sure that we had SQLNET DBNAME definitions for our SQLNET instances. Also included a 'SQLNET DBNAME oracle7=2:' since this was in the PO7 INI. This did not work.

However, PC #5, changed the instance name from oracle7 to test in ORACLE.INI, created a different configuration file (copied from 7.1 default), added the paramter REMOTE_LOGIN_PASSWORDFILE=SHARED (was EXCLUSIVE) and discovered that he could connect to the local instance. PC #2 discovered that if you start up the database using the PO7 ORACLE.INI, then copied back the REPORTS20 ORACLE.INI and start up using that, (plus some other fiddling that included copying over some DLL's into the \PATHWAY directory, which is the directory for wollongong network drivers) then his PC also ran correctly.

PC #3, we tried all of these things, plus the following: Remove QEMM, REMOVE Norton Desktop, use generic SVGA drivers and we still cannot connect to the local instance, though we are able to connect to any SQLNET instance on the system.

PC #4 has no SQLNET, and no remote Oracle. When I start up REPORTS20 without PO7.1 running, it starts up but, of course, has no instance to connect to. When starting up PO7 first, then starting R20 designer, the startup aborts with fatal unexpected interrupt errors which seem to occur in a varying number of DLL files (caused by R20DES). On this PC, I had first installed PO7 then installed R20. To attempt to solve this, figuring that there may be older DLL's on R20, I again install PO7 (to same directories as before) to try to overwrite any conflicts. This changed the Unexpected Interrupt messages to other DLL files but the message still occurs. Removing QEMM from PC 4 helped a lot of this trouble but it still locks up periodically. Removing QEMM from #3 didn't help the connection problem. Removing RAMDRIVE (which returned 4 mb of RAM) did help PO7 installation but did not resolve the R20 problem.

Needless to say, if this is supposed to be a stable, easy to install, well integrated product, it obviously is not for 4 out of 5 of our PCs. Whether or not it is a WIN32S problem exclusively is, at this time, irrelevant.

This was posted in part to perhaps help others having similar problems and also to solicit any suggestions that others might find useful who have gone through this with more success. Received on Thu Mar 02 1995 - 17:39:06 CET