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.
Related
I'm using Powershell 4 to install SQL 2014. everything goes ok except at the very end where I have a function that will run a script from a .sql file using invoke-sqlcmd. I get the following error:
"The term 'invoke-sqlcmd' is not recognized as the name of a cmdlet, function, script file..."
If I try and import the sqlps module I get:
The specified module 'sqlps' was not loaded because no valid module file was found in any module directory.
But here's the kicker. If I open a separate PowerShell terminal, IT WORKS THERE. :/ and continues to fail in the initial terminal.
I'm trying to understand why this is so any assistance would be greatly appreciated. I'd like to avoid writing in a reboot once script.
Thanks,
Dan
Existing Powershell session isn't aware about Sql's modules that were just installed. Take a look at environment variable $env:PSModulePath. Compare new shell's variable to existing and you should see a missing path like ...\Microsoft SQL Server\110\Tools\PowerShell\Modules\.
For a work-around, modify the path to include module dir. Like so,
$env:PSModulePath += ";c:\some\path\to\sql"
In MS SQL Server Management Studio in SQLCMD Mode I use this script to run another script:
:setvar path "C:\workspace\scripts\scripts\"
:r $(path)'VERSIONS.sql'
But it gets this error:
A fatal scripting error occurred. The file specified for :r command
was not found.
VERSIONS.SQL is definitely in the specified folder. Why is this script not working when I run it?
EDIT: Something to note. The database I'm running this script against is not on my local machine. (I hope that's not the reason this isn't working)
I just solved my own problem. I changed the single quotes around VERSIONS.sql to double quotes and it worked.
Why are they not interchangeable?
Take a look at Get puppet build to fail when the contained SQL script fails execution
I was attempting to run a vagrant build which installs Oracle XE in an Ubuntu Virtualbox VM and then runs a an SQL script to initialize the Oracle Schema. The vagrant build is here : https://github.com/ajorpheus/vagrant-ubuntu-oracle-xe. The setup.sql is run as a part of the oracle module's init.pp (right at the bottom or search for 'oracle-script').
When running the SQL script as a part of the vagrant build, I see the following error:
notice: /Stage[main]/Oracle::Xe/Exec[oracle-script]/returns: Error 6 initializing SQL*Plus
notice: /Stage[main]/Oracle::Xe/Exec[oracle-script]/returns: SP2-0667: Message file sp1<lang>.msb not found
notice: /Stage[main]/Oracle::Xe/Exec[oracle-script]/returns: SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory
There were two things that were instrumental in me finding a workaround for the problem:
As suggested in this answer, setting the logoutput attribute to true for the exec block under question immediately showed me the error, whereas before the exec was just failing silently.
It seemed strange that I was able to run the command (sqlplus system/manager#xe < /tmp/setup.sql) after manually logging in as the 'vagrant' user. That suggested that there was something missing in the environment. Therefore, I copied all ORACLE env. vars into the exec as seen on Line 211 here
That worked, however, setting up the env vars manually seems a bit brittle. Is there a better way to setup the ORACLE environment for the vagrant user? Or, is there a way to get puppet to setup the environment for the vagrant user similar to an interactive shell?
If some profile has been set up to give the user a working interactive shell, you should be able to pass your action through such a shell
command => 'bash -i -c "<actual command>"'
As an aside about logoutput, since you mentioned that - the documentation advises that "on_failure" is a sane default, as it will only bloat your output when there are actual errors to analyze. It is the actual default in the latests versions of Puppet.
Earlier this morning I trying to create DLL for my DB2 database but it kept giving the following message:
The DB2 Administration Server encountered a script error. Script
error code "1".
Explanation:
A script error was encountered while the DB2 Administration server was
executing the script. The script exited with error code "".
User response:
Verify that the script is correct.
If you continue to receive this error message after attempting the
suggested response, refer to the DB2 Administration Server's First
Failure Data Capture Log for additional information or contact IBM
Support.
can anyone help me on this?
my user is ROOT and schema is SQLJ
command is db2look -d OBDB -z SQLJ -u ROOT -e -l -x -c ;
Error code is SQL22220.
i once too had this problem. may be you are trying to generate dll for more than 30 tables at a time. reduce the no. of tables and see if this works. worked for me though but errors can be due to other reason as well, plz let me know.... :)
MSBUILD - When executing DDL file I get this error:
Unexpected System.Reflection.TargetInvocationException error executing SQL command
Before this execution two other ones are executed with no problems.
I'm assuming that you're using the ExecuteDDL task from the MSBuild Community Tasks library. If so, I've run into the same issue before and I have always found that the script fails if I run it manually in SQL Management Studio.
I recommend that you run the two scripts that succeeded, then running the on that's failing manually and make sure that it doesn't have any errors.