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)
Related
I am using TOAD application to execute my query which you can see below:
SET FEEDBACK OFF;
SELECT * FROM TABLENAME
-- and then rest of the queries
I used SET FEEDBACK OFF in Toad app (by Quest Software) as an alternative to SET NOCOUNT ON in SQL, but it shows error and says:
ORA-00922: Missing or Invalid option
Is there any alternative to SET NOCOUNT ON that we write in SQL for Oracle?
SET set of commands - in Oracle - was originally related to its command-line tool named SQL*Plus. It (the SET) works in some other tools, such as Oracle's GUI - SQL Developer.
Mathguy showed me that TOAD recognizes quite a lot SQL*Plus commands (I thought it does not); it is the way you run code in TOAD:
if you run it as a separate command, it won't work:
on the other hand, if you run it as a script, then it works, and the result is displayed in its "Script output" tab:
I have about 100 of stored procedures with ansi_nulls off, and I am trying to set it ON. One way I can go to each stored procedure and set property>options>ansi_nulls ON, also can modify each of them with ansi_nulls ON and compile it. But it is very much time consuming to do for hundreds of SPs.
I would like to have a way where I can write a script to modify them with ansi_nulls on and execute it in same script without touching any system table.
Well, I can use sys tables to just query the SPs to list them which I need to modify.
I appreciate your help, thanks in advance.
What I would do and it certainly isn't time consuming:
In SQL Server Management Studio, right click the database in Object Explorer, go to Tasks, and Generate Scripts
Select "Select specific database objects" and check "Stored Procedures" and click Next
The default should be good (single file) on the Set Scripting Options screen except you need to pick your file output. Click Next and then Next again. It'll take a minute or five to generate the file.
Open the text/SQL file generated in a decent editor like Notepad++.
Mass replace CREATE PROCEDURE with ALTER PROCEDURE
If SET ANSI_NULLS OFF was created in the script, replace SET ANSI_NULLS OFF with SET ANSI_NULLS ON.
If SET ANSI_NULLS OFF was not created, replace ALTER PROCEDURE with SET ANSI_NULLS ON\r\nGO\r\nALTER PROCEDURE where \r\n is of course a Carriage Return Line Feed combo. If your text editor can't create CrLFs, get a better text editor.
The text file should now be good to execute to correct the issue. Test this before running the whole thing. Also, be sure to keep a backup of the original script.
Consider the following bit of SQL
SET DATEFORMAT ymd
SET ARITHABORT, ANSI_PADDING, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER, ANSI_NULLS, NOCOUNT ON
SET NUMERIC_ROUNDABORT, IMPLICIT_TRANSACTIONS, XACT_ABORT OFF
GO
USE master
GO
IF DB_NAME() <> N'master' SET NOEXEC ON
--
-- Create database [myDatabaseName]
--
PRINT (N'Create database [myDatabaseName]')
GO
CREATE DATABASE myDatabaseName
There is then a very long script setting up tables, views, stored procedures etc etc.
I would like to know if SQL would allow something along the likes of the following pseudo code;
If (myDatabaseName Exists)
Return // in other word abort the script here but don't throw an error
Else
//Carry on and install the database
I am aware of the Exists function in SQL but I can't seem to find anything that would simply abort the remains of the script straightaway.
This script will end up in an installation routine. In theory it should never be in an installer where the database is already present, however I would prefer not to take chances and prepare properly for a potential mistake. It is also crucial that the script does not throw any error as that will just cause the installer to roll back and install nothing.
I'm hoping that something exists in SQL that will just exit a script cleanly if particular conditions are met. By exit I really do mean exit as opposed to simply breaking out of the condition being currently evaluated.
The problem is, your client tool (SSMS, SQLCMd, etc) splits your script into batches based on the location of the GO keyword (it's a client tool thing, not SQL Server at all).
It then sends the first batch. After the first batch is complete (no matter what the outcome), it sends the second batch, then the third after the second, etc.
If you're running with sufficient permissions, a high-valued RAISERROR (severity 20-25) should stop the client tool in its tracks (because it forces the connection closed). It's not that clean though.
Another option is to try to set NOEXEC ON which still does some work with each subsequent batch (compilation) but won't run any of the code1. This allows you a slightly better recovery option if you want some batches at the end to always run, by turning it OFF again.
1Which means you still will see error messages for compilation errors for later batches which rely upon database structures that would have been created in earlier batches, if they weren't being skipped.
You can use GOTO as follows :
If (myDatabaseName Exists)
GOTO QUIT; // in other word abort the script here but don't throw an error
Else
//Carry on and install the database
QUIT:
SELECT 0;
There are several methods for that kind of request :
raiserror('Oh no a fatal error', 20, -1) with log
OR
print 'Fatal error, script will not continue!'
set noexec on
They should work and close the connection.
See here : Answer
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.
In MS SQL Server Management Studio 2005:
If you have the setting Tools|Options|Scripting|"Include IF NOT EXISTS clause" set to true, modifying a stored procedure will create a strange script that doesn't even work. It looks something like the following: (ellipsis used for brevity)
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS [...]
BEGIN
EXEC dbo.sp_executesql #statement = N'
ALTER procedure [dbo].[p_Procedure]
[...]
'
END
This obviously doesn't work because the only way the ALTER statement is called, is if the stored procedure DOESN'T exist.
The question is thus: is there any way of changing this generated code? A template out there somewhere (this doesn't seem to be related to the build in Templating tools)?
(A slight explanation for this behavior: scripting a CREATE statement generates the same code in which the IF NOT EXISTS makes more sense)
There are some issues on this topic on MS-feedback site.
Here are one:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=260519
Here are one comment on that issue (from the bottom of the page linked above):
In SQL2000, the approach was If
exists, DROP followed by a CREATE.
This worekd flawlessly and covered all
cases. It wored so well that we built
our deployment off of this scripting
model. Since SQl2005 entered our
world, we have had manual, cumbersome
workarounds to replace the automated
scripting that was lost in the move to
SQL2000.
Please do readd the If exists, DROP
followed by a CREATE approac. It was
great the way