I am trying to create some script variables in T-SQL as follows:
/*
Deployment script for MesProduction_Preloaded_KLM_MesSap
*/
GO
SET ANSI_NULLS, ANSI_PADDING, ANSI_WARNINGS, ARITHABORT, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER ON;
SET NUMERIC_ROUNDABORT OFF;
GO
:setvar DatabaseName "MesProduction_Preloaded_KLM_MesSap"
However, when I run this, I get an error stating 'Incorrect syntax near ':'. What am I doing wrong?
The :setvar only works in SQL command mode, so you are possibly within normal SQL execution in the management studio and have not swapped to command mode.
This can be done through the user interface in SQL Server Management Studio by going to the "Query" menu, and selecting "SQLCMD mode."
Just enable sqlcmd mode in SQL Server Management Studio as described in following image.
FOR SQL2012:
go to :
tools/options/Query Execution and check the by default, open new queries in SQLCMD mode.
Hit the New Query button and make sure the variable definitions are highlighted, your script should run correctly now.
Previous versions:
http://blog.sqlauthority.com/2013/06/28/sql-server-how-to-set-variable-and-use-variable-in-sqlcmd-mode/
try replacing :setvar DatabaseName "MesProduction_Preloaded_KLM_MesSap"
with:
USE [MesProduction_Preloaded_KLM_MesSap]
GO
Related
I'm trying to execute some SQL file that contain a lot of SQL files inside. Just as a main.sql that contains all the others that should be executed.
main.sql :
SET ANSI_NULLS ON;
SET QUOTED_IDENTIFIER ON;
SET ANSI_PADDING ON;
#new_instance.sql
#new_instance_tbl.sql
#new_instance_views.sql
#new_instance_tbl_configs.sql
When I open the file in my SQL Server, the red underline appears:
Incorrect syntax near '#new_instance.sql'
and then if I try to execute this, the same failure appears, so...
How can I execute different "included" .sql files from one main SQL file?
If you are using SSMS (SQL Server Management Studio) you can enable SQLCMD Mode
However, the syntax for referencing and executing external files is a bit different, see this answer to: TransactSQL to run another TransactSQL script
:r C:\Scripts\Script1.sql
:r C:\Scripts\Script2.sql
:r C:\Scripts\Script3.sql
My question is regarding to SQL schema compare.
Database Schema Compare
When i generate script using SQL schema compare, script is generating in below format.
/*
Deployment script for Student
This code was generated by a tool.
Changes to this file may cause incorrect behavior and will be lost if
the code is regenerated.
*/
GO
SET ANSI_NULLS, ANSI_PADDING, ANSI_WARNINGS, ARITHABORT, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER ON;
SET NUMERIC_ROUNDABORT OFF;
GO
:setvar DatabaseName "Student"
:setvar DefaultFilePrefix "Student"
:setvar DefaultDataPath "F:\Data\"
:setvar DefaultLogPath "H:\Logs\"
GO
:on error exit
GO
/*
Detect SQLCMD mode and disable script execution if SQLCMD mode is not supported.
To re-enable the script after enabling SQLCMD mode, execute the following:
SET NOEXEC OFF;
*/
:setvar __IsSqlCmdEnabled "True"
GO
IF N'$(__IsSqlCmdEnabled)' NOT LIKE N'True'
BEGIN
PRINT N'SQLCMD mode must be enabled to successfully execute this script.';
SET NOEXEC ON;
END
GO
USE [$(DatabaseName)];
GO
PRINT N'Altering [dbo].[usp_InsertStudentData]...';
GO
.....
If i run below query in SQL Cmd mode then it is suppose to run.
But i dont want to run this query in SQL Cmd mode as our dba not approve this
Now my question is...
I need to execute script which not include SQL Command mode code ":setvar DatabaseName"
Let me know if you need more help in my question.
I have a very simple procedure with comments. Example:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE test
AS
BEGIN
-- Single line comment
SET NOCOUNT ON;
SELECT GETDATE();
END
GO
The script is saved as encoded UTF-8.
When I migrate this with flyway (successfully) and later check it through the management studio, I see that the multi-line comment is stripped off. Also when viewing the flyway migrated procedure SSMS complains about 'Inconsistent Line Endings'. What am I missing here?
Glad that moving the comment down helped you - as for your 2nd problem:
why i am getting "Inconsistent ending lines" warning window while executing sql script?
Quintessence: find what corrupts it and fix it ;o)
Manually
If you have notepad++ you can clean your scripts by opening them, then Edit/EOL Conversion/ and choose what EOLs you want
kindof automatic
see Windows command to convert Unix line endings?
--> be careful with the MORE thing, it kills your file if you use it inplace (inputfile=outputfile)
We're using Visual Studio Database Professional and it makes heavy use of SQLCMD variables to differentiate between environments while deploying.
I know there's several directives available for setting context (like :connect for server name). Is there a way within the script itself to force SQLCMD mode for execution? Part of our deployment process is to have DBA's examine and execute the scripts and it would be a nice safety net (so I don't have to remind them to set their execution mode to SQLCMD).
Not a solution, but as a work-around, you could embed your script in some warning. This post inspired me to this code:
SET NOEXEC OFF; -- previous execution may have toggled it
:setvar IsSqlCmdEnabled "True"
GO
IF ('$(IsSqlCmdEnabled)' = '$' + '(IsSqlCmdEnabled)')
BEGIN
PRINT('Use SqlCmd-mode!!');
SET NOEXEC ON;
-- RAISERROR ('This script must be run in SQLCMD mode.', 20, 1) WITH LOG
END
ELSE
BEGIN
PRINT('Using SqlCmd-mode')
-- insert the code you really want to execute:
-- ...
END
SET NOEXEC OFF; -- do not disable next execution in this session
This does not seem to be possible. I even checked the SSMS project mode.
However, if you create a database project in BIDS, the pre-deploy & post-deploy scripts run in SQLCMD mode by default.
I know that is not the answer you want, but it is the best I can give you w/o resorting creating a custom SSMS plugin that would do it for you based on some text in the script file.
I have a stored procedure which takes an XML parameter and inserts the data into multiple tables. If I run the stored procedure into a database using a SSMS query window, everything works fine. However, we have a custom installation program that is used to deploy stored procedures to databases, and when this is used, execution of the sp fails with this error:
INSERT failed because the following SET options have incorrect settings:
'ANSI_NULLS, QUOTED_IDENTIFIER'. Verify that SET options are correct for use with
indexed views and/or indexes on computed columns and/or query notifications
and/or xml data type methods.
The custom installation program does not use the correct settings when scripting in the stored procedures.
Setting these ( SET ARITHABORT ON; SET QUOTED_IDENTIFIER ON; SET ANSI_NULLS ON;) within the sp has no effect:
I have also tried setting these options for the open connection just before calling the sp in the code. This again does not have the desired effect.
It appears that the settings on the connection to the database while the sp is being run in to the database are what matters, not the settings when the sp is used.
I have experimented by playing with these settings in SSMS options, and this does appear to be the case. I would just like someone to confirm that this is definitely the case (if there is a way around I would love to hear it, but I'm not hopeful)
Unfortunately altering the installer program is not an option for me at the present time, so I'm looking at having to roll back a couple of weeks work; so if I do have to do this I want to be really sure (and have some evidence to back me up) that this is the only option
The settings applied with those at CREATE or ALTER time and are ignored at runtime.
SSMS has correct settings by default (so does sqlcmd, osql etc).
From BOL, CREATE PROC, "Using SET Options"
The Database Engine saves the settings
of both SET QUOTED_IDENTIFIER and SET
ANSI_NULLS when a Transact-SQL stored
procedure is created or modified.
These original settings are used when
the stored procedure is executed.
Therefore, any client session settings
for SET QUOTED_IDENTIFIER and SET
ANSI_NULLS are ignored when the stored
procedure is running. Other SET
options, such as SET ARITHABORT, SET
ANSI_WARNINGS, or SET ANSI_PADDINGS
are not saved when a stored procedure
is created or modified.