I'm using sql developer.
I want to run some scripts.
I don't want to have to include the folder name in the call to each script.
But I also want to use a variable to include the directory to look in (the working directory).
I can do this but i am having trouble with folder names with spaces (this is in windows).
Can anyone help me work out how to do this without having to rename my folder to remove spaces?
define dir="c:\Users\xx\Google Drive\Analytics\Recruitment\NSL\2. Data Understanding\Code"
#&dir\cb_nsl_impairments.sql;
Returns error
SP2-0310: Unable to open file: "c:\Users\xx\Google.sql"
Oops. Solved it.
Just needed double quotes around the script call:
#"&dir\cb_nsl_impairments.sql"
Related
I have two files in two different floder locations in Trace32. I execute cd.do file_name subroutine_name in Trace32. The trace32 takes the location of first command executed as the folder from which the following commands needs to be executed. How can I execute the routines from two different folders.
There is a pretty good guide here on how to script in Trace32.
http://www2.lauterbach.com/pdf/practice_user.pdf
I do not understand why you need to have them in two different folders, shouldn't it be solved by just have it in the same folder?
Well, maybe you should simply use DO <myscript.cmm> instead of CD.DO <myscript.cmm>.
DO <myscript.cmm> executes the script at the given location but keeps the current working path.
CD.DO <myscript.cmm> changes the working path to the location of the given script and then executes the script.
However I would recommend to write your scripts in a way that it doesn't matter if they are called with CD.DO or just DO. You can achieve that with either absolute paths or with paths relative to the script locations. (I prefer the 2nd one.)
So imagine the following file structure:
C:\t32\myscripts\start.cmm
C:\t32\myscripts\folder1\routines.cmm
C:\t32\myscripts\folder2\loadapp.cmm
C:\t32\myscripts\folder2\application.elf
You can cope this structure with absolute paths like that:
start.cmm:
DO "C:/t32/myscripts/folder1/routines.cmm" subroutine_A
DO "C:/t32/myscripts/folder2/loadapp.cmm"
folder2/loadapp.cmm:
Data.LOAD.Elf "C:/t32/myscripts/folder2/application.elf"
DO "C:/t32/myscripts/folder1/routines.cmm" subroutine_B
With relative paths you could use the prefix "~~~~" before accessing other files relative from the location of the currently executed PRACTICE script. The "~~~~" is replaced with the path of the currently executed script (just like "~" stands for your home directory.) There is also a function OS.PPD() which gives you the directory of the currently executed PRACTICE script.
So above situation with relative paths look like that:
start.cmm:
DO "~~~~/folder1/routines.cmm subroutine_A"
DO "~~~~/folder2/loadapp.cmm"
folder2/loadapp.cmm:
Data.LOAD.Elf "~~~~/application.elf"
DO "~~~~/../folder1/routines.cmm" subroutine_B
I thought for sure there would be an SO question on this, but I haven't been able to find one.
I have 2 SQL files, myFile1.sql and myFile2.sql. myFile1.sql calls myFile2.sql like so:
-- In myFile1.sql:
#scripts/myFile2
This works with no problem, but now I'd like to pass an argument to the file. I've tried doing the following, with no success (results in a File Not Found exception):
#scripts/myFile2 'ImAnArgument'
Does anyone know what the syntax would be to do this?
I'm guessing your problem is that scripts/myFile2.sql is a relative path from the script it is located in. If that is so, then it is following that path from the directory where SQL*Plus was started (the current working directory). If this is the problem, then it's not the parameter that is the issue, but rather that SQL*Plus can't find the file. In this case, you should use ##, which invokes the path relative to the file it's located in.
The parameter should work just as you proposed (documentation). Parameters provided when invoking a file are placed into substitution variables (rather than bind variables) and can be referenced by using an ampersand followed by the argument number. In your example, 'ImAnArgument' would be &1.
After many attempts, I wasn't able to pass a parameter in (and I still don't understand why not). But here is what I did to get the same affect:
-- In myFile1.sql:
DEFINE my_arg = 'ImAnArgument';
#scripts/myFile2
Then
-- In myFile2.sql
-- Do stuff using the variable my_arg, such as
SELECT my_arg FROM my_table;
First, this question relates to Oracle SQL Developer 3.2, not SQL*Plus or iSQL, etc. I've done a bunch of searching but haven't found a straight answer.
I have several collections of scripts that I'm trying to automate (and btw, my SQL experience is pretty basic and mostly MS-based). The trouble I'm having is executing them by a relative path. for example, assume this setup:
scripts/A/runAll.sql
| /A1.sql
| /A2.sql
|
/B/runAll.sql
/B1.sql
/B2.sql
I would like to have a file scripts/runEverything.sql something like this:
##/A/runAll.sql
##/B/runAll.sql
scripts/A/runAll.sql:
##/A1.sql
##/A2.sql
where "##", I gather, means relative path in SQL*Plus.
I've fooled around with making variables but without much luck. I have been able to do something similar using '&1' and passing in the root directory. I.e.:
scripts/runEverything.sql:
#'&1/A/runAll.sql' '&1/A'
#'&1/B/runAll.sql' '&1/B'
and call it by executing this:
#'c:/.../scripts/runEverything.sql' 'c:/.../scripts'
But the problem here has been that B/runAll.sql gets called with the path: c:/.../scripts/A/B.
So, is it possible with SQL Developer to make nested calls, and how?
This approach has two components:
-Set-up the active SQL Developer worksheet's folder as the default directory.
-Open a driver script, e.g. runAll.sql, (which then changes the default directory to the active working directory), and use relative paths within the runAll.sql script to call sibling scripts.
Set-up your scripts default folder. On the SQL Developer toolbar, Use this navigation:
Tools > Preferences
In the preference dialog box, navigate to Database > Worksheet > Select default path to look for scripts.
Enter the default path to look for scripts as the active working directory:
"${file.dir}"
Create a script file and place all scripts associated in it:
runAll.sql
A1.sql
A2.sql
The content of runAll.sql would include:
#A1.sql;
#A2.sql;
To test this approach, in SQL Developer, click on File and navigate and open the script\runAll.sql file.
Next, select all (on the worksheet), and execute.
Through the act of navigating and opening the runAll.sql worksheet, the default file folder becomes "script".
I don't have access to SQL Developer right now so i can't experiment with the relative paths, but with the substitution variables I believe the problem you're seeing is that the positional variables (i.e. &1) are redefined by each start or #. So after your first #runAll, the parent script sees the same &1 that the last child saw, which now includes the /A.
You can avoid that by defining your own variable in the master script:
define path=&1
#'&path/A/runAll.sql' '&path/A'
#'&path/B/runAll.sql' '&path/B'
As long as runAll.sql, and anything that runs, does not also (re-define) path this should work, and you just need to choose a unique name if there is the risk of a clash.
Again I can't verify this but I'm sure I've done exactly this in the past...
you need to provide the path of the file as String , give the patch in double quote it will work
**
For Example
#"C:\Users\Arpan Saini\Zions R2\Reports Statements and Notices\Patch\08312017_Patch_16.2.3.17\DB Scripts\snsp.sql";
**
Execution of Sql
#yourPath\yourFileName.sql
How to pass parameters in file
#A1.sql; (Parameter)
#A2.sql; (Parameter)
This is not absolute or relative path issue. It's the SQL interpreter issue, where by default it will look for files which are having .sql extention.
Please make sure to modify the file name to file_name.sql
Ex: if workspace is having file name called "A", then move the file from A to "A.sql"
I've been trying to get this re-build command working for a Windows 8 Project in Visual Studio 2012.
if "$(ConfigurationName)"==ReleaseOEM copy "$(ProjectDir)PackageOEM.appxmainfest" "$(ProjectDir)Package.appxmainfest" copy "$(ProjectDir)StoreManifestOEM.xml" "$(ProjectDir)StoreManifest.xml"
The xml file StoreManifest.xml is copied every time I do a rebuild; however the Package.appxmainfest is never changed.
What have I done wrong?
This worked in a test project ...
if "$(ConfigurationName)"=="Debug" copy "$(ProjectDir)Package.appxmanifest" "$(ProjectDir)Package2.appxmainfest"
The only real difference is I added quotes around Debug. It does not copy the file without the quotes. According to MSDN, you need to separate commands by line breaks. Yours should probably look something like ...
if "$(ConfigurationName)"=="ReleaseOEM" copy "$(ProjectDir)PackageOEM.appxmainfest" "$(ProjectDir)Package.appxmainfest"
if "$(ConfigurationName)"=="ReleaseOEM" copy "$(ProjectDir)StoreManifestOEM.xml" "$(ProjectDir)StoreManifest.xml"
I am trying to set up some path using environment variable.
I added an environment variable "MAVEN_HOME" with the value "C:\maven".
Then in the path I added "%MAVEN_HOME%\bin;...rest".
When I type "echo $MAVEN_HOME%" I get the correct "C:\maven" printed on the screen.
But when I type "mvn" which is a batch file in the "bin" directory, it can't find it.
So, I manually added the entire path in PATH.
"C:\maven\bin;...rest"
and it was able to find "mvn" and execute it.
Could someone help me what I did wrong?
Check if there is a space character between the previous path and the next:
Incorrect:
c:\path1; c:\Maven\bin\; c:\path2\
Correct:
c:\path1;c:\Maven\bin\;c:\path2\
I had exactly the same problem, to solve it, you can do one of two things:
Put all variables in System Variables instead of User and add the ones you want to PATH
Or
Put all variables in User Variables, and create or edit the PATH variables in User Variable, not In System. The Path variables in System don't expand the User Variables.
If the above are all correct, but the problem is still present, you need to check the system Registry, in HKEY_CURRENT_USER\Environment, to make sure the "PATH" key type is REG_EXPAND_SZ (not REG_SZ).
My issue turned out to be embarrassingly simple:
Restart command prompt and the new variables should update
Things like having %PATH% or spaces between items in your path will break it. Be warned.
Yes, windows paths that include spaces will cause errors. For example an application added this to the front of the system %PATH% variable definition:
C:\Program Files (x86)\WebEx\Productivity Tools;C:\Sybase\IQ-16_0\Bin64;
which caused all of the paths in %PATH% to not be set in the cmd window.
My solution is to demarcate the extended path variable in double quotes where needed:
"C:\Program Files (x86)\WebEx\Productivity Tools";C:\Sybase\IQ-16_0\Bin64;
The spaces are therefore ignored and the full path variable is parsed properly.
%M2% and %JAVA_HOME% need to be added to a PATH variable in the USER variables, not the SYSTEM variables.
If there is any error at all in the PATH windows will silently disregard it. Things like having %PATH% or spaces between items in your path will break it. Be warned
Also worth making sure you're using the command prompt as an administrator - the system lock on my work machine meant that the standard cmd just reported mvn could not be found when typing
mvn --version
To use click 'start > all programs > accessories', right-click on 'command prompt' and select 'run as administrator'.
To address this problem, I have used setx command which try to set user level variables.
I used below...
setx JAVA_HOME "C:\Program Files\Java\jdk1.8.0_92"
setx PATH %JAVA_HOME%\bin
NOTE: Windows try to append provided variable value to existing variable value. So no need to give extra %PATH%... something like %JAVA_HOME%\bin;%PATH%
If the PATH value would be too long after your user's PATH variable has been concatenated onto the environment PATH variable, Windows will silently fail to concatenate the user PATH variable.
This can easily happen after new software is installed and adds something to PATH, thereby breaking existing installed software. Windows fail!
The best fix is to edit one of the PATH variables in the Control Panel and remove entries you don't need. Then open a new CMD window and see if all entries are shown in "echo %PATH%".
I had this problem in Windows 10 and it seemed to be solved after I closed "explorer.exe" in the Task Manager.
In my Windows 7.
// not working for me
D:\php\php-7.2.6-nts\php.exe
// works fine
D:\php\php-7.2.6-nts
I had the same problem, I fixed it by removing PATHEXT from user variable. It must only exist in System variable with .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Also remove the variable from user to system and only include that path on user variable
Copy the value of path to notepad and check if this corresponds with the echo %path% in terminal window and make changes if needed. Then delete the old path value and paste the notepad value back in.
I assume some invisible character entered there by some installation corrupted the path value.
Make sure both your System and User paths are set correctly.