I have a stored procedure that has several transactions in a loop:
WHILE #COUNT < #MY_NUM
BEGIN
BEGIN TRANSACTION
-- DO STUFF HERE
IF(##ERROR != 0)
BEGIN
ROLLBACK TRANSACTION
BREAK
END
COMMIT TRANSACTION
END
I would now like to test whether or not my ROLLBACK TRANSACTION and BREAK logic will work by purposely introducing an error to the loop after a certain number of runs and look at the data.
Furthermore, I run these stored procedures from a shell script. So, I would like to test by using Ctrl + C in the middle of a run. Will this work? If not, how can I purposely introduce an error?
Thanks
You could do one of the following:
Intentially cause an error like Divide by zero
Use RaiseError()
You can to use print:
WHILE #COUNT < #MY_NUM
BEGIN
BEGIN TRANSACTION
print 'BEGIN TRANSACTION'
-- DO STUFF HERE
print '-- DO STUFF HERE'
IF(##ERROR != 0)
BEGIN
ROLLBACK TRANSACTION
print 'ROLLBACK TRANSACTION #MY_NUM: %1!',convert(varchar,#MY_NUM)
BREAK
END
COMMIT TRANSACTION
print 'COMMIT TRANSACTION'
END
Here it's link to documentation.
Related
I'm learning T-SQL and trying to get my head around how to approach it/best practices. Working through some examples, there are three questions I have:
1) Coming from Python, is there a generally agreed upon style guide (something like PEP 8) or approach for laying out T-SQL or is it more like JavaScript where anything goes?
2) When creating stored procedures and functions I see some authors always use a main BEGIN/END block and others don't. At first I thought you need BEGIN/END if you have more than one statement. However, this doesn't seem to be true because I have seen lengthy stored procedures with no main BEGIN/END. Any thoughts on this?
3) Within stored procedures, some authors seem to like to enclose parts of their code in BEGIN/END blocks. I can't see why you'd do this and wonder if I'm missing something. For example:
CREATE PROCEDURE <NAME> (
<Parameter List...>
)
AS
BEGIN
-- Setup:
-- Declare/initialize variables...
BEGIN TRY
BEGIN TRANSACTION
-- Validity check 1:
IF #Param1 ...
BEGIN
-- Do stuff...
END
-- Validity check 2
IF #Param2 ...
BEGIN
-- Do stuff...
END
-- Update - added BEGIN/END after if blocks for clarity
-- Why wrap these statements in a BEGIN/END Block???
BEGIN
--Add the entry
INSERT dbo.JournalClientFamilyChanges (
HouseholdMembersID,
PreviousClientsID,
NewClientsID,
ActionTaken,
Notes,
ModifiedBy,
ModifiedDate
)
VALUES (
#HouseholdMembersID,
#PreviousClientsID,
#NewClientsID,
#ActionTaken,
#Notes,
#ModifiedBy,
SYSDATETIME()
)
SET #success =1;
SET #ErrorStatus ='';
COMMIT TRANSACTION;
END
END TRY
BEGIN CATCH
-- Error handling...
END CATCH
END
Any thoughts appreciated,
--Jim
To answer your question at your own example
IF #Param1 ...
-- Validity check 2
IF #Param2 ...
-- Why wrap these statements in a BEGIN/END Block???
BEGIN
--Add the entry
INSERT dbo.JournalClientFamilyChanges (
HouseholdMembersID,
...
)
VALUES (
#HouseholdMembersID,
#PreviousClientsID,
...
)
SET #success =1;
SET #ErrorStatus ='';
COMMIT TRANSACTION;
END
There is an IF which will call the code below just under certain circumstances. Without the BEGIN ... END this will be valid for the very next statement only. Using BEGIN ... END will see the whole code block covered by the IF condition (the lines with SET and COMMIT).
Try this out:
DECLARE #SomeInt INT=0;
IF #SomeInt=1
PRINT 'Example 1: hello, this is the first line';
PRINT 'Example 1: hello, the next line';
IF #SomeInt=1
BEGIN
PRINT 'Example 2: hello, this is the first line';
PRINT 'Example 2: hello, the next line';
END
For better readability one would use indents. But this is not relevant for the engine. There are some languages using indents as block marker though, others use paranthesis or any kind of brackets. T-SQL uses BEGIN ... END. Sometimes people use this in larger procedures just to allow collapsing (like the #region in C#)
IF #SomeInt=1
PRINT 'Example 1: hello, this is the first line';
PRINT 'Example 1: hello, the next line';
IF #SomeInt=1
BEGIN
PRINT 'Example 2: hello, this is the first line';
PRINT 'Example 2: hello, the next line';
END
update
Just to reflect the comments below: The OP changed the initial question in a way, that the BEGIN ... END is no longer connected to the IF. So the question shoudl be: Why would one use BEGIN ... END without any functional reason?.
The answer for this is
To mark some lines of code as a "block"
... thus emphasising the functional unit
Collapsing is a nice side-effect
I need to break a repeat loop, whose break decision is made inside a fork-join block, but my simulator doesn't compile the code that has the following structure.
repeat (10) begin
fork
begin
// do something
end
begin
#(100ms);
break; // compile error
end
join_any
disable fork;
end
I also tried the disable command. I was able to compile, but it didn't break the loop.
repeat (10)
begin : repeat10_loop
fork
begin
// do something
end
begin
#(100ms);
disable repeat10_loop; // try
end
join_any
disable fork;
end : repeat10_loop
Is there a way to use break or disable inside fork-join?
The break and continue statements must be within the same process as the loop statement. The problem with your disable is you incorrectly labeled your loop. Try:
repeat10_loop: repeat (10)
begin
In SSMS 2012, after setting Options > Query Execution > ANSI > SET IMPLICIT_TRANSACTIONS, cf this SO post
I have the following code in a query window:
begin transaction
select ##TRANCOUNT
begin
declare #someNumber int; set #someNumber = 1;
print #someNumber;
end
rollback
When I select the whole block and press Execute, I see the expected result, i.e. 1.
However, when I select the first 4 lines and execute, then select line 5, i.e. print #someNumber;, I got the following message:
Msg 137, Level 15, State 2, Line 1
Must declare the scalar variable "#someNumber".
What is exactly the scope of the variable?
I'm baffled. Can someone shed any light or point me to the right direction please?
The variable is scoped per batch.
The scope of a local variable is the batch in which it is declared.
Each press of "Execute" is a batch. So, for the 2nd run, it isn't declared
What are doing with 2 runs is this
--start of batch 1
begin transaction
select ##TRANCOUNT
begin
declare #someNumber int; set #someNumber = 1;
--end of batch 1
GO --separate batch after this
--start of batch 2
print #someNumber;
end
rollback
--end of batch 2
In SSMS, a variable lives for the duration of the execution.
If you execute the declaration only, it dies when the execution ends.
If you then execute the print statement of the variable, it was not declared within this execution so it does not exists.
Or: What is not a T-SQL statement?
Except to resolve ambiguity, T-SQL syntax does not require a semicolon to terminate a statement. Despite this, Itzik Ben-Gan recommends using a semicolon to terminate a T-SQL statement because it makes code cleaner, more readable, easier to maintain, and more portable.
I don't know a precise definition of what a valid T-SQL statement is, so I might be confused here. But as far as I know, a BEGIN...END block is a T-SQL statement, so should be terminated by a semicolon. For example:
IF OBJECT_ID('tempdb.dbo.#TempTable') IS NOT NULL
BEGIN
DROP TABLE #TempTable;
END;
The code example in Microsoft's BEGIN...END documentation supports this conjecture:
USE AdventureWorks2008R2;
GO
BEGIN TRANSACTION;
GO
IF ##TRANCOUNT = 0
BEGIN
SELECT FirstName, MiddleName
FROM Person.Person WHERE LastName = 'Adams';
ROLLBACK TRANSACTION;
PRINT N'Rolling back the transaction two times would cause an error.';
END;
ROLLBACK TRANSACTION;
PRINT N'Rolled back the transaction.';
GO
/*
Rolled back the tranaction.
*/
Itzik Ben-Gan contradicts this in the code example of Excercise 1-1 of T-SQL Fundamentals:
SET NOCOUNT ON;
USE TSQLFundamentals2008;
IF OBJECT_ID('dbo.Nums', 'U') IS NOT NULL DROP TABLE dbo.Nums;
CREATE TABLE dbo.Nums(n INT NOT NULL PRIMARY KEY);
DECLARE #i AS INT = 1;
BEGIN TRAN
WHILE #i <= 100000
BEGIN
INSERT INTO dbo.Nums VALUES(#i);
SET #i = #i + 1;
END
COMMIT TRAN
SET NOCOUNT OFF;
Microsoft's Transact-SQL Syntax Conventions document states that the semicolon "will be required in a future version" of T-SQL.
Commenting on Microsoft's intention to require the semicolon in a future version of T-SQL, Itzik notes some exceptions that aren't supposed to be terminated:
So far it was a requirement to use a semicolon only in specific cases. Now it looks like the plan is to make it a required terminator for all* T-SQL statements in some future version of SQL Server.
(*) Naturally there are cases that aren’t supposed to be terminated with a semicolon; those include (but are not limited to):
BEGIN
BEGIN TRAN
IF
ELSE
WHILE
BEGIN TRY
END TRY
BEGIN CATCH
Itzik seems to be consistent with himself, but Microsoft itself does not follow his recommendations. Compare Microsoft's BEGIN TRANSACTION; and Itzik's BEGIN TRAN in the previous examples.
In the code I maintain, I have seen even the BEGIN keyword terminated by semicolon:
IF #HasWidget = 0x1
BEGIN;
SELECT WidgetID
FROM tbWidgets;
END;
I believe a T-SQL parser may consider the semicolon following the BEGIN keyword to terminate an empty statement rather than terminate the BEGIN keyword itself; I don't believe that BEGIN itself is a valid T-SQL statement.
This conjecture is supported by the fact that SQL Server 2008 successfully parses and executes the following query:
SELECT 0;;
It's so confusing because there is no widely available specification of the T-SQL language, like the Java Language Specification for Java, so nowhere is there a formal definition of a T-SQL statement.
Am I wrong? Does such a specification exist for T-SQL, and is it publicly available?
Otherwise, should just I believe what Itzik says?
T-SQL syntax does not require a semicolon to terminate a statement.
Actually, this is deprecated1. I can't remember for sure, but I think you can still get away with not using them in the upcoming SQL Server 2012, but some version after that will likely require a semi-colon for every statement. Using a semi-colon is also technically required by the ansi standard. The point is that now is the time to get in the habit of using one for every statement.
As a practical matter, I don't expect them to follow through with this directly. Rather, I expect SQL Server Management Studio and other development tools to first start issuing warnings instead of errors, perhaps for several versions. This will help developers find and fix all the old non-compliant code. But that doesn't lessen the message: semi-colons are coming, and soon.
For a simple heuristic on when not to use a semi-colon, think of the code as if it were a procedural language that used curly brackets for blocks, like C/C++. Statements that would be paired with an opening (not closing) curly bracket if written in the procedure language should not get a semi-colon.
1It's almost all the way at the bottom of the page
Summary, based on the OP's original, quoted list.
Yes semi-colon:
BEGIN TRAN;
No semi-colon:
BEGIN
IF
ELSE
WHILE
BEGIN TRY
END TRY
BEGIN CATCH
Also, use them after END and END CATCH.
Details:
BEGIN TRAN is a statement and should be terminated with a semi-colon.
Microsoft's documentation notes the optional semi-colon:
BEGIN { TRAN | TRANSACTION }
[ { transaction_name | #tran_name_variable }
[ WITH MARK [ 'description' ] ]
]
[ ; ]
Microsoft's example has semi-colons:
BEGIN TRAN T1;
UPDATE table1 ...;
BEGIN TRAN M2 WITH MARK;
UPDATE table2 ...;
SELECT * from table1;
COMMIT TRAN M2;
UPDATE table3 ...;
COMMIT TRAN T1;
Both of the above are from:
https://msdn.microsoft.com/en-us/library/ms188929(v=sql.90).aspx
They match the current documentation:
https://msdn.microsoft.com/en-us/library/ms188929(v=sql.120).aspx
As for BEGIN...END, the Microsoft documentation does not provide clear guidance.
The definition has no semi-colon:
BEGIN
{
sql_statement | statement_block
}
END
However, their example shows a semi-colon after END:
IF ##TRANCOUNT = 0
BEGIN
SELECT FirstName, MiddleName
FROM Person.Person WHERE LastName = 'Adams';
ROLLBACK TRANSACTION;
PRINT N'Rolling back the transaction two times would cause an error.';
END;
https://msdn.microsoft.com/en-us/library/ms190487.aspx
That trailing semi-colon is not consistent with Microsoft's own documentation for IF control of flow language construct:
IF Boolean_expression
{ sql_statement | statement_block }
[ ELSE
{ sql_statement | statement_block } ]
Neither that definition nor their code example shows any semi-colon:
DECLARE #compareprice money, #cost money
EXECUTE Production.uspGetList '%Bikes%', 700,
#compareprice OUT,
#cost OUTPUT
IF #cost <= #compareprice
BEGIN
PRINT 'These products can be purchased for less than
$'+RTRIM(CAST(#compareprice AS varchar(20)))+'.'
END
ELSE
PRINT 'The prices for all products in this category exceed
$'+ RTRIM(CAST(#compareprice AS varchar(20)))+'.'
https://msdn.microsoft.com/en-us/library/ms182717(v=sql.110).aspx
However, their ELSE documentation, while also not showing any semi-colon in the definition, does show one in the example, after the final END.
Definition:
IF Boolean_expression { sql_statement | statement_block }
[ ELSE { sql_statement | statement_block } ]
Example:
IF 1 = 1 PRINT 'Boolean_expression is true.'
ELSE PRINT 'Boolean_expression is false.' ;
https://msdn.microsoft.com/en-us/library/ms182587(v=sql.110).aspx
The ANSI standard doesn't resolve the ambiguity because these are non-standard extensions:
Control-of-flow statements are not covered by the ANSI SQL standard
because these are proprietary SQL extensions. The SQL Server Books
Online is sketchy on the subject and many of the examples (as of this
writing) are inconsistent and do not always include statement
terminators. Furthermore, control-of-flow statement blocks are
confusing due to the many variations, nesting, and optional BEGIN/END
specifications.
http://www.dbdelta.com/always-use-semicolon-statement-terminators/
However, the behavior of the server sheds some light. The following is not a syntax error in SQL Server 2005:
DECLARE #foo int;
IF #foo IS NULL
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
So the BEGIN itself does not require a semi-colon. However, the following does produce a syntax error in SQL Server 2005:
DECLARE #foo int;
IF #foo IS NULL
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
WITH Blah2 AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah2;
The above results in this error:
Msg 319, Level 15, State 1, Line 13 Incorrect syntax near the keyword
'with'. If this statement is a common table expression or an
xmlnamespaces clause, the previous statement must be terminated with a
semicolon.
It also throws that error in SQL Server 2008 R2.
It gets even more confusing. Microsoft's documentation for TRY...CATCH shows an optional semi-colon after the END CATCH, and their examples are consistent with that.
BEGIN TRY
{ sql_statement | statement_block }
END TRY
BEGIN CATCH
[ { sql_statement | statement_block } ]
END CATCH
[ ; ]
However, if you have a CTE immediately after a BEGIN TRY, without a semi-colon, it will throw an error.
BEGIN TRY
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END TRY
BEGIN CATCH
END CATCH
In SQL Server 2008 R2, the above batch throws this error:
Msg 319, Level 15, State 1, Line 2 Incorrect syntax near the keyword
'with'. If this statement is a common table expression, an
xmlnamespaces clause or a change tracking context clause, the previous
statement must be terminated with a semicolon.
The error implies that BEGIN TRY is a statement (which it isn't), and that a semi-colon "fixes" the issue (which it does). That's right, this works:
BEGIN TRY;
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END TRY
BEGIN CATCH
END CATCH
However, Microsoft says that's not good practice:
Posted by Microsoft on 12/29/2009 at 12:11 PM I am resolving the
corresonding SQL11 bug as "by design". Here is the explanation:
The semicolon between END TRY and BEGIN CATCH should not be allowed,
because they are actually not different statements, but parts of the
same TRY-CATCH statement. We only allow semicolons when they separate
two statements in a sequence.
A word of explanation why then we allow semicolons after BEGIN TRY and
BEGIN CATCH. These keywords serve as opening "parentheses" that start
an embedded statement sequence. Semicolons after BEGIN TRY/BEGIN CATCH
get parsed as part of that embedded sequence, with the first statement
in the sequence being empty. While we allow this syntax, I would not
recommend it as a good coding practice because it creates a wrong
impression of BEGIN TRY/BEGIN CATCH being independent, standalone
statements.
The recommended way to handle that situation is with an extra BEGIN...END for clarity:
BEGIN TRY
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
END TRY
BEGIN CATCH
END CATCH
However, that END before the END TRY should probably have a semi-colon. After all, this will throw an error:
BEGIN TRY
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
WITH Blah2 AS
(
SELECT
'b' AS b
)
SELECT
b
FROM Blah2;
END TRY
BEGIN CATCH
END CATCH
Maybe always preceding a CTE WITH a semi-colon isn't so silly.
The only situation in which I frequently using a semicolon is when using Common Table Expressions via the WITH keyword - and only then because the WITH keyword must be preceded by a semicolon otherwise it returns an error. In those cases, I write
;WITH [exp]...
i.e. I precede the WITH with a semicolon, rather than terminate the previous statement.
Semicolon usage in SQL seems to be very rare; I occasionally see it after a stored procedure or function declaration by that is the exception rather than the rule. Of all the developers I've worked with I don't believe any have really used the semicolon in the way that you described.
Statements like
BEGIN;
SELECT WidgetID
FROM tbWidgets;
END;
are hard to understand - if BEGIN; is considered a statement independent of its corresponding END;, why is SELECT WidgetID not a valid statement independent of its corresponding FROM?
I need to exit a SQL script without an error if a certain condition holds true. I've read that 1 solution would be to raiseerror with error code 20+ and with log parameter. But the limitation for that is that i can execute that only as an admin and the connection to the db will be aborted.
Also, I tried using GOTO and jump to the end-of-the-script, but it doesnt work, because I have multiple GO in the middle of the script. Is there a another solution?
IF <some condition>
BEGIN
GOTO Finished;
END
GO
Finished:
SELECT 'Done'
Thanks!
goto cannot jump past a go. You'd have to retest the condition in each block:
IF NOT <some condition>
BEGIN
...
END
GO
IF NOT <some condition>
BEGIN
...
END
GO
IF NOT <some condition>
...