I am trying to get a SQL Server Agent job to execute in command line the following code. It sets the variable to the server name of the SQL Server instance so that it can reach out to the UNC path and run the executable. This singular line works find when I run it on the server in command line through RDP, but fails when run in SQL Server as type Operating system (CmdExec). The line is:
FOR /F "usebackq" %i IN (`hostname`) DO SET _exeCall=\\%i\test\test1.exe && %_exeCall%
The results from the log are:
C:\Windows\system32>SET _exeCall=\\testbox\test\test1.exe && _exeCall
'%_exeCall%' is not recognized as an internal or external command,
operable program or batch file.
The machine is correctly titled testbox, the path and executable file are correct, but it does not appear to understand that it should be executing the variable _exeCall. This works properly when executed on the server in commandline, but not from SQL Server's commandline tool.
Related
We are executing SQL loader command from shell script on RH Linux OS. The command passes both control file and data file as command line parameters. The syntax used is given below (masked sensitive data):
sqlldr userid=$connstring control=/local/abc-1.2.3/instances/www.abc.com/apps/int/script/bin/ABC_CONTROL.ctl data=$f log=/local/abc-1.2.3/instances/www.abc.com/apps/int/script/logs/ABC.log bad=/local/abc-1.2.3/instances/www.abc.com/apps/int/script/logs/ABC.bad
The data file name is passed as dynamic variable in a FOR loop to process multiple files. The data file extension is *.app and path is /local/abc-1.2.3/instances/www.abc.com/apps/int/script/input.
We have verified that $f variable is able to correctly point to data file. Also verified file permissions. We tried changing the directory paths as well.
Still script fails with below error: **SQL Loader-500 Unable to open file (ABC_CTL.dat)**, SQL Loader-553 File not found, SQL Loader-509 System error: No such file or directory
The same script runs with exact same syntax on another server. Please suggest any solutions.
I am trying to run a .sql script on a schedule. I have created a batch file to run the script. The script runs fine in sql server management studio and also when I run the batch file content through cmd.
Contents of the batch file:
sqlcmd -S omfmesql -U OMESRV -P orat -i "\\pvsrv-
fsr14\data\Projects\Stat_Table_Creation_unique.sql"
The sql script is supposed to update a stat table. When I run it though cmd and refresh the stat table, the numbers are updated. But when I run this batch file through Task Scheduler, the only action that seems to be performed is running C:\Windows\SYSTEM32\cmd.exe
The task is stated to be completed successfully but the sql query is just not run.
I am not too experienced with Task Scheduler. Any help here would be very much appreciated. Thanks!
Note: I am not intending to use SQL Server Agent
If you have not done so, you need to set the location in Task Scheduler (TS). In at least some versions of TS, this can only be done when you create a basic task, not from the more general "Create Task..." option. Ensure that all the paths in the batch file are absolute or are based in this location.
I have a requirement to start ssms (SQL Management Studio) from the command line that connects to a (localdb)\myinstance. The instance exists
sqllocaldb info myinstance
but using the command line and the -S parameter with (localdb)\myinstance throws an error.
PS C:\workingArea> ssms -S(localdb)\myinstance
localdb : The term 'localdb' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:9
+ ssms -S(localdb)\myinstance
I can connect using the named pipe but would ideally like to use the known name.
You can try the following: ssms -S LOCALHOST\myinstanceto connect to a LocalDb instance
I am trying to copy a file in my Pre Deployment script for a Visual Studio SQL Database project.
:!!copy $(DataFileDirectory)\data.csv $(DataDestinationDirectory)
I found that this generated the error:
SQL72007: The syntax check failed 'Incorrect syntax near .' in the batch near: ':!!copy
So I tried to simplify my testing and tried:
:!! dir
This also failed:
SQL72007: The syntax check failed 'Incorrect syntax near .' in the batch near: ':!! dir
It fails when I try:
!! dir
I am able to execute commands like:
:r .\myfile.sql
I noticed the following error occurs whenever I do :!!,
72006: Fatal scripting error: Command Execute is not supported.
Why is command execute (:!!) not supported?!
This can, of course, only truly be answered by the designers of SSDT, but you can make an educated guess: it would compromise system security too much. It would allow you to run arbitrary commands on the database server's OS, under the account of the user that runs SQL Server itself.
The sqlcmd.exe command allows one to disable the :!! and :ed commands, using the -X command line option, for the same reason.
If you really need to run OS commands in your script, you could still fallback to xp_cmdshell, which of course also has issues, but at least the server's administrator can decide if it should be allowed.
There are a lot more SQLCMD syntax options, that SSDT pre- or post deployment scripts do not support (for example :connect or :on error, it seems). So, another explanation would be, that for the purpose of deployment scripts the :r and :setvar commands were considered sufficient.
I have a complex Powershell script that gets run as part of a SQL 2005 Server Agent Job. The script works fine, but it uses the "Start-Transcript $strLogfile -Append" command to log all of it's actions to a transcript file. The problem is that the transcript is always empty. It adds the header and footer to indicate that the transcript is starting and stopping, but it doesn't actually log anything. Example:
**********************
Windows PowerShell Transcript Start
Start time: 20100304173001
Username : xxxxxxxxxxxx\SYSTEM
Machine : xxxxx-xxx (Microsoft Windows NT 5.2.3790 Service Pack 2)
**********************
**********************
Windows PowerShell Transcript End
End time: 20100304173118
**********************
When I execute the script from a command prompt or start -> run everything works just fine. Here is the command used to run the script (same command used in the Operating system CmdExec step of the SQL Agent Job)
powershell.exe -File "c:\temp\Backup\backup script.ps1"
I first thought it must have something to do with the script running under the System account (default SQL Agent account), but even when I tried changing the SQL Agent to run under my own personal account it still created a blank transcript.
Is there any way to get PowerShell Transcripts to work when executing them as part of a 2005 SQL Server Agent Job?
If your script uses native commands (console exes), Start-Transript does not log any of that output. This issue has been logged on Connect, you can vote on it. One way to capture all input is to use cmd.exe:
cmd /c powershell.exe -file "C:\temp\backup script.ps1" > backup.log
sqlps.exe does not implement certain methods including the method that supports write-host. This may explain why you are not seeing output using Start-Transcript when running sqlps.exe from a SQL Agent Powershell jobstep. See http://blogs.msdn.com/mwories/archive/2009/09/30/the-use-of-write-host-and-sql-server-agent-powershell-job-steps.aspx for more information.
I am still not sure why the Powershell Transcript is empty, but we found a workaround. Under the CmdExec step of the SQL Job there is an advance option to capture the output to a file, which combined with the "Append output to existing file" option and using a Logfile.rtf extension is about the same as the Powershell transcript. This way anything that gets printed to the host from the Powershell script (including native console executables piped to "| out-host") will be captured in the log file.