Archive
SQL Logical Query Processing Order
–>Logical Query-processing step numbers:
(5) SELECT (5-2) DISTINCT (7) TOP(<top_specification>) (5-1) <select_list> (1) FROM (1-J) <left_table> <join_type> JOIN <right_table> ON <on_predicate> | (1-A) <left_table> <apply_type> APPLY <right_input_table> AS <alias> | (1-P) <left_table> PIVOT(<pivot_specification>) AS <alias> | (1-U) <left_table> UNPIVOT(<unpivot_specification>) AS <alias> (2) WHERE <where_predicate> (3) GROUP BY <group_by_specification> (4) HAVING <having_predicate> (6) ORDER BY <order_by_list> (7) OFFSET <offset_specs> ROWS FETCH NEXT <fetch_specs> ROWS ONLY;
–> Logical step sequence of a Query:
1. FROM / JOIN/ APPLY/ PIVOT/ UNPIVOT
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT list/ DISTINCT
6. ORDER BY
7. TOP/ OFFSET-FETCH
–> Flow diagram representing logical query-processing:
SQL Server CURSOR and it’s Life Cycle
A CURSOR in SQL is a database object that contains a set of records that you can traverse one-by-one, rather than the SET as a whole.
SQL is a set-based language and produces a complete result set, and the SQL queries works on this complete set only, and not on individual rows. But there are times when the results are best processed one row at a time. Opening a cursor on a result set allows processing the result set one row at a time. You can assign a cursor to a variable or parameter with a cursor data type.
CURSOR in SQL language gives you the flexibility to traverse records like the way you do in other programming languages with iterators and for-loop.
–> A simple Cursor life cycle with minimum definition:
USE [AdventureWorks]
GO
-- Returns -3
SELECT CURSOR_STATUS('global','myCursor') AS 'Before Declare'
DECLARE myCursor CURSOR
FOR SELECT ContactID, FirstName, LastName FROM Person.Contact WHERE ContactID BETWEEN 100 and 102
-- Returns -1
SELECT CURSOR_STATUS('global','myCursor') AS 'After Declare'
DECLARE @ContactID INT, @FirstName VARCHAR(50), @LastName VARCHAR(50)
OPEN myCursor
-- Returns 1
SELECT CURSOR_STATUS('global','myCursor') AS 'Open Cusrsor'
FETCH NEXT FROM myCursor INTO @ContactID, @FirstName, @LastName
WHILE @@fetch_status=0
BEGIN
-- SQL Statements with logic inside
SELECT @ContactID, @FirstName, @LastName
FETCH NEXT FROM myCursor INTO @ContactID, @FirstName, @LastName
END
-- Returns 1
SELECT CURSOR_STATUS('global','myCursor') AS 'While loop exited, all rows iterated'
CLOSE myCursor
-- Returns -1
SELECT CURSOR_STATUS('global','myCursor') AS 'Cursor is Closed'
DEALLOCATE myCursor
-- Returns -3
SELECT CURSOR_STATUS('global','myCursor') AS 'Cursor Deallocated'
Physical Join vs Logical Join in SQL Server
Most of us know about JOINS in SQL Server and their types. But do we really know how they are interpreted in SQL Server internally. Today I found lot of informative, interesting and important sources regarding Logical and Physical joins in SQL Server (links below).
–> Classifying JOINS mainly into 2 types:
1. Logical Joins: These joins are simple joins that we apply in our SQL queries, like INNER JOIN, RIGHT/LEFT OUTER JOIN, CROSS JOIN, OUTER APPLY, etc.
2. Physical Joins: These are the joins that users don’t use/write in their SQL queries. Instead these are implemented inside SQL Server engine as operators or algorithms to implement the Logical Joins. Their types are Nested Loop, Merge and Hash.
For a particular SQL query when you try to view an Estimated Execution Plan or execute a query by selecting Actual Execution Plan, you can clearly see these Physical Joins under the Execution Plan tab in SSMS.
Reference for Logical Joins from one of my old posts: https://sqlwithmanoj.wordpress.com/2009/03/12/sql-server-joins-and-types
–> Logical Joins:
– Inner/Outer/Cross: https://blogs.msdn.microsoft.com/craigfr/2006/07/19/introduction-to-joins/
–> Physical Joins:
– Nested Loop Joins: https://blogs.msdn.microsoft.com/craigfr/2006/07/26/nested-loops-join/
– Merge Joins: https://blogs.msdn.microsoft.com/craigfr/2006/08/03/merge-join/
– Hash Joins: https://blogs.msdn.microsoft.com/craigfr/2006/08/10/hash-join/
Defensive Database Programming with SQL Server… a must have (e)book
Book By Alex Kuznetsov… and a must read for all T-SQL techies.
The goal of Defensive Programming is to produce resilient code that responds gracefully to the unexpected.
To the SQL Server programmer, this means T-SQL code that behaves consistently and predictably in cases of unexpected usage, doesn’t break under concurrent loads, and survives predictable changes to database schemas and settings.
Inside this book, you will find dozens of practical, defensive programming techniques that will improve the quality of your T-SQL code and increase its resilience and robustness.
Download the e-book from here: http://www.red-gate.com/specials/Ebooks/Defensive_Database_Programming.pdf
Related article: http://www.simple-talk.com/sql/t-sql-programming/book-review-defensive-database-programming-with-sql-server/
Stopping a DELETE statement in middle of its execution – MSDN TSQL forum
–> Question:
I accidentally executed the DELETE statement for a table.
However, I stopped it before it completed.
What effect will this have on the table in Database, is my data safe?
–> My Answer:
In SQL Server by default a single SQL statement is bounded within a Transaction.
So, if you cancelled the DELETE statement execution in between it would have cancelled the overall deletion from the table. So either all of your rows are safe or all gone. SQL Server ensures that a transaction should be completed fully or not at all, one of the ACID properties.





