How can you get SQLCMD, when executing a SQL script file, to just output any errors or warnings it encounters?
I essentially dont want information based messages to be output.
It's not possible to prevent SQLCMD returning non-error output messages by passing it a parameter.
However, what you can do is redirect error messages to STDERR, then direct all other messages to NUL.
This is done by passing the -r parameter. From books online:
-r[ 0 | 1] msgs to stderr
Redirects the error message output to the screen (stderr). If you do not specify a parameter or if you specify 0, only error messages that have a severity level of 11 or higher are redirected. If you specify 1, all error message output including PRINT is redirected. Has no effect if you use -o. By default, messages are sent to stdout.
Set -r depending on exactly which error messages you want to display, but to display all error message output, an example command would be:
sqlcmd -Q "select 1 as a; select 1/0 as b" -E -r1 1> NUL
Just as an addition to this, if you are sending errors out to file, I found this https://www.simple-talk.com/sql/sql-tools/the-sqlcmd-workbench/
which I have used. If you omit setting the OUT, then you only get an error log created.
So you have a command like this :
sqlcmd -x -E -S MyServer -i C:\MySQLBatchToRun.sql
Then in MySQLBatchToRun.sql , something like this
USE MyDatabase
:Error C:\MyErrorLog.txt
:r C:\MySQLScript.sql
GO
In MySQLScript.sql you have the actual SQL to run. It's a bit convoluted, but works. The only issue I have is that it seems to create an empty error log file, even if there is not an error.
It looks like print statements are sent to stderr with -r1 so you can use them to log separate from your output like so:
sqlcmd -Q "print 'hello logfile';select 'Ted' as bro" -r1 1> C:\output.txt 2> C:\logfile.txt
This also works with -i inputfile like:
sqlcmd -i helloTed.sql -r1 1> C:\output.txt 2> C:\logfile.txt
helloTed.sql:
print 'hello logfile';
select 'Ted' as bro
Probably you could use -Q and insert exec a stored proc that contains prints.
Related
I want to run a SQL code using shell script and return the message whether the SQL query executed successfully or not. For this I have used unix script given below.
#!/bin/sh
sqlplus -S hr/hr#xe<<EOF
#emp.sql
EOF
var1=$(cat /cygdrive/d/scripts/output.txt | grep -c 'COUNT')
if [ $var1 -ge 1 ];
then
echo "success"
else
echo "failure"
fi
exit;
and emp.sql(called sql file) as
SET ECHO OFF
SPOOL D:\scripts\output.txt
SET LINESIZE 100
SET PAGESIZE 50
SELECT count(*) FROM employees;
SPOOL OFF;
EXIT 0;
When I execute the script I am getting output as
COUNT(*)
----------
107
./script1.sh: line 13: syntax error: unexpected end of file.
I don't know where I should put EOF statement exactly. Also I am not getting the status message whether it is success or failure which I want as output. Please help. Thanks in advance
SPOOL D:\scripts\output.txt Isnt this windows way of referring to a file where as in the shell script you referred to the file as /cygdrive/d/scripts/output.txt. I assume you are using linux shell to execute so I executed your script changing the spool line in sql file. It worked fine.
Edit: Also the \ that you used, for the spooled output.txt path, will cause the sqlplus to terminate. Hence the error line 13: syntax error: unexpected end of file. Perhaps add quotes to the path or use the same file path as you used in shell
I've been playing around with SQLCMD to output a .SQL results to a file. It is working but the actual SQL statements are also being displayed in the output file which I obviously don't want. I am using a .bat file to run the SQL File. The following command is what I have in my .bat:
SQLCMD -S MyServerName -d MyDBName -i C:\test\start.SQL -o C:\test\out.txt -e
In my start.SQL I have the following:
set nocount on
SELECT '<HEADER>', getDate(), '<HHEADER>'
SELECT UPPER(ACCTNUM),
CONVERT(VARCHAR(10),DATEEXP,126),
UPPER(OPERID),
CONVERT(VARCHAR,CREATE_TMSTMP,120)
FROM RETURNS
WHERE CREATE_TMSTMP < getDate()
AND CREATE_TMSTMP > getDate() - 1
SELECT '<TRAILER>', getDate(), '<HHEADER>'
set nocount off
In the output file the correct information is shown but it's a little ugly with dashes and such and even shows the SQL command that was executed. Is there any way to fix this problem. Am I doing something wrong here? Any help would be greatly appreciated.
Why are you using the -e option?
-e
Writes input scripts to the standard output device (stdout).
The dashes are part of the header. Use -h-1 to specify no header. If that is not acceptable use something like FINDSTR /B /V "----" to exclude that header line... assuming none of the lines you want to keep start with dashes.
I'm running DOS 6.0.6002 on a windows server enterprise system, SP2.
SQL Server 2008 R2 (10.50.4000)
I have a main control program in DOS.
I'm invoking an sql program through sqlcmd.
A simplified version looks like this:
set sqlsvr=myServer
set logfile=logfile.txt
sqlcmd -S %sqlsvr% -d myDB -i import_some_stuff.sql > "%logfile%" 2>&1
echo error level = %ERRORLEVEL%
I need this program to be pretty robust. It has to run every day against a lot of files and tables. If it fails, I need to catch it and notify sysadmin. For now, just catch it.
So to test this, I've tried the following tests:
1) Renaming the file to one that does not exist.
Result: it returns and errorlevel of 1 (that is it caught the error!) bravo!
2) typing in some syntactical rubbish at the front of the sql program.
Result: it prints the error message in the log file, BUT it DOES NOT return an error (so the return value in %ERRORLEVEL% is zero. This seems incredible to me. What am I missing?
Try the -b option to sqlcmd:
-b
Specifies that sqlcmd exits and returns a DOS ERRORLEVEL value when an
error occurs.
The value that is returned to the DOS ERRORLEVEL
variable is 1 when the SQL Server error message has a severity level
greater than 10; otherwise, the value returned is 0. If the -V option
has been set in addition to -b, sqlcmd will not report an error if the
severity level is lower than the values set using -V. Command prompt
batch files can test the value of ERRORLEVEL and handle the error
appropriately. sqlcmd does not report errors for severity level 10
(informational messages).
If the sqlcmd script contains an incorrect comment, syntax error,
or is missing a scripting variable, ERRORLEVEL returned is 1.
Here is the documentation
everyone!
I want to know what this line does:
sqlplus -s /nolog <<EOF
Any ideas?
Thanks for the help!
From the information that you provided in the comments:
sqlplus -s /nolog <<EOF
Fires up an instance of sqlplus with silent mode enabled (which, I believe, doesn't send out any output to the console screen), and without a login explicitly provided (hence the /nolog), and it's taking input from the string contained in the EOF heredoc (which probably contains login credentials).
Here is a quick overview of Oracle's documentation on sqlplus.
From HERE:
-s The silent option: it suppreses the output of the SQL*Plus banner, the command prompt and the echoing of commands.
/nolog Starts SQL*Plus but does not log on (connect) a user/session.
So it seems that starts SQL*PLUS without logging on a user/session (nolog option) and don't display info (silent option).
The full excerpt should probably be:
sqlplus -s /nolog << ABCDE
CONNECT user/pwd#database
-- DO SQL AND PLSQL STUFF
EXIT
ABCDE
Which is similar to running sqlplus -s user/pwd#database #script.sql where script.sql contains the sql, plsql stuff and the exit command. The << syntax is shell operator for heredoc, which means all following lines are variable-expanded if ${variables} are found, and the first line beginning with ABCDE (at the very beginning of the line, no spaces, no tabs) ends the input.
I have an expect script which I need to run every 3 mins on my management node to collect tx/rx values for each port attached to DCX Brocade SAN Switch using the command #portperfshow#
Each time I try to use crontab to execute the script every 3 mins, the script does not work!
My expect script starts with #!/usr/bin/expect -f and I am calling the script using the following syntax under cron:
3 * * * * /usr/bin/expect -f /root/portsperfDCX1/collect-all.exp sanswitchhostname
However, when I execute the script (not under cron) it works as expected:
root# ./collect-all.exp sanswitchhostname
works just fine.
Please Please can someone help! Thanks.
The script collect-all.exp is:
#!/usr/bin/expect -f
#Time and Date
set day [timestamp -format %d%m%y]
set time [timestamp -format %H%M]
#logging
set LogDir1 "/FPerf/PortsLogs"
et timeout 5
set ipaddr [lrange $argv 0 0]
set passw "XXXXXXX"
if { $ipaddr == "" } {
puts "Usage: <script.exp> <ip address>\n"
exit 1
}
spawn ssh admin#$ipaddr
expect -re "password"
send "$passw\r"
expect -re "admin"
log_file "$LogDir1/$day-portsperfshow-$time"
send "portperfshow -tx -rx -t 10\r"
expect timeout "\n"
send \003
log_file
send -- "exit\r"
close
I had the same issue, except that my script was ending with
interact
Finally I got it working by replacing it with these two lines:
expect eof
exit
Changing interact to expect eof worked for me!
Needed to remove the exit part, because I had more statements in the bash script after the expect line (calling expect inside a bash script).
There are two key differences between a program that is run normally from a shell and a program that is run from cron:
Cron does not populate (many) environment variables. Notably absent are TERM, SHELL and HOME, but that's just a small proportion of the long list that will be not defined.
Cron does not set up a current terminal, so /dev/tty doesn't resolve to anything. (Note, programs spawned by Expect will have a current terminal.)
With high probability, any difficulties will come from these, especially the first. To fix, you need to save all your environment variables in an interactive session and use these in your expect script to repopulate the environment. The easiest way is to use this little expect script:
unset -nocomplain ::env(SSH_AUTH_SOCK) ;# This one is session-bound anyway
puts [list array set ::env [array get ::env]]
That will write out a single very long line which you want to put near the top of your script (or at least before the first spawn). Then see if that works.
Jobs run by cron are not considered login shells, and thus don't source your .bashrc, .bash_profile, etc.
If you want that behavior, you need to add it explicitly to the crontab entry like so:
$ crontab -l
0 13 * * * bash -c '. .bash_profile; etc ...'
$