I try to run several SQL-Statements in an SQL Script action for an Oracle dbms inside an installer and as part of a JDBC container action.
The script is encoded as UTF-8, and contains several statements, delimited by ";" and a new line between each statement, like this
statement 1;
statement 2;
...
The statements contain installer variables that are replaced before execution. I used the semicolon as a statement separator in the SQL script action.
The first statement throws an error
Error executing script line "CREATE user testconuser identified by xxx TEMPORARY TABLESPACE temp;",
error message: "ORA-00911: invalid character"
The statement itselfs works fine within SQLPLUS, but the problems seems to be the semicolon, that is still part of the statement executed by install4j.
In a JDBC sql statement, semicolons are not valid.
I also tried to remove the semicolons from the statements and used "\n" as statement delimiter, but then the sql script actions fires all sql statements within the script at once, so it looks like the "\n" is not recognized.
I am using install4j 6.1.5 build 6349. The platform is windows and the sql script is build on windows.
Any idea what I should change?
Any help would be highly appreciated, thanks a lot in advance,
Alex
I used the semicolon as a statement separator in the SQL script action. The first statement throws an error Error executing script line
and
I also tried to remove the semicolons from the statements and used "\n" as statement delimiter
Both are bugs in 6.1.5 and will be fixed in 6.1.6. Please contact support#ej-technologies.com to get a build where you can verify that this will work for you.
Related
I am using Oracle SQL Developer 4.0.3.16, and since a few weeks, the shortcut Ctrl+Enter doesn't execute the current line or statement anymore, except for when I highlight it, but instead does run my whole worksheet. Using the green button on the top, which is supposed to only run the current line results in the same behaviour (except for when the line is highlighted). Hovering over the button still reveals the tooltip "Run Statement (Ctrl+Enter)". A colleague of mine does get this problem too.
I also looked into the Preferences->Shortcut Keys menu, but the shortcut set for running a statement is still Ctrl+Enter.
Anyone knows what's wrong with my SQL Developer?
Every SQL statement in SQL Developer should have semicolon ; otherwise ctrl+Enter would execute will execute entire worksheet.
Suppose for example I have two SQL statements:
1.select * from emp without semicolon ;
2.UPDATE EMP SET DEPT_ID=10; WITH SEMICOLON ;
Then it will execute both statement simultaneously for that you should have semicolon after each SQL statement.
I faced it too. Usually you'll have PL/SQL block above the SQL code you are trying to execute. Comment out the PL/SQL block which is DECLARE, BEGIN without ending in semicolon creating this issue. So commenting the PL/SQL block in worksheet should solve your issue.
Thanks to the answer here: if it doesn't work even with a semicolon after the line like it didn't for me (Oracle SQL Developer 3.2.20.10), you need to put a '/' after each command if you want to execute them all independently, e.g.:
blahblah;
/
blahblah;
/
Think of the '/' as the real terminator/separator here.
I think I kinda solved it.
Since I'm not an administrator on the computers at work I couldn't install a new client, so I downloaded the SQL Developer in version 4.0.3.16 a while ago and just ran it locally from my user directory.
Meanwhile the client 4.0.3.16 is installed on the OS and when using this client I don't get this bug.
Thanks for the help though.
Sometimes it works anyway if I forget the ;. But sometimes it doesn't.
And in JDBC and Android SQLite, it seems that I don't need ; at all. I am confused.
When should I use a semicolon?
semicolon indicates end of a statement, so if there are multiple statements then you should use semicolon else it will work fine.
I generally use semicolon as a practice, it can be useful even when you are running queries on sql client e.g. in Sql Developer using semicolon is very helpful if you have multiple statements on worksheet, as you can simply go to that particular statement and use F9 to execute that, without semicolon this is not possible.
It is not mandatory if you run a single query at time, it comes necessary instead if you want to run multiple query with a single command.
However in most of JDBC drivers out there it is not possible to add multiple query separated with semicolon in a single JDBC Command, it exist however the addBatch method that allow you to add multiple statements :
java.sql.Statement stmt=con.createStatement();
stmt.addBatch(insert_query1); //insert_query1
stmt.addBatch(insert_query2); //insert_query2
As a rule of thumb, in JDBC semicolon is not necessary at all, if you need multiple statement use addBatch.
Usually the semicolon is not part of the actual syntax of a statement (as most database internal APIs execute a single statement at a time). Instead the semicolon is an 'end-of-statement' marker or statement separator that is - usually - defined in CLI or scripting tools for the database. This allows that tool to know when a statement ends, so it can send that single statement to the database for execution.
On the other hand, the JDBC API is intended to execute a single(!) statement at a time, therefore you don't need such a separator (the statement is the whole string). This means that a semicolon is not needed, and as it is not part of the actual statement syntax for a lot of database it is also a syntax error to include it. Some JDBC drivers will strip the last ; from a statement to 'fix' that, some drivers don't.
Some drivers allow - contrary to the JDBC specification - multiple statements to be executed as a single string, this usually has to be enabled with a connection property, for example for MySQL it is the option allowMultiQueries (see the MySQL properties for details).
Depends on the DBMS and version number. Semicolons are often optional at the end of a single statement. But if you are going to execute a script with more than one statement, they need to be terminated by a semicolon.
Except maybe the last one. But it seems bad form to be inconsistent.
Context
We're changing our install scripts to use ant's "sql" task and jdbc rather than proprietary sql clients sqlplus (oracle) and osql (msft).
Updated: added more context. Our "base data" (seed data) consists of a collection of .sql files containing "vendor-neutral"(i.e. works both in oracle and mssql) sql statements.
The Problem
The scripts run fine, with one exception:
This sql fails in Oracle. Specifically, something (ant or jdbc driver) treats the dashes/hyphens as "beginning of a comment"--even though they are embedded in a string. Note that the same sql works fine with ant/sql and microsoft's jdbc driver.
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----');
Related Bug
This ant bug appears to identify the problem. As it's still open (after 8 years), I'm not hoping for a fix soon. However, because the problem appears only in oracle, it may lie with the driver.
The oracle driver: jdbc thin driver, version 10.2.0.1.0
The Question
Does anyone have a workaround which works in both mssql and oracle? (e.g. changing the offending lines to define an escape character? I don't see an 'escape' on the 'insert' sql92 syntax)
thanks
After viewing the 'SQLExec' source and turning on verbose logging, I found a workaround:
Workaround
if the sql statement includes a string containing '--', place the delimiter (semi-colon) on the next line.
This Fails
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----');
This Succeeds
Note that semi-colon is on a separate line
INSERT INTO email_client (email_client_id,generated_reply_text) VALUES(100002,'----- Original Message -----')
;
Details
Turning on verbose logging, I saw that when Ant came across the offending sql statement, it actually passed three sql statements in at once to the jdbc driver. The offending statement, the next statement (which also included an embedded '--'), and the subsequent statement (which did not include an embedded '--').
I gave the Ant code a quick glance and didn't see any obvious errors. Since I wasn't planning to patch Ant, I looked for a workaround.
Tweaking with it I found that if I simply moved the delimiter (semicolon) to the next line for the statements with embedded '--', the scripts executed successfully.
thanks everyone for weighing in
You could try this:
INSERT INTO email_client (email_client_id,generated_reply_text)
VALUES(100002,LPAD('-',5,'-') || ' Original Message ' || LPAD('-',5,'-'));
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 `
I write:
CREATE TABLE Person (
name CHAR(10),
ssn INTEGER);
and save it to a file "a.sql".
If I then run it by typing "#a" in the SQL*Plus command prompt, it will tell me that the line starting with "ssn" is not recognized as a command, and is ignored.
From what I gather, it seems that sqlplus terminates a command if it encounters multiple newline characters in a row. Is this an accurate statement? If so, does anyone know if this is necessary/ why it chooses to do this?
I don't know about the why, but a completely blank line terminates a command in SQL*Plus.
Quote from the SQL*Plus docs :
Ending a SQL Command:
You can end a SQL command in one of three ways:
with a semicolon (;)
with a slash (/) on a line by itself
with a blank line
You can also change how blank lines are treated with SET SQLBLANKLINES
SQLBL[ANKLINES] {ON|OFF}
Controls whether SQL*Plus allows blank lines within a SQL command or script. ON interprets blank lines and new lines as part of a SQL command or script. OFF, the default value, does not allow blank lines or new lines in a SQL command or script or script.
Enter the BLOCKTERMINATOR to stop SQL command entry without running the SQL command. Enter the SQLTERMINATOR character to stop SQL command entry and run the SQL statement.
By default, SQLPlus does terminate (but not execute) a statement when a blank line is entered. It has always done this. It probably seemed like a good idea in the days before screen editors and query tools.
You can change that default behaviour with
set SQLBLANKLINES on
In which case you'd have to enter a line with just a full stop to terminate (but not execute) a statement.
But if you are wanting to insert multiline text in a varchar2 or a clob field, you may use
chr(10)
insert into t values ('Hello,'||chr(10)||chr(10)||' How are you?');
insert into t values (
'Hello,
How are you');
will not work for reasons explained above.