PL/SQL developer with oracle 32-bit/64-bit client - plsqldeveloper

I have Oracle 64-bit client installed to run with my weblogic application. I learnt that pl-sql developer doesn't work with oracle 64-bit client so now i have both 32-bit and 64-bit clients installed on my machine and my ORACLE_HOME variable points to 64-bit client.
I am not able to start pl/sql developer even i specify the 32-bit client in Tools->Preferences of pl-sql developer version 8.0.4.
I changed my oracle client to 32-bit client then i was able to start pl-sql developer but my application doesn't work.
Is there a way i can run PL/SQL developer whilst pointing ORACLE_HOME to 64-bit oracle client. I am not sure specifying the ORACLE_HOME explicitly in Tools->Preferences of pl sql developer (for user/default as well as system preferences) has any effect as it picks the oracle home from the environment variable i believe.
Thanks,
Adithya.

You'll need to install the two clients into separate Oracle Home locations, for example I've gone for C:\OracleHome and C:\OracleHome32
Then set up an Environment Variable, called TNS_ADMIN with the folder that contains your default TNSnames.ora file as the value (for me it is C:\OracleHome\network\admin)
Keep your preferences in PL/SQL Developer, and make sure you also specify the OCI library (mine is C:\OracleHome32\oci.dll)
Finally, using regedit.exe, add a second key under ORACLE (HKEY_LOCAL_MACHHINE\SOFTWARE\ORACLE). I've called mine KEY_OraClient11g_home1 and KEY_OraClient11g_home2. Create the same 4 strings in the second key, with the appropriate changes to the data (e.g. ORACLE_HOME should have C:\OracleHome32 as it's data field in my example)
Restarting all applications should now let you use PL/SQL Developer seamlessly, whilst also defaulting to the 64-bit Oracle home for your weblogic application.

To fix this, download the 32-bit version of Oracle Instant Client, extract it to a directory such as C:\instantclient.
Next, configure PL/SQL Developer to use this version by clicking on Tools -> Preferences. Under Connection -> Oracle Home, point to the location where you had extracted Instant Client (C:\instantclient), and under Connection -> OCI library, point to the oci.dll file in the same directory (C:\instantclient\oci.dll).
Restart PL/SQL Developer and you should be able to connect.

This is an updated answer specifically for the Oracle 19 instant client and PLSQL Developer 13, which is 64 bit.
To make PL/SQL Dev work with the client, I went to :
Configure -> Preferences -> Oracle\connection -> set oracle home to the new home dir, in my case, c:\oracle\product\19.x.
Do the same for the OCI : C:\oracle\product\19.x\instantclient_19_6\oci.dll
If you're migrating from an order version, you probably have built up a list of databases in your tns_names.ora. That will have to be moved over to the new client directory tree.
Manually make a subdir network\admin under the 19.x root. Once restarted, the Database list under 'Define Connection' had my list.

Quick post: I was trying to connect to a 64-bit Oracle database using PL/SQL Developer. Despite ORACLE_HOME being set the right values and oci.dll available, PL/SQL Developer could not connect to the database.
Further probing indicated that the Oracle installation was a 64-bit one, and PL/SQL Developer is incapable of loading 64-bit version of oci.dll file. To fix this, download the 32-bit version of Oracle Instant Client, extract it to a directory such as \instant_client.
Next, configure PL/SQL Developer to use this version by clicking on Tool menus -> Preferences. Under Oracle Home, point to the location where you had extracted Instant client (\instant_client, in this case) and under location of OCI Library, point to the oci.dll file present in location where you had extracted Instant client ( \instant_client\oci.dll). Restart PL/SQL Developer and you should be able to connect now.
open given link to download oci.dll file
http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html

Related

SSIS - Using Attunity connector with Oracle Express Edition

I've been trying to setup a local test environment by installing Oracle Express Edition. I've got a test database up and running and can query that database from Oracle SQL Developer. I then installed the Attunity Oracle connector. I found documentation that said I should install both 32-bit and 64-bit versions of the Oracle Client for Windows, so this is what I did. Actually these are just zip packages that you have to unzip and add to your PATH environment variable. (Apparently the people at Oracle haven't heard of installers.) I then created an SSIS package, added an Oracle Source component to my data flow and created an Oracle Connection manager for it. However, I'm unable to connect to the XE database. The error I receive is 'Oracle Home not found.'
Any ideas? Is it even possible to do this?
VS2015, SQL Server 2014 Express, Data Tools 14.0.61021.0, Oracle Express Edition 11g R2
#Rubio,
You'll need to set your system environment variables for Oracle on the VM or local box you're running the SSIS package if that's where your version of Oracle Express resides. To determine where that is, the directory path should be one level above the bin directory where the sqlplus executable exists.
Here's an example setting: ORACLE_HOME=c:\Oracle\product\11.2.0. You should also set your path to include $Oracle_HOME\bin.
To set your environment variables in Windows, go to the advanced system settings, click on environment variables, add a new one under system.

asp.net core 1. how change the Target Runtime to x86

i develop an Asp core web application (.net framework).
how i specify a run as 32-bit applications?
the publish wizard do not give way to change the Target Runtime, which the selected option is x64 is selected.
I installed on my machine the x86 version of .NET Core Installer.
publish wizard screenshot:
PS Why do I need x86.
I had to run the site on a computer that installed Microsoft Access 32-bit (2003, for an old software).
I also need to access data in Microsoft Access file, which requires me to use the Microsoft.Jet.OLEDB.4.0 driver.
The problem is, probably, that the app's core ASP.NET always running as 64-bit applications, is what gives me the known exception 'driver not registred'
stil after set "enable 32-bit application" in IIS.
i cant install the 64-bit access driver engine, because it requires the removal of MS Access 32-bit...
As mentioned here you need to add the "runtimes" key to your project.json file like below image.
Once you do this, the Target Runtime entry in Publish menu will list all of your specified runtimes. Although this is not enough to get it working since using the Publish menu and selecting x86 version will have no effect and will result in x64 binary files. (This bug may be fixed in future).
The workaround is to navigate to your project folder where the project.json resides. Open a command prompt and type the following to have your binary in desired runtime:
dotnet publish --runtime win7-x86
If you get any error yet, you may need to have the corresponding runtime installed (Download form here).
More info:
https://learn.microsoft.com/en-us/dotnet/articles/core/app-types
https://learn.microsoft.com/en-us/dotnet/articles/core/rid-catalog#what-are-rids
There is also a platform key under buildOptions listing all possible targets, but yet because of some issues (like #1624) it has no effect and it seems the system ignores that.

'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine' without need to install Access Engine

I've written an app which uses OLE DB, and I've encountered the error from the title. I've installed the Access Database Engine as suggested in this question and all had become work well. However, I want to distribute the app among some users to their locale machines and I have been reported such a error from the testers which do not have this util installed.
Is there any way to embed the Access Database Engine into my binary as dll or, maybe, into installer? I do not want to say "to use my app, install that util please"
if your end-user computer does not have MS office or MS Access installed, you won't be able to use the ACE.OLEDB driver UNLESS you install the basic access runtime/databse engine. However, if your end-users have 64bit windows and 32bit office, you will get the same error. To over come this issue you need to change your app target platform to x86.
if you are using visual studio, on additional way would be to add "AccessDatabaseEngine.exe" as one of your prerequisite which will be then installed along with your software.
more about custom bootstrapper:
http://msdn.microsoft.com/en-us/library/ms165429.aspx

ACE.oledb Not showing up in list of providers

I have an SSIS package that I use for a quick upload to a SQL database. I have recently moved to a different machine. New specs are Win 7 64bit and Office 2010 32bit. Had to have the 32 bit office in order for another program to run correctly. If I build/run the package in SQL Server Data Tools it completes. But if I try to run the solution from a batch script, I get the microsoft.ACE.oledb.12.0 is not registered error. I have searched many sites, and downloaded what I assume were the appropriate install packages to have the ACE driver.
I used a trick from one of the sites where you make a new text file, and rename it TEST.UDL. When I right click on the file, select properties, and go to the provider tab, Microsoft ACE is not listed. Is there another step to register the ACE driver that I am missing?
Thanks
I found that I was still executing the 64bit dtexec.exe, and had to rewrite my batch script to find the 32bit version.

Detect MySQL version or compile individually for installer?

I have a custom-built installer for our software and I'm in the process of upgrading/updating it to match our new program. The program works on a Server/Client model. When a new workstation is added as a client it has to install ODBC drivers to connect to the databases on the server.
My question is, should I be trying to connect to the server to get the version of MySQL to determine which drivers I need (3.5, 5.1, etc) by reading a registry key, or should I just compile separate installers for each version? What are the best practices for making installers for different environments?