Showing posts with label Oracle 9i. Show all posts
Showing posts with label Oracle 9i. Show all posts

25 August, 2014

Oracle XE, ODP.NET and Oracle 9i in the same Windows XP machine

English: The logo of Oracle Corporation de:Bil...
English: The logo of Oracle Corporation de:Bild:Oracle-Logo.svg he:תמונה:Oracle Logo.jpg (Photo credit: Wikipedia)
Saturday night, 23-Aug-2014


For a couple of weeks now, I have been figuring out how to make Oracle 9i and Oracle XE work in the same machine. For a long time, I have been running Oracle 9i and ODP.NET, designing, developing and maintaining applications using the Oracle RDBMS. Only lately when I started working in a new company that I am having restricted access to databases that I had to resort to some local DB, even on my old XP machine. I have the disc space to begin with.

And having some access on some Oracle dB means I had to also create and maintain a local dB that is Oracle-based. In comes Oracle XE.

That is when I started experimenting with Oracle Express Edition, and with 11g as the latest, and with ODP.NET version of 10.x.x, did not think of having a compatibility issue, even then, since I was doing all these in a Windows XP-based unit.

Then I got the problem. I mean, I don’t know how it happened, but for a moment, after initially installing oracle XE, I was getting both local dB and data warehouse dB (using TNS) to work. I was very happy. And as in all installs, I did a reboot. And if in most cases, a reboot would rebuild and repair and renew settings and realign once again everything – as new – something now doesn’t work. I either would get the DW dB to be working, and Oracle XE dB to be broken, or vice-versa.
I did many things, like tweaking the Path variables, the 3 .ora files, even the TNS_ADMIN variable and value, pointing either to the Oracle 9i directory, or the Oracle XE, and like I said, I would either get one or the other, but not both. And in most cases, I get the DW dB which is using TNS, to be the one working. Doing a PING to XE would result in error, but TNSPING to XE would give a positive result. But both PING and TNSPING to 127.0.0.1 would give both a positive result.

As in previous issues and problems, I did a lot of searching. And this becomes complicated, because I have to wait until I get home then I will be able to look up ORA-12154, ORA-12514, ORA-12528, etc., etc., because internet access is also restricted! Bummer!

There were some suggestions that focused on setting up, if not already, TNS_ADMIN variable in the system variables, and assigning its value to the Oracle XE …\network\admin path, and I tried this one, adding, removing, changing, then putting it back to Oracle 9i …\network\admin path, and still, I would either get one or the other, but not both. And still the same, I would usually be having the DW dB working, but not the Oracle XE dB.

I should mention that for each trial, I am either uninstalling Oracle XE, at least, or I would uninstall all of Oracle XE, ODP.NET and Oracle 9i, in sequence. And in reinstalling, it is also in the same order: Oracle XE, then ODP.NET, and finally, Oracle 9i. I believe it is common knowledge for all who have tried it, that for ODP.NET to work with Oracle 9i, the installation should be in that sequence. This is more or less something to do with the final value of Path in the system variables, and even in the default Home selection for Oracle.

Also, after each uninstallation, I would run CCleaner to remove invalid registry items, after a reboot. And after running CCleaner, another reboot, to really be sure that I am starting clean.

After many trials and errors, I made it to work. I did a reboot, and I checked, and it is still working. Another reboot, and it is still working. I run CCleaner, to once again remove invalid registry items, then a reboot, and yes, I confirm that both data warehouse dB using TNS and Oracle XE dB are both working.

Monday morning, 25-Aug, when I came to work, I booted up my PC, tested the 2 dBs, and they are working. I did a reboot, just to be really sure that I am not dreaming, and yes, both are working.

What did I do to make it work?
  1. I removed the TNS_ADMIN setting from the System Variables. So it is now the individual .ora files being looked up and evaluated when I do a connection to each dB. (I think).
  2. After the installation, I did not touch the .ora files, which means that whatever value that was created by the installers, then that was it. No tweaking or whatever.
  3. The ODP.NET …\network\admin folder does not contain any .ora file. That’s a fact. It is just the dll file anyway that is required by .NET applications. Nada mas.
The day is now closing, and I have done quite a number of reboots – I am just very, very curious if the working condition will be sustained throughout the day. And yes, even as the day is already closing, I still get both data warehouse dB using TNS, and the local dB, using Oracle XE. I guess some times, you just keep your hands off things, and they will work on their own. They don’t need our help. 

Sometimes.

Till then!

02 December, 2011

The provider is not compatible with the version of Oracle client; ORA-03134

English: The logo of Oracle Corporation de:Bil...Image via Wikipedia02-Dec-2011


One of the final touches that I had to do on the new refurbished PC that I got is to make it into a local web server, an intranet application per se. And having found that in Windows 7, the way to go is publishing by a compiled site, I did just that.

I am one who would tend to make use of the different technologies and methodologies, just to be able to familiarize and not be tied to one; it’s for the good: when that singular method you lean on breaks, your whole system breaks, so having many sticks to lean on, you still are lifted up by the many others that remain standing and strong – when one breaks or falters.

Here’s what happened:

I copied over the codes, built the solution, and then published it. Since this is the second time around, I was going through all these things, including the creation of the folder, a breeze.

When I accessed the service from another PC, well, I got a 404 error.

I went to the IIS manager, and ticked all the services and features that I think are needed; of course, I haven’t memorized these sets, so I referenced the other PC that is already running the same web application.

That wasn’t enough. I still get a 404 error.

I remembered other things needed, so I didn’t hesitate downloading Web Platform Installer, where some other small, small services or features, not to mention some other service packs or applications, are offered.

I did that, and when the installation was finished, I did a reboot.

That brought the intranet application up and running!

Well, not all of it.

The section that runs queries using Oledb was okay. The other section that runs queries using Oracle client (ODP.NET) wasn’t. I got this error message:

“The provider is not compatible with the version of Oracle client”


Of course, the web being my primary source of information, I immediately launched Maxthon, which I prefer using to IE (a snail browser; Netscape is many times faster than IE), and searched on solutions to this problem at hand.

Again, many, many articles and discussions offered various steps to solve this problem, like copying over some dll files to the folder holding the exe, installing the ‘right’ and ‘compatible’ version of Oracle client, etc., etc. I could say the list is endless. I think I also saw some that suggested checking on the Oracle home definition, in various way and means, which I did by invoking Home Selector, and finally, through the registry editor.

And these didn’t help me. My problem isn’t solved. I actually did another comparison technique, that of the working PC and the non-working PC. They are the same.

But taking from some from the whole, I did what I think will help. I reinstalled ODP.NET, of course the version I am using is the same all over the computers that I manage. So there is no question of introducing an ‘incompatible’ or ‘incorrect’ version for this software.

Well, that fixed the problem on the particular section. BUT, it broke a number of other applications!
In particular, I got this error:ORA-03134. This is something about a newer Oracle client version accessing an older Oracle server version.

I’ve been through this one, but I don’t remember how I fixed it! My gracious me…

But I thought, since I fixed one by reinstalling, why don’t I do the same with this other?

And I did just that, reinstalling Oracle 9i client – which fixed ORA-03134.

I did a reboot, and after confirming that all the sections of my just-released web application are working, I retired – for the day.

Here’s a summary of what I was doing, what happened, and how problems are fixed, so far:

  1. Publish an intranet application on a local desktop PC running in Windows 7
  2. Copy the codes from another PC (already running the same web apps).
  3. Created the folders in the Program Files directory for the web apps destination.
  4. Built, and published to local folder (through compiled site method).
  5. Opened IIS manager (inetmgr), then added in the Virtual Directory (PC_Name >Sites > Default Web Site right click, then select Add Virtual Directory).
  6. Once the Virtual Directory is added, I right click on it, and then selected Convert to Application.
  7. That’s when error 404 was thrown out.
  8. Turned on additional windows features on IIS. Still got 404.
  9. Installed Web Platform Installer, followed by installing the service pack, and some auxiliary services and features.
  10. Reboot, and that’s when Web Apps was brought up, but section using Oracle client wasn’t working, with this error message: The provider is not compatible with the version of Oracle client.
  11. Reinstalled ODP.NET (the version I am using is ODT with ODAC 11.2.0.2.1)
  12. Fixed section using Oracle client for oracle connection, but created a problem for the others, specifically Oracle 9i client, with this error message: ORA-03134.
  13. Reinstalled Oracle 9i.
  14. The other programs were okay, and every section of the web apps works.
  15. Reboot, and crossed my fingers while waiting for the machine to come back up.
  16. A final check and review, and everything were working fine.
  17. And so I retired for the day, tired, but happy.



Till then!


Enhanced by Zemanta