ODBC driver for Oracle supports both x86 and x64 versions of the following Oracle Clients: 12c, 11g, 10g, 9i, 8i, 8.0. Note that support for x64 versions of Oracle Clients is available for 64-bit.

And what the need is. While 64 Bit Applications allow for more resources to be used they may not be necessary at the moment be the best option available. Sure eventually we will all move to 64 Bit Applications just like we did when moving from 8 to 16 Bit and then onto 32 Bit. But the problem here is that 64 Bit Hardware has been around for a long time but the software to use all of it's abilities hasn't. As a result the driver Base and so on for 64 Bit Applications isn't well developed so while technically 64 Bit is Superior when it comes time to implement a 64 Bit system it may not be piratical. There are still numerous Driver issues with all forms of 64 Bit Windows Server Platforms so while it is the way to go it may not currently be the time to switch. As the existing 32 Bit application is working and I'm assuming satisfactorily there is no need to change it unless there are currently problems or you have a need to move to 64 Bit Systems.

Nov 08, 2012  YouTube TV - No long term contract. No cable box required. Cancel anytime. No thanks Try it free. Find out why Close. Nepoznannoe Zamki prividenij Anglii. Prezentaciya na anglijskom yazike pro novij god v anglii en.

Just moving to 64 Bit because Oracle needs it and no other applications do isn't enough of a reason. But if you are using 2007 Exchange which is a native 64 Bit System then adding a 64 Bit version of Oracle to that server may be worth the effort. Really it depends on the current implementing as to what is the best option now. It's useless to switch just because the 64 Bit version is available and it's not needed. Also you need to test the 64 Bit application before deploying it to see if there are any issues with Data Loss or Corruption involved.

For instance a F1 car is technically better than a clapped out 1950 mini but that doesn't mean that it works better in most applications just in one set of circumstances, and in many it will prove to be a drawback to have. Edited to improve clarity I hope. .so, if it's only Oracle that needs the 64-bit (to make it run smoother and more efficient), I can forego the idea of migrating both my OS and database? But if our main concern is to make the database run efficiently (it's a 24x7 production database), should I consider the migration idea? I read somewhere (sorry I forgot the article) that sooner or later, I would might get ORA errors such as ORA-4030, ORA-12500, ORA-12560. I think this leads back to the fact that memory is not enough to support the database's (and other user threads) activities. Thanks so much again!

That is what I would do as it's possible to have a complete loss of function changing the version of Oracle or for that matter any other application. At the current time 64 Bit OS's are not well supported and there are issues involved in migrating to this form of Computing. While it will eventually be the normal it's currently not quite time for full scale migration. As for the ORA Errors yes you could get them but that would require a massive size D Bade file measured in Terabytes. Even then it would be better to rework the Layout to cut out unnecessary fields to make the file smaller. This is more to do with the size of the actual files not the hardware involved or the up time.

I would say that while installing 9i in windows 7, windows 7 itself warns you that this software has known compatibility issues. I visited the compatibility center and saw all clean, yet windows 7 warns me the same way. I tried doing that for the same purpose you mentioned in your question, but all efforts were futile, since some of the packages do not install properly, and O9i fails to function as desired. Options: use xp mode, or else use a VM within windows 7, and run windows xp in this vm and install o9i there. Would seem like too much, but this is the best way to go. In case it is just queries you wish to run, and not use any oracle specific features, then MySQL is a good option, especially the one with the GUI.

I found the following options in a few threads: (a) right-click run as administrator the 'install.exe' instead of 'setup.exe' * on errors do the same thing again (b1) right-click properties the 'setup.exe' set compatibility to Windows XP SP2 set run as administrator (b2) try installing using the 'setup.exe' (c) try the above steps with the 'install.exe' Once installed: 1. Go into the installation folder 2. Right-click properties the EXE file and select set compatibility to: Windows XP SP2 set run as administrator 3.

Repeat step '2' for every executable in the Oracle directory and sub-directory.