I'm trying to get Toad 9.7 to work on a new installation of Windows 7 x64. I installed a 64-bit Oracle instant client (manually by extracting to a folder and setting some environment variables). Things seemed to be OK (SQL Developer worked, SQL*Plus worked), but Toad was having problems.
I then read that Toad needs a 32-bit client, so I "installed" that using the same method, but it still wasn't happy. It kept giving me an error saying that I didn't have an Oracle client installed. I tried many different things like setting different environment variables (LD_LIBRARY_PATH, ORACLE_HOME etc.) and nothing worked. I then scrapped the manual method and downloaded the full Oracle client but only checked the "instant client" option when I ran the setup, and that finally worked. Toad recognized the client and I got rid of those env. variables I had set, and only had TNS_ADMIN set, in addition to the oracle home folder in the system path.
There was still one problem. Toad didn't know the version of my oracle client and kept giving me error messages saying that the oracle home was invalid. I could ignore those messages and everything seemed to work, but I just didn't like the fact that the home it was using was coloured red and I had to tell it to ignore those error messages.
So after a little more digging and some guesses on my part, I got a kludge-ey method to work. I copied the oci.dll file into the bin folder under the oracle home, and I also made another copy of that file in the bin folder and called it oraclient11.dll. The combination of those two things got Toad to stop complaining.
However, that doesn't seem like a very clean method, so I was wondering if anyone else has come across this issue and used a cleaner method to get it working.
After you install the 32-bit client by extracting the files, set the PATH to point to the 32-bit directory. And make sure that the 32-bit directory is in the path BEFORE the 64-bit directories.
I think that's what worked for me but I'm not 100% positive.
Related
After having Oracle 12C client 32-bit installed on a VM, I found that the environment variable path was created but there is no registry entry for Oracle in HKEY_LOCAL_MACHINE\SOFTWARE.
As I understand it, this should be created automatically during install and since the environment variable path exists and is correct, I'd expect to find the registry entry.
Any thoughts on why this wouldn't have been created and, without uninstalling/reinstalling, how I can go about manually creating it?
The reason I am avoiding the reinstallation route is because this has happened previously on a different machine, and reinstalling did not fix the issue.
TIA!
For (any) 32-bit application you have to check HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Oracle
When a 32-bit application access HKEY_LOCAL_MACHINE\SOFTWARE then it is automatically redirected to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node. Actually that's a simplified statement, see Registry Keys Affected by WOW64.
A 64-bit application has access to both.
See also Registry Redirector to get a general description.
All.
I have used a DLL approach explained on How to securely store Connection String details in VBA
This code is running very well on windows 10 64 bit and MS Office 64 bit. But same copy of the files i am not able to use on Wndows 8.1 Pro and MS Office 64 bit.
DLL generated is converted to host machnines environment by using
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\regasm c:\windows\syswow64\OraConnection.dll /tlb /codebase
But still same error i am facing. About environment variables care has been taken.
My Connection string is
"Provider=OraOLEDB.Oracle; Data Source = ; User ID =; Password=";
In the Succesfull machine i was using Release 12.2.0.1.0 for ODAC 12.2c Release 1 as oracle client.
But saw a latest version of the oracle client as 64-bit ODAC 12.2c Release 1 (12.2.0.1.0) for Windows x64 which was released on 1st June 2017.
Installed the same. And my error was resolved. When i observed system environment variables i saw few things added into it.
E:\app\client\Admin\product\12.2.0\client_1;E:\app\client\Admin\product\12.2.0\client_1\bin;C:\Users\Admin\Oracle\;
I dont know actually what they did. But error was resolved.
Can anybody throw highlight on this?
I'm not sure what the DLL buys you beyond simple obfuscation. All you're doing is making it a bit harder to get to but not actually protecting the privacy of it in any meaningful sense. My normal advice for management of connection strings is to simply don't save user/password. Instead, require the users to input the username/password at runtime and ensure that you have Persist Security Info=false in your OLEDB connection. That way, once it's opened, the full connection string is now inaccessible and there's no reference to a password. That's much more secure than sticking it in a variable in a DLL and crossing your fingers nobody knows how to read a memory dump or attach a debugger.
That said, that's not germane to your question, not able to the use the provider. First thing I'd do is to rule out whether the DLL is causing a problem that you didn't expect by removing it and using the provider directly. If it likewise fails, then you know the DLL has nothing to do with it and you need to work out with Oracle's provider documentation to get to the bottom of the issue.
Lazarus 1.2.4 (FPC 2.6.4)
Oracle XE 11.2
Oracle Instant Client 32bit (Basic & SqlPlus)
I have been able to use the Lazarus TOracleConnection in the designer to connect on Windows 7 and CentOS Linux. When attempting to do the same in OSX Lion I get "Can not load Oracle client library libociei.dylib. Is it installed?" It is located in /Library/Oracle/instantclient_11_2.
I am able to connect and query via sqlplus on the Mac. Here is the contents of my .bash_profile (paths are accurate):
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Library/Oracle/instantclient_11_2
TNS_ADMIN=/Library/Oracle/instantclient_11_2/network/admin
PATH=$PATH:/Library/Oracle/instantclient_11_2
CLASSPATH=$CLASSPATH:$ORACLE_HOME
export DYLD_LIBRARY_PATH
export TNS_ADMIN
export PATH
export CLASSPATH
ORACLE_HOME is set to /Library/Oracle in Environment Variables
Can anyone tell why can't I connect through Lazarus running on OSX?
I'm neither knowledgable in Oracle nor OS X, so I just try to give some pointers:
Afaik the lazarus code just tries to dlopen('libociei.dylib').
So that either means
it can't find it because the lib has a different name (I assume you checked this)
it can't find it due to path issues (DYLD_LIBRARY_PATH should be ok, but temporarily try to set it globally in case a spawned process doesn't receive the changed env
it can't load it due to 32-bit vs 64-bit or other architectural reasons.
it can't load it due to other errors. (missing dependencies, security/permissions)
One can try to initialize the oracle module directly with a custom path.
Try using unit ocidyn in the lpr and then
do a
initialiseOCI('/your/whatever/path/libociei.dylib'); as first line in your .lpr
Note: If the error changed from "is it installed?" to "is it already loaded?", you are on to something, since you managed to load it at least once. I mention this because this subtle change often goes unnoticed.
My immediate workaround is to open Lazarus.app in Terminal. The designer works as advertised this way. The resulting .app can be run successfully from /Applications.
I built a Lazarus program and it's now in exe form.
I am able to run it on two of my computers running XP and Vista.
However, there are other computers as well running XP, Vista and Win7 but I cannot get it to run at all on them.
There are no errors, nothing... Has anyone else had this issue?
The program is connecting to a postgres DB on my LAN server.
Any idea on fixing this is really valued.
NEW INFO:
Maybe I'm wrong but here's a thought... On the development machine, I initially got an error like **libpq.dll* not found when I first tried to connect to postgres. Then after setting the path, it was fine. I'm thinking now if it cannot find that library and that's why it's not able to run.
If this is the case, should my line Application.OnException:=#CatchErr; catch the error? If not how else should I check if this dll or anything else is missing?
First, a sincere and big THANK YOU to Marco and MArtyn for the great tips and guidelines hat got me thinking of this strange issue.
Here's what happened...
I installed a fresh copy of Windows 7 and XP. As usual it did not work.
Then I suspected the old problem of libpq and then I copied libpq.dll from my working OS and put it in the application folder. By the way this machine has no Lazarus or Postgres. The moment I did this, I got my first error message saying that msvcr100.dll was missing.
And then I copied that as well. So the cycle of copy pasting went on for each and every error until I had finally brought these files to my 'non-working'.
libpq.dll - 9.2.1.12263 - PosgreSQL Access Library
msvcr100.dll - 10.0.40219.1 - Microsoft C Runtime Library
ssleay32.dll - 1.0.1.2 - OpenSSL Shared Library
libeay32.dll - 1.0.1.2 OpenSSL Shared Library
libintl.dll - 0.18.1.0 - LGPLed libintl for Windows NT/2000/XP/Vista/7
Once these files came in, the problem was gone!
Now the program works great :)
Thanks for all your inputs!
I now have to see what the above files have to say about their licenses as I have to distribute the app to other users. But I'm glad at least we figured out the problem.
No, base Lazarus programs don't require special permissions. Of course it could be that a specific functionality in the program requires special permissions (like access to ports below 1024, access to certain paths etc).
Also be aware that EXE's downloaded from what the system considers insecure sources (internet, certain kinds of shares) might be blocked by default. If that is the case, if you take the properties of the .EXE in windows explorer, there will be an "unblock" button.
Anything network related of course requires proper configuration of the firewall. The popups that query you might not always come, in case of doubt configure the firewall manually.
I have installed Cognos BI 8.3 on my machine, which has a Windows 7 OS 64-bit. In IBM's supported environment list for Cognos 8.3, Windows 7 is not listed. On top of that, it says the product will only integrate with 32-bit 3rd party libraries. So, you can already see that I'm already starting on a bad foot. But anyways, this is the machine I have and that is the software I got, so I decided to see if they would work together..
I installed Oracle 10g Express database also in my machine and Apache 2.2 server. Up to there no problems.
Before moving further, I copied ojdbc14.jar to cognos/.../webapps/p2pd/WEB-INF/lib and added the Oracle database in Cognos Configuration. Tested, passed.
With the database started, the Apache server started, and Cognos started, I was successfully able to start Cognos Connection on the computer. So, it looks like the OS is not an issue.
(You can see everything I did by following the steps on this site, which since two days ago seems to be down but I'm thinking will eventually come back up)
Then I decided to try the samples, so I tried to create a data source connection from Cognos to the Oracle database. So, in the admin config console (i.e. Administer Cognos Contents > Configuration), I decided to create a new Oracle data source. I put the credentials, but BAM.. testing fails.
Fail Message:
QE-DEF-0285 The logon failed.
QE-DEF-0323 The DSN(ODBC)/ServiceName is invalid. Either the DSN is missing or the host is inaccessible.
RQP-DEF-0068 Unable to connect to at least one database during a multi-database attach to 1 database(s) in:
testDateSourceConnection
UDA-SQL-0031 Unable to access the "testDataSourceConnection" database.
UDA-SQL-0532 Data Source is not accessible: "XE".
ORA-12154: TNS:could not resolve the connect identifier specified
RSV-SRV-0042 Trace back:
...
From what I have researched, it could be a number of things, but nothing seems to work. Here is what I tried:
Adding ODBC driver. Added the Oracle XE driver, even making sure it was done in the 32-bit ODBC manager (i.e. Windows\SysWOW64\odbcad32.exe). That didn't work.
Added ORACLE_HOME, LD_LIBRARY_PATH, and TNS_ADMIN to my environment variables.
tnsping'ed the XE database and it the ping returned ok.
There are no tnsnames.ora duplicates in the computer.
I tried and I am able to connect to the database via sqlplus. Did I mention that Cognos Config database test also passed?
Installed Oracle XE client. But didn't do much with it because the Oracle server is installed in the computer and also has a client component.
Has anyone come across this problem? I haven't been able to diagnose the problem or make even the slight progress for days. If you would like me to provide more information on any of the solutions I tried, please do ask. If you have a potential solution or, even better, if you have been able to solve this problem before, please let me know how!
Thanks!
One thing to keep in mind : certain portions of Cognos BI are implemented via Java and other portions are implemented via native C++ processes (the BI Bus processes)
Cognos connects to the content store database from the Java process using JDBC.
The BI Bus processes will connect to Oracle using a native oracle client.
So based on your description, I'd say that the problem area is in the native oracle client configuration (or the Cognos service's perspective of it).
You mentioned adding the ORACLE_HOME, LD_LIBRARY_PATH, and TNS_ADMIN environment variables in windows, and the fact that Oracle Utilities like SQLPlus and TNSPing are working for you.
When you added the environment variables, did you add them to the SYSTEM area for environment variables or the User area...?
If you're running Cognos as a service, its going to be a child process of SERVICES.EXE, which is run as system (this process is also not restarted unless you reboot the machine).
I'd try this :
make sure the above environment variables are defined for the SYSTEM user (in the system area, not the user area)
once you've done this, reboot the machine
See if you can create the database connection now.
If that doesn't work, I'd suggest doing a "run as" of SQLPlus or TNSPING as the SYSTEM user (and see if that works).
In order to use oracle as data source, you must install 32 bit client.
64 bit client will not work.
So if you installed oracle express 64 bit, and you don't want to uninstall it,
you can just install additional 32 bit client, and make sure to set it as your default home.