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.
Related
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.
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.
We have an application that stores its database files in a subfolder of the Program Files directory. These files are redirected to the VirtualStore in Vista and Windows 7. We represent data from the database using Microsoft DataReports (VB6). So far so good.
But we now want to use Crystal Reports XI to represent data from the database. Our idea is to NOT pass this data to CR from our program, but to have CR retreive it from the database using a a system DSN through ODBC. In this way we hope to present our users with more flexibility in designing their own reports. What we do want to ensure though is that these system DSNs are configured correctly when the user installs our program or when the program calls the Crystal Report.
Is there a smart way to do this using System variables for instance, instead of having to write a routine that checks for OS-version, whether UAC is enabled on the OS, whether the write restrictions on the Program Files folder have been lifted, etc and then adapts he System DSN to point to either the C:\Program Files\OurApp\Data folder, or the C:\Users\User\AppData\VirtualStore\Program Files\OurApp\Data folder?
Suggestions for an entirely different approach are welcome too!
New applications should have an application manifest that specifies requestedExecutionLevel. This declares your program "Vista aware" and bypasses attempts at virtualization.
During installation you should create a folder like [CommonAppData]\Company\App\Full and set security on this folder to allow Full Access by Everyone (or by Users). Put your database into this folder.
For an MDB you can drop the database right here. For a client/server database put a UDL file here. Also see Use Universal Data Link (.udl) Files.
ODBC and DSNs are pretty obsolete technologies.
Using the suggested approaches should work for almost anything but the oldest Win95 computer.
Is this an Access database? You haven't specified.
For an Access database, you don't need to point your DSN to a specific database when you install it. You can modify the connection string to point to different databases at runtime (details). For instance
Driver={Microsoft Access Driver (*.mdb)};Dbq=C:\mydatabase.mdb;Uid=Admin;Pwd=;
Can you simply read the installation path at runtime (in VB6 it is App.Path) and then send a different connection string to Crystal Reports?
It seems that Virtual Store takes care of everything, so you can point the DSN blatantly at C:\Program Files\MyApp\Data\mydb.mdb even while the database has been relocated to the Virtual Store.
Current Version
You might want to detect the current-version of Windows the system is running.
This will in turn help You in determining the correct PATH.
How to find windows version, build and revision numbers??
Read the the Registry keys –
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EditionID
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProductId
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\BuildLabEx
The CurrentBuildNumber is your Windows Build Number. Then CurrentVersion value is your windows version i.e. the version of your windows 7, windows vista, windows xp, etc. EditionID and ProductId to know the windows-edition and product-id.
The key BuildLabEx contains build number and revision number.
For example, in the value 6001.17387.x86fre.vistasp1_gdr.070927-1921:
the first four digits stand for build number i.e. 6001 and
the next five digits stand for windows revision number i.e. 17387.
x86 tells you that you are running a 32-bit operating system.
You might also be interested in this:
How to detect true Windows version?
GoodLUCK!!
We are in the process of moving from the .NET Microsoft oracle driver to the ODP.NET driver.
One of the problems we have had is this error:
ORA-12705: Cannot access NLS data files or invalid environment specified
We were able to stop the error by modifying the registry and changing the setting (see this question)
In our case we changed
HKEY_LOCAL_MACHINE - SOFTWARE - ORACLE - NLS_LANG
which was set to NA
to be the same as
HKEY_LOCAL_MACHINE - SOFTWARE - ORACLE - HOME0 - NLS_LANG
which was set correctly
My question is why would there be different NLS_LANG settings in the registry, and might there be any knock on effects of changing this value?
Update:
I've just found in the Oracle NLS FAQ the following
For Oracle version 7:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
For Oracle Database versions 8, 8i and
9i:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\
where "x" is the unique number
identifying the Oracle home.
HOME0 is the first installation
For Oracle Database 10g:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_<oracle_home_name>
There you have an entry with name
NLS_LANG
OK, so there are different registry settings for different versions...
Note:
Some people are confused by finding a
NLS_LANG set to "NA" in
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
when no version 7 was installed. This
is used for backwards compatibility,
and can be ignored.
I have Oracle 9i, so now I'm even more confused - why is the ODP.NET dll looking at the Oracle 7 registry setting?
I had a similar problem with the;
ORA-12705: Cannot access NLS data files or invalid environment specified
The ODP.NET dll's or instant client were reading the registry;
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\NLS_LANG=NA
The value NA caused the error.
This was because I already had a client installation but I wanted to use the oracle instant client via network drive for the a VB.NET app with ODP.NET.
My simple fix in my vb.net solution was for example to adjust the environment for the application via:
Environment.SetEnvironmentVariable("NLS_LANG",
"AMERICAN_AMERICA.WE8MSWIN1252",
EnvironmentVariableTarget.Process)
nb. The Oracle "NLS FAQ" link is no longer valid (2012)
PER Oracle Notes on the 11g ODP release, the following can cause this error:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\NLS_LANG=NA <--- This NA does in fact cause this error if set to NA.
You can try DELETING the key if not needed or setting it to a valid NLS_LANG setting for your locale.
For us we set it to AMERICAN_AMERICA.WE8MSWIN1252.
In our case we did not want to make any potentially breaking changes to the Oracle registry because we were installing our web service on a production Oracle 9i server.
The solution was simply to prevent ODAC from being able to see any ORACLE registry keys by denying all access to that key for the user ID our web service was running as.
Start -> Run... regedit (as an administrator)
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
Right click on the ORACLE key -> Permissions...
Click the Add... button.
Add the web service user name configured in your web service's application pool identity (e.g. IUSR_MyWebService); this is the user name that appears against your w3wp.exe process in Task Manager.
Press OK.
For the new user permissions, check "Deny" against the Full Control permission and press OK.
This worked just fine and as a bonus we have ensured that our application is isolated from any future changes to the ORACLE registry keys.
Tip: you can prove to yourself that the user in question has no access to the keys in question by closing any running instances of the Registry Editor, start a CMD prompt as that user (using Run As...) and then launching regedit from the command prompt.
the Oracle Client (ORACLE_HOME\bin\ora*.dll) is looking for a file named "oracle.key" in the same directory. This file contains the name of the registry key which belongs to this Oracle client installation. (e.g. "Software\ORACLE\HOME3")
hth
Andreas
This was all resolved in the end by installing the ODAC 11 client components (downloaded from the Oracle website). I think the system was getting confused because we had copied the ODAC dlls across rather than fully installing the client. ODP.NET is expecting an Oracle 11 client and didn't know where to find the Oracle Home.
NB if you are installing the ODAC components using xCopy deployment then do not install them to an existing Oracle Home directory (eg c:\oracle\ora92 for 9i client). This causes a 'Provider is not compatible with the version of Oracle Client’ error.
How can i enable tracing in a odp.net client from the connection string? Just adding the parameters traceFileName, TraceLevel and TraceOption ?
After some researching, I've found that ODP.net can be configured via web.config olny in version 11 and above. For previos versiones of ODP.Net, the only way is using the windows registry
You can't. You'll need a registry or XML fix.
But you can emit ALTER SESSION SET SQL_TRACE=true right after logon, either in your application or in AFTER LOGON trigger.
ODP.NET does exactly the same: it looks into registry and executes this statement.
A few tips for those finding this from Google:
Note that the trace will default to go in the root of the C drive. For Windows 7 and later, this requires administrator privilege or it will just fail silently. So either make sure your app is running as administrator or that you change the path of the file.
Also note, that if you want to trace ODP.NET fully managed, you need to put the settings inside the app or web config file, not the registry, AND the settings for TraceLevel are different (1 through 7).
And finally, when tracing unmanaged ODP.NET remember that there is a separate WOW registry node for 32 bit Windows. If your app is 32 bit, don't accidentally set it under the 64 bit portion of the registry.