I'm trying to install Oracle 11g Release 2 (client). But it gives an error like that :
Environment variable: "PATH" - This test checks whether the length of the
environment variable "PATH" does not exceed the recommended length.
Expected Value: 1023
Actual Value : 1028
List of errors: - PRVF-3929 : Adding the Oracle binary location to the PATH
environment variable will exceed the OS length limit of [ "1023" ] for the
variable on the node "KamalNuriyev-PC" -
Cause: The installer needs to update the PATH environment variable to
include the value "%ORACLE_HOME%/bin;". However, doing so will
cause PATH to exceed the maximum allowable length that this
operating system allows. - Action: Ensure that the sum of the
lengths of your current PATH environment variable and that of
"%ORACLE_HOME%/bin;" does not exceed the operating system limit.
Restart the installer after correcting the setting for
environment variable.
This limitation is based on older Windows restrictions, where length of environmental variables was important. This limitation is still there in the Oracle installation.
Work around this:
Step 1: Copy the value of your 'path' variable to a text-editor (Ex.: notepad) and save this value as backup.
Step 2: Reduce the size of this path to less that 1023 characters. Remove path variables at the end. You will mostly not need any of them during the oracle installation. Keep those removed values in a separate text-file, because you need to add them again later!
Step 3: Start the oracle installation again.
Step 4: After Oracle installation: Add those removed path values again at the end of the path.
Good luck!
For those who are facing this issue, solution would be to look into your Environment Variable "PATH" and bring it to shorter in length by removing unnecessary paths / repeating paths as suggested by Bob Javis in his comment. Thanks to him.
I had the similar issues and got it resolved by doing so.
To Edit ENV Variable on Windows 7:
Start -> Computer -> Properties -> Advanced System Settings -> On "System properties" window, select "Advanced" tab - > Click on "Environment Variable" -> Scroll down to see the PATH variable and click on "Edit" to edit accordingly and Click "OK" to save
Hope someone might get helped :)
You could check on the ignore all check box on top right and that should enable the next button to continue further.
One way of fixing this is to go to stage\cvu in the installer directory and edit cvu_prereq.xml, replace all values (there are multiple ones) containing 1023 with a larger number and then try to install it again.
Might need to do this after running the installer but before the installer does the check on the different requirements like the PATH length.
After trying with all I found this in the Oracle wiki:
What it says is that you should reduced your string's path changing the "C:\Program Files (x86)" to "C:\PROGRA~2"
Be sure to make a backup of the original path.
Simple,
Check path size, if unnecessary things are there removing that, if not, save it as it is.
And restart oracle installation process.
http://hashtutorial.com/plsql-tutorial/plsql-environment-setup/
Simple solution:
Rename your current PATH variable to PATH2
Then add a new PATH = %PATH2%
Continue with the installation
But, if you don't have unnecessary paths / repeating paths and you can't shorten it(beware! if you delete some necessary paths it can affect corresponding services!), go by removing some paths before oracle installation and return them after the installation.
Or, you can manually ADD the oracle path string in the system PATH variable(add it at the start of the string, not at the end) for your oracle installation.
As example, if you're installing Oracle 11g R2 in the path "c:\ora" then typically the path string for this will be,
C:\ora\product\11.2.0\dbhome\BIN -for server and
C:\ora\product\11.2.0\client_1\BIN -for client. :)
I used two approaches to shorten my PATH environmental variable:
1) Use other environment variables, e.g.:
%CommonProgramFiles(x86)% for "C:\Program Files (x86)\Common Files"
%ProgramFiles(x86)% for "C:\Program Files (x86)"
2) Use 8 character DOS path names, e.g.:
MICROS~4 for "Microsoft SQL Server"
* Your system may have a different number, in a CMD window, browse to the parent folder and type "dir /ad /x"
"%ProgramFiles(x86)%\Micros~4\140\DTS\Binn" is 15 characters shorter than "C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn"
I shrank the total length of the PATH from 1120 to 890. Then I could install the Oracle client without a problem.
I had this issue and the only way we could get the PATH test to pass was to remove the computer from the domain and re-add it. Can't explain why, but that worked for us. Best of luck.
In my case, I couldn't install an 11.2.0.4 32 bit client or the 12.2.0.1 64 bit client also, due to this error. After much investigation, I discovered there appears to be a bug when installing it on Windows 10 Enterprise 1703 as hinted at by this issue:
https://dba.stackexchange.com/questions/176774/environment-variable-path-exceeding-recommended-length
In my case, as I was using automation to install this, I ended up recreating my virtual machine as Windows 10 Enterprise LTSC and no longer have this error. In my case, it had nothing to do with the actual path as I had shortened to the point where barely anything was left and it was not enough to resolve the issue.
You can try to run install as administrator.
Hope it helps
Related
I have checked my ORACLE_HOME in 3 different ways in my windows 32-bits PC in this order:
1.- In cmd, if I type echo %ORACLE_HOME% the result is just:%ORACLE_HOME%, so no current path. Why?
2.- In regedit, under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1, the stored value is C:\oracle\product\11.2.0\client_1
3.- Finally, in the variable Path in Environment variables these are the oracle-related ones values (I disguise the others by using asterisks) in the same order they appear:
C:\ProgramData\Oracle\Java\javapath;C:\oracle_python\instantclient_11_2;C:\oracle\32bit\product\11.2.0\client_1\bin;*;*;C:\oracle\product\11.2.0\client_1\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;*;*;*;*;*;*;*;*;C:\Program Files\Java\jdk1.7.0_60\bin
In addition, I operate with Oracle only in two ways basically: I use SQL Developer daily but also I do some scripting in Python by using the cx_Oracle library.
My question is whether I have properly optimized the ORACLE_HOME variable or not, I mean would an expert in Oracle agree with this current scenario?
When you do echo %ORACLE_HOME% then you interrogate the Environment variable ORACLE_HOME. In your case it is not set.
Some tools use (only) the Environment variable for ORACLE_HOME, other use the Registry value. I think most programs use both and give precedence over Environment variable.
I assume for your Oracle Client following folders are relvant:
C:\oracle_python\instantclient_11_2
C:\oracle\32bit\product\11.2.0\client_1\bin
C:\oracle\product\11.2.0\client_1\bin
Looks like you installed Oracle client three times (all into different folder). I do not consider this as an optimized setup. My recommendation is to remove all of them and make one single proper installation.
Check also How to uninstall / completely remove Oracle 11g (client)? in case of problems.
I've been installing programs with chocolatey, but it's not adding them to my path automatically. Does anyone know a solution? I just followed the install instruction on Chocolatey's front page, and everything works well. The programs just aren't being added to the path.
It depends on what you install, and whether those native installers add themselves to the path in some cases.
If the package maintainer doesn't take the extra step in the cases where the installer doesn't add a program folder to the PATH, then those items may not be available on the command line.
The other side of this is that those items may be in PATH, but not to your current shell (cmd/powershell/whatever). This is due to how Windows works versus terminal in *nix. We've made some improvements there but it's not perfect. Expect things to get better over time in that aspect.
We have one issue out for ensuring that we create the User PATH correctly in the registry. This might be what is causing the issue for any items that may be adding themselves to this PATH instead of the system PATH.
I am creating a visual studio setup project using vs2010. I want my application to be installed in c:\manufacturer\ProductName. I used [HOMEDRIVE] as the defaultLocation of "ApplicationFolder" which will points to c:\ at the installation time. However, when i put [HOMEDRIVE][Manufacturer]\[ProductName] as the defaultLocation, it raises an error at the installation time saying "Could not access network location Manufacturer\ProductName". I appreciate any kind of help or suggestion.
You can use this default path:
[WindowsVolume][Manufacturer][ProductName]
WindowsVolume property is automatically resolved to the Windows partition (usually C:). Also, all predefined folder property values are ended with a backslash (). So you don't need to add one after WindowsVolume.
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
This issue was resolved with SQL Server 2008 R2 Cumulative Update 5 / SP1 / SQL Server 2012 RTM
On occassion when I try to build a Reporting Services project as part of either deploying or previewing a report in Visual Studios I receive the following error:
Access to the path 'C:\My Solution Folder\bin\Debug\My Report.rdl' is denied.
What appears to happen is the file in the \bin\Debug\ folder has been changed to read-only. I can "fix" the symptom by removing the read-only flag on the impacted file. I would like to find a way to avoid this error altogether since this happens usually multiple times a day.
I verified the file is not being saved to my source control system, so it doesn't seem like my source control plugin would cause this problem. The problem seems to have started with SQL Server 2008 R2 and this makes sense given that I am pretty certain the \bin\Debug\ folders didn't exist prior to this version of the Reporting Services project.
I tried changing the project OutputPath to a path that is not under the project folder, but Visual Studios would't allow me to do this.
It's a known bug with Microsoft that was corrected by CU5 and later in SP1. The issue did not occur at all in SQL Server 2012 RTM.
https://connect.microsoft.com/SQLServer/feedback/details/543755/fiserv-tap-checking-it-rdl-source-sets-output-folder-to-read-only
Basic workaround is to build once, unset the read-only attribute on all files in the reporting project's BIN folder and it'll all work again...until you edit a file again.
I suspect this is due to VSS marking files as read-only once checked in...VS then copies the resources (*.RDL) to the BIN folder verbatim i.e. with read-only attribute set.
You can use Process Monitor to find out which process changes that. All you need to do is set up a filter with full path the file in interest and watch for any operations done on this file. Also turn off all the other monitors like registry and network. They are on the the main toolbar on the right.
The following isn't a fix, persay, but it's a workaround that doesn't get much better until your server is updated. Constantly deleting the bin folders for projects got old real fast and I'm stuck on a server instance with the issue, and it seemed like a good job for a simple batch script.
It just recursively deletes every folder named 'bin' in your project directory.
BINZAP.bat
Create a new text file in your windows\users\YOURNAME directory
This location allows easy access from a normal cmd prompt if needed.
Paste in the code block below this list
Replace the ellipsis with your system's path
Save it as BINZAP.bat (good naming is very important)
Right click on your desktop.
Create a new shortcut.
Point it to the batch script.
Right click the short cut and click in the “Shortcut key” text box
Press Z, or another key if that key chord is already assigned to something else.
#echo off
cd "C:\ ... \Reports"
for /d /r . %%d in (bin) do #if exist "%%d" rd /s/q "%%d"
echo.
echo All your bin are belong to us.
echo.
pause
exit
If you've done this correctly, you can now simply press CTRL+ALT+Z, or whichever key you chose, from Visual Studio whenever you get the error. Much easier!
Enjoy!