I would like to run commands which is placed in 1.sql file This is my code:
$sth=$dbh->do( q { #1.sql } );
But this code isn't working:
There is output:
DBI::db=HASH(0xf18edc0) trace level set to 0x0/2 (DBI # 0x0/0) in DBI 1.634-ithread (pid 10389)
-> do in DBD::_::db for DBD::Oracle::db (DBI::db=HASH(0xf18ee50)~0xf18edc0 ' #1.sql ') thr#eebf010
dbd_st_execute (STMT TYPE 0) (out0, lob0)...
Statement Execute Mode is 32 (COMMIT_ON_SUCCESS)
-> DESTROY for DBD::Oracle::st (DBI::st=HASH(0xf18f190)~INNER) thr#eebf010
ERROR: 900 'ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ')' (err#1)
<- DESTROY= undef at run.pl line 12
!! ERROR: 900 'ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ')' (err#0)
<- do= undef at run.pl line 12
DBD::Oracle::db do failed: ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ') [for Statement " #1.sql "] at run.pl line 12.
DBD::Oracle::db do failed: ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ') [for Statement " #1.sql "] at run.pl line 12.
! -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0xf18edc0)~INNER) thr#eebf010
ERROR: 900 'ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ')' (err#0)
! <- DESTROY= undef during global destruction
No, that won't work (obviously). Some DBI drivers support multiple statements (MySQL and SQL Server via ODBC come to mind), but I don't think Oracle does. At any rate, you'd still have to handle the file reading part yourself. As you can see in the DBI docs, do() is expecting a valid SQL statement, which the string #1.sql is not.
Your basic options for executing an SQL file from Perl are:
Split the SQL file yourself and then execute each statement.
If you have control of the file and know it won't contain anything tricky, this is a fairly easy task. It could be as easy as splitting the file based on a semicolon character, or you might want to add some basic stripping of comments first.
However, this is quite hard to do 100% correctly for the full range of possible file content (what if an SQL statement has a string containing a semicolon? What if there are nested sets of comments? etc.). This requires fully parsing the file--and I'm not aware of any tool that allows you to do this easily. There is an SQL::Parse module, but I don't think it handles multiple statements.
Call an external program from Perl to do it for you.
For example, call the Oracle command line client. This is easy, but you don't have granular control of the statements being executed.
Related
I have no idea but this is throwing an error i think it is on line "set #al = 2020". I have read the documentation and not seeming to translate over.
begin
declare #al int;
set #al = 2020;
exec dbo.get_egus_trdg_desk_rpt_no_clrg_broker(#al int);
end
Error message:
SQL Error [102] [42000]: Incorrect syntax near ';'.
You do not need to use ';' after every line of code. I can successfully generate the following script in SQL Server 2019.
Sample Output
I'm playing hackthebox machine's and current one has a postgresql db in place. The query breaks with ' and appeas as follows:
ERROR: unterminated quoted string at or near "'" LINE 1: Select * from
cars where name ilike '%test'%' ^
I understand that % is being used to search within the query string for the characters provided but, What is ^ used for?
Bold highlights my test query
All my searches yielded resulst regarding regexes and caret signaling the start of the string. Plus other result about using cli or something like that.
Can anybody tell me what is it doing at the end of the query?
Your are looking for the use of the caret specifically within error messages.
If I run this query:
psql -c " Select * from cars where name ilike '%test'%'"
This is what I get, preserving line breaks and spaces:
ERROR: unterminated quoted string at or near "'"
LINE 1: Select * from cars where name ilike '%test'%'
^
The caret points to where on the previous line the error occurred. In this case, that is where the opening quote mark that never got closed was located.
If you are using a tool which malformats your error messages, you should consider changing to one that does not or otherwise figuring out how to fix it.
I installed Mimic3 database in Pg11, and try to query using the code from here: https://mimic.physionet.org/tutorials/intro-to-mimic-iii-bq/ solution to step 1.
SELECT ie.subject_id, ie.hadm_id, ie.icustay_id,
ie.intime, ie.outtime
FROM `physionet-data.mimiciii_clinical.icustays` ie;
but I got the error.
ERROR: syntax error at or near "`"
LINE 3: FROM `physionet-data.mimiciii_clinical.icustays` ie
^
, Time: 0.004000s
And if I deleted those two backticks, I got the warning.
ERROR: syntax error at or near "-"
LINE 3: FROM physionet-data.mimiciii_clinical.icustays ie
^
, Time: 0.002000s
And if I explaced ` with ", it showed the error that:
ERROR: relation "physionet-data.mimiciii_clinical.icustays" does not exist
LINE 3: FROM "physionet-data.mimiciii_clinical.icustays" ie
^
, Time: 0.002000s
Hope somebody can tell me what was wrong. Thank you!
Postgres doesn't use backticks to quote table names, it uses double quotes, and dots aren't allowed in names without quoting, so you probably want this:
SELECT ie.subject_id, ie.hadm_id, ie.icustay_id,
ie.intime, ie.outtime
FROM "physionet-data.mimiciii_clinical.icustays" ie;
With Postgres 10.10, here is what I am trying to accomplish. I want to have a test.sql script file (executed by \i /path/test.sql) whose code execution depends on what the user inputs after an initial prompt.
For instance, with code below I would like some text to be echoed and a table to be created, but the echoed text and the table name should depend on the text passed by the user as input to a prompt:
\prompt 'What is your favourite color?' answer
IF ('blue' = :answer) THEN
\echo 'It is blue! :) '
CREATE TABLE blue;
ELSE
\echo 'It is something else. :( '
CREATE TABLE :answer;
END IF;
However, a few errors prevent that from working:
myuser=# \i /home/myuser/test.sql
What is your favourite color?red
It is blue! :)
psql:/home/myuser/test.sql:4: ERROR: syntax error at or near "IF"
LINE 1: IF ('blue' = red) THEN
^
It is something else. :(
psql:/home/myuser/test.sql:7: ERROR: syntax error at or near "ELSE"
LINE 1: ELSE
^
psql:/home/myuser/test.sql:8: ERROR: syntax error at or near "IF"
LINE 1: END IF;
^
myuser=#
Notice that this is not the same as asked in https://dba.stackexchange.com/questions/207666/how-do-i-use-the-input-from-a-prompt-in-a-conditional-if. Also, I tried adapting it to follow the answer in Postgres syntax error at or near "IF", but then I just get more errors, starting with "syntax error at or near 'DO'".
Is there a way for me to accomplish this task? That is, every time an user executes the test.sql file with \i, the user is prompted and the execution of the code within the file branches depending on the text that the user inputed via prompt?
Something like this:
SELECT :'answer' = 'blue' AS isblue \gset
\if :isblue
...
\endif
I've tried setting 'log_min_error_statement' equal to debug5 in postgresql.conf but I'm still getting the standard "PostgreSQL said: syntax error at or near "AS"" error message in both the console and the postgresql log.
If PostgreSQL knew what the error was it'd tell you, at least in most cases.
If it just says "Syntax error at or near ..." it doesn't know what you meant, and can't guess what's wrong. It's a parse error. It could offer a (very long) list of suggestions, but that'd make error messages absurdly verbose, like:
postgres=# SELECT AS fred ORDER BY 1;
ERROR: syntax error at or near "AS"
LINE 1: SELECT AS fred ORDER BY 1;
Yup, that's a syntax error, because it doesn't make sense on any level. What's wrong with it? How do you succinctly describe that? How does a parser even tell what's wrong?
postgres=# SELECT AS fred ORDER BY 1;
ERROR: syntax error at or near "AS"
LINE 1: SELECT AS fred ORDER BY 1;
HINT: typo?
HINT: Did you use a reserved keyword as an identifier without "quoting" it? Like "AS"?
HINT: Did you leave out the value before the AS keyword?
HINT: ... endless possibilities ...
Occasionally a parser can guess something you might've done wrong. PostgreSQL's parser tries to tell you when it can, e.g.
psql -c "SELECT 'openquote";
ERROR: unterminated quoted string at or near "'openquote"
LINE 1: SELECT 'openquote