I have a visual studio solution with an ASP.NET 3.5 web application (WCF host) and a test project. I wanted to use the Oracle Instant Client (v11, via NHibernate) to create Oracle connections without having the Oracle client tools installed on every "involved" machine (dev, CI server, test server, production server).
The weird thing is that on my development machine (x86) my tests run without problem, while my web application still gives me the following error message: System.Data.OracleClient requires Oracle client software version 8.1.7 or greater
Things I ruled out already:
The bin folder has read & execute permissions for everyone
The DLL's are unblocked (windows 7)
Problem occurs with both Visual Studio Development Server and IIS 7
I've also tested this on a machine with Oracle client tools installed and that works
I even managed to get the tests running on our x64 CI server (more info).
Anyone has a clue on what I am missing?
I see this error almost every time I set up Oracle on a new machine.
Check that the oracle bin folder is in your path
Give read and execute permission to everyone on the client folder (on my machine C:\oracle\product\10.2.0\client_1)
Changing permissions may not take effect until you reboot your machine.
EDIT:
From your comment, steps 2 and 3 are irrelevant for Oracle Instant Client. Hoverer, I would guess that the problem is still that the system cannot find the Oracle Instant Client DLLs. It would be worth putting the location of these DLLs into your path and seeing if this resolves it.
From http://www.oracle.com/technetwork/database/features/instant-client/index-100365.html
Installation Instructions
Installation Steps:
Download the appropriate Instant Client packages for your platform. All installations REQUIRE the Basic or Basic Lite package.
Unzip the packages into a single directory such as "instantclient".
Set the library loading path in your environment to the directory in Step 2 ("instantclient"). On many UNIX platforms, LD_LIBRARY_PATH is the appropriate environment variable. On Windows, PATH should be used.
Start your application and enjoy.
Related
Hello we have some SSIS packages with XML file configurations. Basically we configure the database connection, password, etc. to run the packages in different environment (Production vs. Testing). We use a 3rd party software to run our SSIS packages on target SQL servers. The packages run fine on our Testing environment, however fail miserably on Production server. The difference is SQL server on testing is vs. 2016, while on Production only 2012.
There are various error messages on why they fail on production, some of them about "Failed to load at least one of the configuration entries for the package..". And then there are some that cannot login to the database connection provided in the XML files, even though the info is 100% correct.
Does anyone know if XML config file is not supported in SQL 2012?
You really shouldn't be going from a test environment that's a different version than your production environment, it will only lead to more headache in the future.
If you can't upgrade production then I'd suggest getting another test system on the same version as production.
That being said...
The functionality is there in 2012, but the format probably isn't the same.
You need to set the TargetServerVersion to SQL Server 2012 in Visual Studio under Project > Properties and build the project again.
Project Properties
After successfully testing my MVC4 programs using this environment
I tried to publish it to 64-bit Windows 2008 Server with the IIS that disallows 32 bit apps, then I start getting stuck with the exception : the referenced dll's dependencies cannot be found!
I tried every advice the internet can give me including modifying web.config to reflect their dlls' on deploy-to server win 2008 using global cache cmd's on the prompt!
Yet nothing works. 32-bit is working but 64-bit is flat broke!
First, I stopped messing around the web.config. Then, I re-installed Oracle 11g 64 on my Windows 2008 server. Finally I placed ODAC on top of 11gx64's installation. The key to success is locating the correct ODAC to match the version of Oracle you have on your system.
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
To VERIFY you have the right ODAC installed correctly over oracle 11 g you have to look into [asp.net] and [ODP.net] directories to make sure they BOTH have 2.x's and 4's dirs in each bin and their presence in global cache 64.
Ater solving the ODAC installation problem, I start experimenting with oracle client dll's. I copied the Oracle.DataAccess.dll(64-bit) from bin [2.x] to my app's compiled bin only to watch my program still crashed with the same complaint that it cannot find the dependent DLL's. Then I copied the Oracle.DataAccess.dll from bin [4], then everything WORKS fine!!
Now the remaining question is why 4.112.4 not found in register cache GAC_64 is working great but the set of dll's registered in GAC_64 broke the program? Can't help not being confused.
See the resulting view of the working dlls ==>
If you acquire all those screens I show in this case, your MVC4 apps should fly high with Oracle 11 g 64-bit client! Good luck! I'll share mine with you!
Whenever I try to install SQL Server 2012 Express with Advanced Services I am getting this error:
I have tried both version (32-bit/64-bit) and re-downloaded multiple times.
How can I solve it ?
Check if you have .Net framework 4 installed at your machine. If not - download it and install it and then try again with SQL Server.
Also check this bug at Microsoft site about .Net framework 4 (there is workaround explained in the bug).
FWIW, I just downloaded and installed SQLEXPRADV_x86_ENU.exe from HERE on a vanilla Win7Pro/64 VirtualBox virtual machine and encountered no errors.
Edit
I also installed SQLEXPRADV_x64_ENU.exe from that same location on an older Vista machine. The SQL Server installer told me that it needed some new .NET components, then it proceeded to download and install them. I didn't need to manually install anything ahead of time.
Also perhaps worth noting:
Both of the machines on which my installs were successful had no anti-virus software installed. (They are development boxes behind a firewall and I don't do email or web surfing on them.)
I'm having problems migrating a PowerBuilder application from XP to Windows 7.
We've built the application in PowerBuilder on Windows XP, and when we attempt to install components in to component services on Windows 7 machines, we get compatibility errors. Everything works great on Windows XP. But I think because the DLL's on 7 are so different, it's having problems.
If the program was built using a PowerBuilder IDE in a Windows 7 environment, would that possibly fix the problem?
The application is divided into
- a server component running on Server 2003
- a client component which installs sucessfully on Win7
- proxy components that are generated into an MSI when the server components are installed.
The problem is only the proxy. The MSI doesn't want to work on Windows 7.
Without the proxy installed on the client desktops, the client can't communicate with the server.
When I run the MSI in compatibility mode on Windows 7, I get some details of the error. Here they are
Program Compatibility Issues found Incompatible Application Fix
application CCS_Proxy_XP_Exports
Issues found Incompatible Application CCS_Proxy_XP_Exports is
incompatible.
Fix application CCS_Proxy_XP_Exports Provides steps to fix the
incompatible application. CompatMode CompatMode UserVerifySolution
User Verification of Solution Verify_NO
Detection details Collection information Computer Name: ##########
Windows Version: 6.1 Architecture: amd64 Time: Wednesday, November
14, 2012 11:56:36 AM
Publisher details Program Compatibility Make older programs run in
this version of Windows. Package Version: 1.5 Publisher: Microsoft
Windows
Program Compatibility Make older programs run in this version of
Windows. Package Version: 1.0 Publisher: Microsoft Corporation
If I view more details on the event log, I get the following
“Product: Client Communications (Application Proxy) -- Error 1928.
Error registering COM+ Application. Contact your support personnel
for more information.”
General idea
Actually dll on the win7 platform are not different from previous ones. There can be differences related to the multiple and different C runtimes that live now in the WinSxS dll-hell directories but this should not impact powerbuilder (as I can say from my 11.5 classic release experience).
I suspect that you might have some problems related to the UAC and or ACL management. I recently upgraded some legacy PB applications by adding compatibility to the Vista / Win7 specifications.
In short : the application must run without needing administrative privileges, and must not try to modify data in privileged places like c:\ or c:\windows.
Thus everything must no more be installed in program files directory. The application binaries can be deployed in program files but if the application need to create / modify some files they must be deployed in a ProgramData subdirectory for user-shared datad and / or in the local user data files for the private data. The application has to be modified to create or find the files in the correct directories. If you do not comply to the standard, the file virtualization mechanism can hide a lack of rights and can simulate the files in a VirtualStore directory in the user local data but is just a workaround and it provides some other problems.
Com+ error
Given you error messages, if the proxy is also a PB application, given the fact that PB only produce 32bits binaries and that your system is a 64bits one, maybe that the tips to register a 32b COM+ onto a Win2008 could help you?
Thought, your proxy exe/dll file does not have manifest or manifest does not contains compatibility section. Try to add compatibility info to manifest.
I created SSIS will do task like get data from oracle to sql server.i run ssis package run in my local system.it is working fine but i deployed ssis package in remote system and trying access from sql procedure. I'm getting error like below.
Oracle client and networking components were not found. These components are supplied by Oracle Corporation and are part of the Oracle Version on 7.3.3 or later client software installation.
Please let know if any solution there?
Simplest solution: The Oracle client is not installed on the remote server where the SSIS package is being executed.
Slightly less simple solution: The Oracle client is installed on the remote server, but in the wrong bit-count for the SSIS installation. For example, if the 64-bit Oracle client is installed but SSIS is being executed with the 32-bit dtexec executable, SSIS will not be able to find the Oracle client.
The solution in this case would be to install the 32-bit Oracle client side-by-side with the 64-bit client.
Technology used: Windows 7, UFT 32 bit, Data Source ODBC pointing out to 32 bit C:\Windows\System32\odbcad32.exe, Oracle client with both versions installed 32 bit and 64 bit.
What worked for me:
1.Start -> search for Edit the system environment variables
2.System Variables -> Edit Path
3.Place the path for Oracle client 32 bit in front of the path for Oracle Client 64 bit.
Ex:
C:\APP\ORACLE\product\11.2.0\client_32\bin;C:\APP\ORACLE\product\11.2.0\client_64\bin
1.Go to My Computer Properties
2.Then click on Advance setting.
3.Go to Environment variable
4.Set the path to
F:\oracle\product\10.2.0\db_2\perl\5.8.3\lib\MSWin32-x86;F:\oracle\product\10.2.0\db_2\perl\5.8.3\lib;F:\oracle\product\10.2.0\db_2\perl\5.8.3\lib\MSWin32-x86;F:\oracle\product\10.2.0\db_2\perl\site\5.8.3;F:\oracle\product\10.2.0\db_2\perl\site\5.8.3\lib;F:\oracle\product\10.2.0\db_2\sysman\admin\scripts;
change your drive and folder depending on your requirement...
After you install Oracle Client components on the remote server, restart SQL Server Agent from the PC Management Console or directly from Sql Server Management Studio. This will allow the service to load correctly the path to the Oracle components. Otherwise your package will work on design time but fail on run time.
In my case this was because a file named ociw32.dll had been placed in c:\windows\system32. This is however only allowed to exist in c:\oracle\11.2.0.3\bin.
Deleting the file from system32, which had been placed there by an installation of Crystal Reports, fixed this issue