I have several PL/SQL scripts that are transforming data accoriding to specification day by day. I would like to run them in the loop for each day of the year. Is this possible to handle somehow in Toad?
I have found that I can run some other scripts by calling them via #name_of_script , but it doesn't work for me in Toad.
I just need something like:
BEGIN
FOR i IN day1 TO dayx
EXECUTE SQL1;
EXECUTE SQL2;
EXECUTE SQL3;
END LOOP;
END
Is there any way how to run these scripts somehow "managed" except to change them to procedures? Thank you for answer.
# is an SQLPlus command
But toad partially supports it too: there are 2 common options:
Use SQL Editor - it should execute scripts in case of # command as in SQL*Plus
Use "Execute as script" --> "Execute via SQL plus": it should start SQL*plus connected to your database, there you can run your scripts.
Related
3GLs provide mechanisms to prepare statements before executing them. E.g.
SELECT name
FROM people
WHERE age=:AGE
The same query can then be executed for different ages. But can such a statement also be prepared in a "plain" Oracle SQL client? Can the same be done in e.g. SQL Plus or dbForge Studio for Oracle as in Java or C# or any other programming language that supports prepared statements?
In dbForge Studio for Oracle, named parameters can be used, preceded by a colon :
SELECT *
FROM people
WHERE name=:name
The parameters can then be filled in with the "Edit parameters dialog box", available from the SQL toolbar.
I know you didn't ask about PostgreSQL but about Oracle. However, of note, PostgreSQL has this feature right in its SQL language.
The SQL standard includes a PREPARE statement, but it is only for use in embedded SQL. The PostgreSQL version of the PREPARE statement works like this:
PREPARE nameByAge(number) AS
SELECT name
FROM People
WHERE age=$1;
and you use it like this:
EXECUTE nameByAge(18);
EXECUTE nameByAge(50);
So unfortunately for Oracle SQLPlus the answer seems to be no, not bind variables. But SQLPlus has substitution variables, similar to shell scripts. You use them as &1, &2, &3, ... and they get their parameters from the way you call the SQLPlus script.
sqlplus user/password #script.sql 18
sqlplus user/password #script.sql 50
with the script.sql being
SELECT name
FROM People
WHERE age=&1;
this would work, even though it is not bind. But then, do you really care about the slight savings in repeat parse time? In fact Oracle hashes SQL statements and already replaces constants with bind variables to be able to better reuse query plans. So the savings you would get with PREPARE and BIND are really minuscule.
I found this line in a sql code:
#../../sql_scripts/create_tables.sql
What does it do? I know that ##file.sql means that file.sql is run and # could be used when we want to supply parameter values later, but here I have # followed by a filename. I know that there is a similar question but it covers only # in queries.
Here the # is not part of the SQL language. It is likely a command for the SQL interpreter which is probably Oracle SQL*Plus.
SQL*Plus has many single-character commands like # or / (which executes buffered SQL), ; which can be puzzling when you encounter them in an .sql file.
# is documented here in Oracle 9i documentation. There you will see the differences with ##.
documentation for Oracle 11g Release 2, click Next section for ## reference.
The # allows you to import another script into the sql script you're running in SQL*Plus.
For example, this executes the contents of otherscript.sql at the specified point:
PROMPT about to run other script
#otherscript.sql
PROMPT finished running other script
Another example, this inserts the contents of another file into the middle of a statement to be executed in SQL*Plus:
SELECT * FROM mytable WHERE
#predicates_for_mytable.sql
AND bla = 1;
The only condition is that # must appear at the 1st character on the line.
I would like to run some ad hoc select statements in the IBM System I Navigator tool for DB2 using a variable that I declare.
For example, in the SQL Server world I would easily do this in the SQL Server Management Studio query window like so:
DECLARE #VariableName varchar(50);
SET #VariableName = 'blah blah';
select * from TableName where Column = #VariableName;
How can I do something similar in the IBM System I Navigator tool?
I ran across this post while searching for the same question. My coworker provided the answer. It is indeed possible to declare variables in an ad hoc SQL statement in Navigator. This is how it is done:
CREATE OR REPLACE VARIABLE variableName VARCHAR(50);
SET variableName = 'blah';
SELECT * FROM table WHERE column = variableName;
DROP VARIABLE variableName;
If you don't drop the variable name it will hang around until who knows when...
At the moment, we're working on the same issue at work. Unfortunaly, we concluded that this is not possible. I agree, it would be great but it just doesn't work that way. iNavigator doesn't support SET or Define. You can do that in embedded SQL but this is not embedded SQL. Even if you create a separate document (xxx.sql), then need to open this document to run the script what makes it an interactive script (that is, DECLARE SECTION is not allowed).
As an alternative, in the SQL screen/script you can use CL:. Anything after this prefix is executed as CL command. You may manipulate your tables (e.g. RNMF) this way.
As a second alternative, the iSeries does support Rexx scripts (default installed with the os). Rexx is good dynamic script language and it does support embedded SQL. I've done that a lot of times and it works great. I even created scripts for our production environment.
Just create one 'default' script with an example PREPARE and CURSOR statement and copy at will. With that script you can play around. See the Rexx manual for the correct syntax of exec-sql. Also, you do have STDIN and STDOUT but you can use 'OVRDBF' to point to a database table (physical file). Just let me know if you need an example Rexx script.
Notice that the manual "SQL embedded programming" does have Rexx examples.
Here are a couple of other alternatives.
Data Transfer Tool - You can run the iSeries Data Transfer Tool from the command line (RTOPCB). First, run the GUI version and create a definition file. If you edit this file with a text editor, you will see that this is just an old-fashioned INI file and you can easily find the line with the query in it. From there, you could write a batch file or otherwise pre-process the text file to allow you to manipulate the query before submitting it to the query tool.
QSHELL - If you can log on to the iSeries interactively, then you may find the QSHELL environment more familiar than CL or REXX (although REXX is kind of fun). QSHELL is a full POSIX environment running on the iSeries. Use the command STRQSH to start QSHELL. You can have ksh or csh as a shell. Inside QSHELL, there is a command called "db2" that submits queries. So, you should be able to do something like this inside QSHELL:
system> VariableName = 'blah blah'
system> db2 "select * from TableName where Column = \'$VariableName\'"
You may have to fiddle with the quotes to get ksh to pass them correctly.
Also, inside QSHELL, you should have a full Perl installation that will allow you to use DBI to get data.
Some other ways to interact with data on the iSeries: query from the client with Python via ODBC; query from the client with Jython via JDBC; install Jython directly on the iSeries and then query via JDBC.
I have an oracle script that I am trying to convert to valid db2 syntax. Within this sql file I have various calls to other sql files passing in a parameter using the '#' syntax.
e.g.
#script1 param1
#script2 param2
Can anyone help me with valid db2 equivalent statements? Is there an equivalent run command in db2? is it possible to pass parameters to a sql script in db2?
thanks,
smauel
The thing you are after is the DB2 Command Line Processor (CLP).
If you want to execute a script, you would execute in the CLP:
db2 -vtf script1
-f tells the CLP to run command input from the given file.
Here's the full list of options.
Unfortunately db2 doesn't support passing parameters to a script. You would have to combine your db2 -vtf commands with other scripting commands (such as sed) to generate the scripts for you, as in this example.
1) place the filename.sql file in SQLLIB/BIN
2) run db2cmd
3) execute this to connect to the required db
db2 connect to *dbname* user *userid* using *password*
4) excute this command
db2 -vtf *filename.sql*
This should execute the sql statements in the file one by one. The sql statements must be ending with a semicolon
There is an easier way for passing in parameters, that works fine for us (it might not work with (complex) multiline sql statements).
Convert your sql-script into a shell script by adding 'db2 ' at the beginning of each line. Than you can use the standard variable replacement syntax from your shell in your scripts.
so instead of
insert ...
update ...
you will have
db2 insert ...
db2 update ...
Place file in one directory.
Open db2cmd.exe as administrator
Navigate to directory where you have place the script
type db2 -vtf `
While entering a SQL statement in Oracle SQL Developer, I noticed that I have two choices. I can either "Run Statement" or "Run Script". A similar choice seems to be available in SQL Maestro as well, although named "Execute query" and "Execute as script".
What exactly is the difference between the two?
Run Statement will give you a list of all the results in a sortable table. It will also only run the statement under the cursor (or highlighted). You will be prompted for bind variables when you run the statement (any place holder with : in front of it).
E.g.
select * from customers where customer_id = :id
will prompt for a value for id
Run Script will execute all statements in the worksheet, and give a text readout of the results. It will not prompt you for the values of bind variables.
I think
"Execute Statement" - mean if you want to get results (resultset)
"Run Script" - is something you need to execute but don't need a results, like installing database dump, or upgrade script to add columns to the table etc.