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.
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.
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.
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.