I'm trying to declare some variables using DBeaver and keep hitting this error.
Unterminated dollar-quoted string at or near "$$
DO $$
DECLARE A integer; B integer;
BEGIN
END$$;
Any ideas?
DBeaver was the issue. Switched to PGAdmin and no more problems.
As of DBeaver 6, you can execute the script with ALT-X (on Windows), which does not attempt to do variable capture/interpolation involving dollar signs.
The syntax posted is fine. Your problem is that the client application or driver is mangling the query, probably because it doesn't understand dollar-quoting.
It might be trying to split it into separate statements on semicolons, running:
DO $$ DECLARE A integer;
B integer;
BEGIN END$$;
as three separate statements. This would result in the reported error, e.g.
$ psql -c 'DO $$ DECLARE A integer;'
ERROR: unterminated dollar-quoted string at or near "$$ DECLARE A integer;"
LINE 1: DO $$ DECLARE A integer;
^
This is why you must specify your client driver/application when asking questions.
Another possibility with some clients is that it might treat $ as an escaped query-parameter placeholder and replace it with a single $ or try to substitute it for a server-side placeholder like $1. That's not what's happening here, though.
DBeaver also gives this error when there is a SQL syntax error in the script.
In my case, it was a pair of mismatched parenthesis in a select calculated column.
Related
Whenever i try to run a program consisting of user input the compiler always throws the same error of i dont know what that means. the error does not explain what the error is that i am encountering, can anyone please help regarding this problem.
Here is the error:
Unsupported Command
Unsupported Command
ORA-06550: line 6, column 4:
PLS-00103: Encountered the symbol "&" when expecting one of the following:
( - + case mod new not null <an identifier>
<a double-quoted delimited-identifier> <a bind variable>
continue avg count current exists max min prior sql stddev
sum variance execute forall merge time timestamp interval
date <a string literal with character set specification>
<a number> <a single-quoted SQL string> pipe
<an alternatively-quoted string literal with character set specifi
Here is the code for plsql in which i am taking user input for temperature and returning the celcius or farenheight temp of the same.
declare
f number;
n number;
ch char;
begin
f:=&f;
ch:=&ch;
if(ch!='F') then
n:=(f-32)*5/9;
else
n:=(f*9/5)+32;
end if;
dbms_output.put_line('Temperature: '||f||' '||ch);
end;
/
I would be highly grateful for your efforts.
Thank you
The & syntax indicates the variable is a substitution variable which is processed in the client application (it is effectively a find-replace on the variable).
Substitution variables are only supported by a limited number of client applications (including SQL*Plus and SQL Developer); they are not supported in other applications such as Oracle Apex, Java, C#, Python, etc.
You are getting the error because your client application does not support substitution variables; instead, you need to use the correct syntax for the application you are using (which may be to use bind variables).
This can be run in the "SQL Commands" window in apex, but you need to use the bind variable syntax :
declare
f number;
n number;
ch char;
begin
f:=:f;
ch:=:ch;
if(ch!='F') then
n:=(f-32)*5/9;
else
n:=(f*9/5)+32;
end if;
dbms_output.put_line('Temperature: '||f||' '||ch);
end;
/
This will invoke a popup window in which you are prompted for the values of :F and :CH.
I'm running PostgreSQL 9.4 and are inserting a lot of records into my database. I use the RETURNING clause for further use after an insert.
When I simply run:
... RETURNING my_car, brand, color, contact
everything works, but if I try to use REGEXP_REPLACE it fails:
... RETURNing my_car, brand, color, REGEXP_REPLACE(contact, '^(\+?|00)', '') AS contact
it fails with:
ERROR: invalid regular expression: quantifier operand invalid
If I simply run the query directly in PostgreSQL it does work and return a nice output.
Tried to reproduce and failed:
t=# create table s1(t text);
CREATE TABLE
t=# insert into s1 values ('+4422848566') returning REGEXP_REPLACE(t, '^(\+?|00)', '');
regexp_replace
----------------
4422848566
(1 row)
INSERT 0 1
So elaborated #pozs suggested reason:
set standard_conforming_strings to off;
leads to
WARNING: nonstandard use of escape in a string literal
LINE 1: ...alues ('+4422848566') returning REGEXP_REPLACE(t, '^(\+?|00)...
^
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR: invalid regular expression: quantifier operand invalid
update
As OP author says standard_conforming_strings is on as supposed from 9.1 by default working with psql and is off working with pg-prommise
update from vitaly-t
The issue is simply with the JavaScript literal escaping, not with the
flag.
He elaborates further in his answer
The current value of environment variable standard_conforming_strings is inconsequential here. You can see it if you prefix your query with SET standard_conforming_strings = true;, which will change nothing.
Passing in a regEx string unescaped from the client is the same as using E prefix from the command line: E'^(\+?|00)'.
In JavaScript \ is treated as a special symbol, and you simply always have to provide \\ to indicate the symbol, which is what needed for your regular expressions.
Other than that, pg-promise will escape everything correctly, here's an example:
db.any("INSERT INTO users(name) VALUES('hello') RETURNING REGEXP_REPLACE(name, $1, $2)", ['^(\\+?|00)', 'replaced'])
To understand how the command-line works, prefix the regex string with E:
db.any("INSERT INTO users(name) VALUES('hello') RETURNING REGEXP_REPLACE(name, E$1, $2)", ['^(\\+?|00)', 'replaced'])
And you will get the same error: invalid regular expression: quantifier operand invalid.
I have DB2 v9.7 client driver to access DB2 instance which is installed on Z/OS environment. I am trying to write and execute an anonymous procedure by the help of Toad for DB2 4.7. Unfortunately, none of the given example codes on the internet hurdled the syntax errors. Whatever i try, even very simple ones, not worked properly. I am curious about is there an execution mode of Toad or something that i missed on my tries. Here are my tries and syntax errors that i have received:
DECLARE
somechr VARCHAR2(255);
BEGIN
somechr:='some value';
END;
The sample above throws these errors:
DB2 Database Error: ERROR [42601] [IBM][DB2] SQL0104N An unexpected token "VARCHAR2" was found following "". Expected tokens may include: "TABLE STATEMENT , . SCROLL INSENSITIVE SENSITIVE ASENSITIVE ". SQLSTATE=42601
DB2 Database Error: ERROR [42601] [IBM][DB2] SQL0104N An unexpected token "SOMECHR" was found following "". Expected tokens may include: "DECLARE". SQLSTATE=42601
DB2 Database Error: ERROR [42601] [IBM][DB2] SQL0104N An unexpected token "END-OF-STATEMENT" was found following "". Expected tokens may include: "DECLARE". SQLSTATE=42601
The last one vanishes when i change the 'some value'; to 'some value';--
Some examples uses following syntax:
BEGIN
DECLARE somechr VARCHAR2(255);--
somechr:='some value';
END;
However, this syntax throws exception too:
DB2 Database Error: ERROR [42601] [IBM][DB2] SQL0104N An unexpected token "SOMECHR" was found following "". Expected tokens may include: "SECTION". SQLSTATE=42601
At last i have tried this:
BEGIN
DECLARE SECTION BEGIN
somechr VARCHAR2(255);--
END;
somechr:='some value';--
END;
And got these:
DB2 Database Error: ERROR [42612] [IBM][DB2] SQL0084N An EXECUTE IMMEDIATE statement contains a SELECT or VALUES statement. SQLSTATE=42612
DB2 Database Error: ERROR [42601] [IBM][DB2] SQL0104N An unexpected token "SOMECHR" was found following "". Expected tokens may include: " GET SQL SAVEPOINT HOLD FREE ASSOCIATE". SQLSTATE=42601
Besides these tries, some noted that use of '--#SET TERMINATOR #' at the beginning of the code, nevertheless it did not help as well for all examples above. I have given tries by changing the ';' to symbol '#' for all combinations (with or without '--#SET TERMINATOR #' statement), but erros does not seem to be vanished.
I work with DB2 LUW, not z/OS. That said, you might try this:
BEGIN
DECLARE V_SOMECHR NVARCHAR(255);
SET V_SOMECHR = 'some value';
END
My experience in DB2 LUW is that the declarations have to be inside the BEGIN block, and must come first, but there is no heading stating that it is a DECLARE section. You can place your procedural code immediately after the last declaration. Not sure if this will be the case in z/OS.
I am migrating some client side stuff into the server, and want to put it into a function.
I need to get the results of a query into a CSV file. But, I'd like to pass the file name/location of the resulting file as an argument of the function.
So, this is a simple example of what I want to do:
CREATE FUNCTION send_email_results(filename1 varchar) RETURNS void AS $$
DECLARE
BEGIN
COPY(SELECT * FROM mytable) TO filename1 WITH CSV;
END;
$$ LANGUAGE plpgsql;
Postgres is complaining about this though, as it is translating the filename1 argument to '$1', and it doesn't know what to do.
I can hardcode the path if need be, but being able to pass it as a parameter sure would be handy.
Anyone have any clues?
I just ran in to this. It turns out that you can't use parameterized arguments when the copy command is used (at least that's the case with python as the stored proc language). So, you have to build the command without arguments, like:
CREATE FUNCTION send_email_results(filename1 varchar) RETURNS void AS $$
DECLARE
BEGIN
execute 'copy (select * frommytable) to ' || filename1 || ' with csv;';
END;
$$ LANGUAGE plpgsql;
You might have to use the quoting feature to make it a little more readable. I don't know, I don't use plpgsql as a postgres function language, so the syntax might be wrong.
execute 'copy (select * frommytable) to ' || quote_literal(filename1) || ' with csv;'
What is wrong with following stored procedure?
CREATE PROCEDURE TEST
(IN mbr VARCHAR(30),
OUT sql_state CHAR(5)
)
DYNAMIC RESULT SETS 1 LANGUAGE SQL BEGIN DECLARE SQLSTATE CHAR(5);
DECLARE rs CURSOR WITH RETURN TO CLIENT FOR
SELECT
*
FROM
A.XYZ;
OPEN rs;
SET
sql_state = SQLSTATE;
END #;
According to Info Center, SQL Code -104 means that you have an illegal symbol somewhere. In the full error message, it should give an indication to where that illegal symbol is located.
My guess is that something is confused about your statement terminators, have a look at this article.
If you are running this in command editor then you simply need to
Change your default termination character from semi-colon (;) to something
else
and it will work.
You can see the IBM TechNote here : http://www-01.ibm.com/support/docview.wss?uid=swg21224723