I have read another entries about this topic, but none of them works for me.
I'm runnign SQL*Plus from bash shell in Linux. The SQL*Plus version is:
SQL*Plus: Release 10.2.0.1.0 - Production
I've tried to enable the help facility as per this FAQ:
http://www.orafaq.com/wiki/SQL*Plus_FAQ#How_does_one_enable_the_SQL.2APlus_HELP_facility.3F
But I got an error importing the help scripts:
DROP VIEW HELP_TEMP_VIEW
*
ERROR en línea 1:
ORA-00942: la tabla o vista no existe
Now, if I try to get the help for the SELECT command, I get a message telling me the there's no help available for this subject:
SQL> help select
SP2-0172: No se ha encontrado la ayuda que coincida con este tema.
If I perform "help index" to show what topics are covered by the built-in help, it seems that only SQL*Plus commands are covered, but none of the SQL sentences:
SQL> help index
Enter Help [topic] for help.
# COPY PAUSE SHUTDOWN
## DEFINE PRINT SPOOL
/ DEL PROMPT SQLPLUS
ACCEPT DESCRIBE QUIT START
APPEND DISCONNECT RECOVER STARTUP
ARCHIVE LOG EDIT REMARK STORE
ATTRIBUTE EXECUTE REPFOOTER TIMING
BREAK EXIT REPHEADER TTITLE
BTITLE GET RESERVED WORDS (SQL) UNDEFINE
CHANGE HELP RESERVED WORDS (PL/SQL) VARIABLE
CLEAR HOST RUN WHENEVER OSERROR
COLUMN INPUT SAVE WHENEVER SQLERROR
COMPUTE LIST SET XQUERY
CONNECT PASSWORD SHOW
It would be great to get help for SQL commands, as in the mysql client. Any help is more than welcome. Thanks in advance
I've peeked into the scripts and the ORA-00942 is normally expected and does not break anything.
This works as designed. Oracle just didn't supply HELP for SELECT, UPDATE, CREATE, etc, presumably because they would be huge pages. The internal sqlplus commands that you've seen with HELP INDEX are all you can expect.
The help contents are in the file helpus.sql in open text. I've tried to google for something similar from any old version but to no avail. If you really wish to have some customized HELP contents, I think you are on your own to write your own script along the lines of helpus.sql and to add the topics as you wish.
SQL> alter session set current_schema=system ;
SQL> INSERT INTO HELP VALUES ('TEST123', 1, 'Just testing...' ) ;
SQL> commit;
SQL> help test123
Just testing...
Related
How can I get all the codes and commands which was executed previously command line SQL of the Oracle 10G Express Edition to new SQL command line?
Like from tempfiles or something else. My OS is Windows.
Here's how I do that:
open CMD
connect to the database using SQL Plus
recall previous commands by pressing the "UP" keyboard key
they are recalled line-by-line, not as a whole command, which means that if you'd like to recall something like this:
select ename
from emp
where deptno = 10
you'll need to press the UP key 3 times
note that - if you want to run the last command (no matter how many lines it spans) - enter slash / at the SQL> prompt and hit the ENTER key
even if you exit SQL Plus, no problem as long as you keep the same CMD window open; just connect again and the same functionality will still be available, in your new SQL Plus session
however, it'll be lost if you close the CMD window
The bottom line is: GUI tools are much more appropriate in this context.
I have two DB instances both running PG 9.4
When i issue the COPY command in one it will return with the number of rows affected, however in the second DB which is set up the same it will not.
I see nothing in the config that is different or may affect such. The imports do not error and import successfully on both accounts.
The Documentation states it should return as long as its not stdout.
This line in the documentation looks pertinent, but i'm not sure it applies to my situation.
Do not confuse COPY with the psql instruction \copy. \copy invokes COPY FROM STDIN or COPY TO STDOUT, and then fetches/stores the data in a file accessible to the psql client. Thus, file accessibility and access rights depend on the client rather than the server when \copy is used.
The command i'm issuing is:
COPY [tablename] from '/var/lib/pgsql/datafile.csv'
At the moment i'm down to looking at putty session variables, but i'm not sure this is the way to go.
Does anyone have any ideas as to why this may be happening?
When psql is quiet, it doesn't display these messages.
The quiet mode is activated with -q or \set QUIET on
Example:
test=# copy test to '/tmp/foo';
COPY 8
test=# \set QUIET on
test=# copy test to '/tmp/foo';
test=#
For a migration I have automatically built scripts containing anonymous blocks for every entity to update and keep a log table for the results.
DO $$
DECLARE productId varchar;
BEGIN
productId := getProductId('9783980493017');
update product set ...;
...
EXCEPTION
WHEN OTHERS THEN
insert into mig_messages(createddate,identifier,message)
values(now(), '9783980493017', SQLERRM);
END $$;
This works fine so far. But when I run these scripts with psql every DO is printed on the prompt. This sounds a bit silly, but there are lots of scripts with lots of product update blocks in it (about 5 millions or more). How can I suppress this output without redirecting it completely to /dev/null or switching psql to silent? At last there MAY be some output I want to see (errors, warnings etc.).
I would prepend the script with this line:
SET client_min_messages=WARNING
Or start psql with that setting in the environment (I am using this in bash).
env PGOPTIONS='-c client_min_messages=WARNING' psql ...
This way you still get messages with severity WARNING or higher.
Related:
How to suppress INFO messages when running psql scripts
Reduce bothering notices in plpgsql
I have a bunch of SQL scripts (with shell script wrappers) to unload data like so
EXPORT TO /tmp/out.csv OF DEL MODIFIED BY NOCHARDEL COLDEL, DATESISO
MESSAGES /tmp/out.msg SELECT WIDGETID
...
I want to add an error handler to the script the way Oracle does it:
WHENEVER SQLERROR EXIT FAILURE;
SPOOL /tmp/out.csv;
SELECT WIDGETID...
SPOOL OFF;
According to DB2's documentation, this can be done in stored procedures, C, Perl, REXX, and nothing else...
How can this be done in SQL scripts?
I am running DB2/LINUXX8664 9.7.2.
you could use the DB2 command line command processor and get its return code. http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.admin.cmd.doc/doc/r0010411.html
or you could use the SYSPROC.ADMIN_CMD procedure and use its return codes. http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0023573.html
you could put the stored proc calls in a script file and run something like db2 -tvf runexport.txt or put the db2 commands in a linux script file and use linux scripting foo to handle the db2 return codes.
Is there a way to specify that when executing a sql script it stops when encountering the first error on the script, it usually continues, regardless of previous errors.
I think the solution to add following to .psqlrc is far from perfection
\set ON_ERROR_STOP on
there exists much more simple and convenient way - use psql with parameter:
psql -v ON_ERROR_STOP=1
better to use also -X parameter turning off .psqlrc file usage.
Works perfectly for me
p.s. the solution found in great post from Peter Eisentraut. Thank you, Peter!
http://petereisentraut.blogspot.com/2010/03/running-sql-scripts-with-psql.html
I assume you are using psql, this might be handy to add to your ~/.psqlrc file.
\set ON_ERROR_STOP on
This will make it abort on the first error. If you don't have it, even with a transaction it will keep executing your script but fail on everything until the end of your script.
And you probably want to use a transaction as Paul said. Which also can be done with psql --single-transaction ... if you don't want to alter the script.
So a complete example, with ON_ERROR_STOP in your .psqlrc:
psql --single-transaction --file /your/script.sql
It's not exactly what you want, but if you start your script with begin transaction; and end with end transaction;, it will actually skip everything after the first error, and then it will rollback everything it did before the error.
I always like to reference the manual directly.
From the PostgreSQL Manual:
Exit Status
psql returns 0 to the shell if it finished normally, 1 if a fatal
error of its own occurs (e.g. out of memory, file not found), 2 if the
connection to the server went bad and the session was not interactive,
and 3 if an error occurred in a script and the variable
ON_ERROR_STOP was set.
By default if the sql code you are running on the PostgreSQL server error psql won't quit an error. It will catch the error and continue. If, as mentioned above, you set the ON_ERROR_STOP setting to on, when psql catches an error in the sql code it will exit and return 3 to the shell.