So, the solution is that I had to apply 8.1.7.4.1 first.
yong321_at_yahoo.com (Yong Huang) wrote in message news:<b3cb12d6.0302271123.5ce267b1_at_posting.google.com>...
> Billy Verreynne <vslabs_at_onwe.co.za> wrote in message news:<b3kv1n$ct0$1_at_ctb-nnrp2.saix.net>...
> > Run a search on the system for all oral8.dll's. Could also be that an old
> > one remained behind and gets picked up first in the DLL search path when
> > the app loads (on Windows the search path is, I thinkk, current directory,
> > \WinNT\, \WinNT\system32, DOS %PATH%).
>
> Kind of off-topic but this trick helps everybody not just DBAs.
> Assuming the running process has the same %path% as your current DOS
> shell, you can quickly search for a file first referenced in %path% by
> creating which.bat as follows:
> @echo off
> rem Windows which: 'which _prog_' tells you from where _prog_ is
> launched.
> echo IMPORTANT: Remember to include filename extention: 'which
> perl.exe' is correct;
> echo 'which perl' is wrong, because a directory named perl may be
> found first. If
> echo you don't know the extension, try .exe, .bat, .com, .cmd in that
> order.
> echo.
> echo fullname: %~$PATH:1
>
> Then run it like this:
>
> C:\>which dunzip32.dll
> IMPORTANT: Remember to include filename extention: 'which perl.exe' is
> correct;
> 'which perl' is wrong, because a directory named perl may be found
> first. If
> you don't know the extension, try .exe, .bat, .com, .cmd in that
> order.
>
> fullname: C:\WINNT\DUNZIP32.DLL
>
> To check a running process environment in Windows, use
> sysinternals.com's Process Explorer. In this case, look at the %path%
> variable of the SQL*Plus process.
>
> Yong Huang
Received on Fri Feb 28 2003 - 21:01:22 CST
