Don’t know what’s with you guys, but when I first bumped into subqueries I could have understood their importance and efficiency, but for some reason, it wasn’t as intuitive for me as I hoped to. That means, I already know joins, right? And if, as claimed, subquries are only another way of writing it, and the SQL’s optimizer uses joins in any way, why bother?

Well, because it’s worthy and well, because it’s much more simple than it might look when dealing with it for the first time.

How simple are subqueries, or better said – how simple is understanding them? Let’s see:

First, a subquery is basically a query inside a query. That’s all there is to it. It might also become handy to understand that it’s basically, as mentioned before, another way of writing joins.

Now, let’s divide subqueries into 3 types in order to understand which type is to be used where:

Let’s think of a result set of a query, any result set, as the purpose of the inner query of ours (inner query, needless to say, is the one who’s inside the brackets, as opposed to the outer query who’s, well, you get the picture, ain’t ya?) : One type is a table – a data set with columns and rows. Other type is a data set that contains only one column and couple of rows, and the third type is a case when we get only one column and only one row.

Now, let’s call the first type “Derived Table”, the second type “List” and the third type “Scalar value”. Now and in general, derived tables will be placed after the “FROM” part of the outer query, lists will be placed after the “IN” part of the “WHERE” part of the outer query and scalar value will be put wherever we can use an expression in the outer query.

Examples? Why not?

Scalar values subqueries:

– Retrieve the orders with total amount greater than the average total amount

SELECT

       Id ,

       CustomerId ,

       TotalAmount ,

       DateAndTime

FROM

       Sales.Orders

WHERE

       TotalAmount >

              (

                     SELECT

                           AVG (TotalAmount)

                     FROM

                           Sales.Orders

              )

ORDER BY

       TotalAmount ASC;

GO

– Retrieve the English customers along with the number of orders

– and the number of support calls of each customer

SELECT

       CustomerId                 = Customers.Id ,

       CustomerName               = Customers.FirstName + N' ' + Customers.LastName ,

       NumberOfOrders             =

              (

                     SELECT

                           COUNT (*)

                     FROM

                           Sales.Orders AS Orders

                     WHERE

                           Orders.CustomerId = Customers.Id

              ) ,

       NumberOfSupportCalls =

              (

                     SELECT

                           COUNT (*)

                     FROM

                           Support.Calls AS Calls

                     WHERE

                           Calls.CustomerId = Customers.Id

              )

FROM

       Marketing.Customers AS Customers

WHERE

       Customers.CountryId = 7    – England

ORDER BY

       CustomerId ASC;

GO

SELECT
Id,
FirstName,
LastName,
(SELECT Name FROM Lists.Countries WHERE Id = Operation.Members.CountryId)
FROM
Operation.Members;
GO

Notice the difference between the first 2 examples and the third one: The last depends on a parameter from the outer query while the first two stand on their own. That’s the difference between a correlated subquery (the last one) and non-correlated one (first two).

List subquery:

SELECT p.Name

FROM Production.Product p WHERE ProductSubcategoryID IN

(SELECT ProductSubcategoryID FROM Production.ProductSubcategory WHERE

Name = 'Wheels')

Derived Table subquery (as another way of writing a join query, for example):

The join way:

SELECT p.Name

FROM Production.Product p

INNER JOIN Production.ProductSubcategory psc

ON p.ProductSubcategoryID = psc.ProductSubcategoryID

WHERE psc.Name = 'Wheels'

And the subquery way:

SELECT p.Name

FROM Production.Product p

INNER JOIN (SELECT * FROM Production.ProductSubcategory

WHERE Name = 'Wheels') psc

ON p.ProductSubcategoryID = psc.ProductSubcategoryID

A derived table can also be correlated, but in that case we will need to use a CROSS/OUTER APPLY. Lets take a look at an example:

– Retrieve all the customers along with the last 3 orders of each customer

SELECT

       CustomerId                 = Customers.Id ,

       CustomerName               = Customers.FirstName + N' ' + Customers.LastName ,

       OrderId                    = LastThreeOrders.Id ,

       OrderAmount                = LastThreeOrders.TotalAmount ,

       OrderDateTime              = LastThreeOrders.DateAndTime

FROM

       Marketing.Customers AS Customers

OUTER APPLY

       (

              SELECT TOP (3)

                     Orders.Id ,

                     Orders.TotalAmount ,

                     Orders.DateAndTime

              FROM

                     Sales.Orders AS Orders

              WHERE

                     Orders.CustomerId = Customers.Id

              ORDER BY

                     Orders.DateAndTime DESC

       )

       AS

              LastThreeOrders

ORDER BY

       CustomerId    ASC ,

       OrderDateTime DESC;

GO

Some things to remember about subqueries, and you are free to start working with them (Of course, it’s only the basics of it, but hey, as long as you understand the way of using it and where to use it, the rest is simply a select query in which you can do whatever you already know about select queries):

Derived tables:

· Can return any number of rows.

· Can return any number of columns.

· Must follow rules for being relational:

o Set must have a name (alias. Write “AS <query_name> outside of it).

o All columns must have unique names (aliases).

o Rows and columns have no order. Order (by) is done at the outer query anyway.

Scalar value subquery:

· Must return only 1 row and only 1 column.

· Does not require column or set alias.

· Can be correlated.

List subquey:

· Must return only 1 column

· Can return any number of rows

· Does not require column or set alias

· Can be correlated.

Let’s finish this post by saying, that subqueries can also be used for an EXIST check. In most cases, it is a very efficient way for such a check.

You might want to remember that:

· Subquery can and should be correlated.

· It does not return any output.

· Number of rows and columns is irrelevant, because SQL Server only checks for the existence of rows and doesn’t really need to retrieve any data, so specifying a long list of columns or a single constant in the column set is identical in this case. Here is an example:

– Retrieve the customers who have at least one order in the last 3 days

SELECT

       Customers.Id ,

       Customers.FirstName ,

       Customers.LastName

FROM

       Marketing.Customers AS Customers

WHERE

       EXISTS

              (

                     SELECT

                           NULL

                     FROM

                           Sales.Orders AS Orders

                     WHERE

                           Orders.CustomerId = Customers.Id

                     AND

                           Orders.DateAndTime > DATEADD (DAY , -3 , SYSDATETIME ())

              )

ORDER BY

       Customers.Id ASC;

GO

Spatial data is defined as data that is represented by 2D or 3D images. 2D images are supported in SQL Server 2008 and 3D images may be added in future releases.

SQLCLR UDT (SQL Common Language Runtime User Defined Types) defines Spatial Data as “technology for hosting of the Microsoft .NET common language runtime engine (such as C# or VB.NET) within SQL Server”.

Spatial data is subdivided into geometric data (Euclidian geometry, aka “Flat Earth”) and geographic data (locations and boundaries on the earth, aka “Round Earth”).

Geography

To explain the uses of Geography Spatial Data Type, let’s think of someone’s address. This someone might be a customer of ours, for that example.

Let’s think of this someone’s address as a point of longitude and latitude, which sets the exact location of him on Earth. Knowing where a customer lives as latitude/longitude allows you to answer questions such as:

1. What is the closest company branch for him?

2. Which salesperson lives closest to him?

3. How many customers live more than 2 Kilometers from your nearest branch location?

Etc.

Defining the Geography Spatial Data Type will lead us to these points:

· Geodetic, Ellipsoidal (round-earth) data, such as GPS latitude and longitude coordinates.

· Different Types of Projections.

· Enables sharing information with other people who might be using a different projection.

· Uses Latitude and Longitude angles to identify points on the Earth. Latitude measures how far North (or South) of the Equator a point is, while Longitude measures how far East (or West) of a Prime Meridian a point is.

· SQL Server 2008's Spatial data types are based on the OGC's "Simple Feature Access" standards.Open Geospatial Consortium, Inc. (OGC) is described as "a non-profit, international, voluntary consensus standards organization that is leading the development of standards for geospatial and location based services".

· It is important to know which Spatial Reference System is used, so accuracy will not be defected.

· Commonly Used Reference System Today: Global Positioning System (GPS) Data – WGS84.

Geometry

The Geometry spatial data type is used to represent information in a uniform 2-dimensional plane (like graph paper). Units are user-defined.

Geometry data type will be used in conjunction with some existing planar projection of the real world that becomes the underlying reference. For example, coordinate space is being used to represent a warehouse facility. You can define polygons that represent storage bays within the warehouse etc. You can then determine where the closest item to each and every bay is.

Defining the Geography Spatial Data Type will lead us to these points:

· Uses Cartesian coordinate system.

· Used to represent information in a uniform 2-dimensional plane

· Units are completely user-defined, and could be inches, miles, pixels etc. Actually, SQL Server doesn't care – It can perform calculations just the same.

· Present Storage Bays in Warehouses, Linkages between areas etc.

Now, after understanding what Spatial Data is and what Geometry and Geography Data Types are, let’s examine the Specific Types of Spatial Data:

POINT:

· An exact location.

· Defined in terms of an X and Y pair of coordinates (Z (elevation) and M (measure) are optional too).

· Does not have a length or any area associated with it.

· Used as the fundamental building blocks of more complex spatial types.

LINESTRING:

· Defined as the path between a sequence of points

· Considered simple if it does not cross over itself, and is considered a ring if the starting point is the same as the ending point.

· A LineString is always considered to be a one dimensional object; it has length, but does not have area (even if it is a ring).

POLYGON:

· A closed two-dimensional shape defined by a ring.

· Has both length and area.

· May also have holes in its interior.

COLLECTIONS:

· Type that can hold a collection of instances. This is similar to a list or an array in most programming languages.

· The most generic type of collection is the GeomCollection, whose members can be of any type. Deriving from GeomCollection are MultiPolygon, MultiLineString, and MultiPoint.

· As their names suggest, the members of these collection types must be of the single instance type (MultiPoint can only contain Points etc.).

Representing Spatial Data

• The OGC defines different ways to represent geospatial information as bytes of data that can then be interpreted by the Geometry or Geography types.

• SQL Server 2008 supports three such formats: Well-Known Text (WKT), Well-Known Binary (WKB), and Geography Markup Language (GML).

• WKT is commonly used since it is both concise and [relatively] human-readable.

• POINT(10 10) / POINT(10 10 10 1) // X Y Z M.

• LINESTRING(0 0, 10 10).

• POLYGON((0 0, 0 10, 10 10, 10 0, 0 0)).

• POLYGON WITH TRIANGLE IN IT: ((0 0, 0 10, 10 10, 10 0, 0 0), (1 1, 4 5, 4 1, 1 1)).

Instantiating the UDT

• Any variable, parameter, or table column can be declared as type Geometry or Geography:

DECLARE @g Geometry

DECLARE @h Geography

• Use the STGeomFromText() static method to parse data provided in valid WKT syntax:

DECLARE @g Geometry

SET @g = Geometry::STGeomFromText('LINESTRING(0 0, 10 10, 21 2)',0)

• In SQL syntax, CLR method names are case sensitive!

DECLARE @g Geometry

SET @g = Geometry::STLineFromText('LINESTRING(0 0, 10 10, 21 2)')

Working with a UDT Instance

DECLARE @g GEOMETRY

SET @g = 'LINESTRING ( 69 26, 69 23, 69 21, 67 20, 65 20,

63 18, 58 17, 52 17, 51 17, 49 17, 45 18, 44 20,

44 21, 42 26, 42 29, 42 32, 42 35, 43 35, 47 38,

50 41, 55 42, 58 42, 65 44, 66 44, 67 44, 68 45,

69 47, 70 48, 70 50, 71 51, 70 56, 68 60, 68 63,

66 65, 65 66, 63 68, 60 71, 59 71, 57 71, 55 71,

51 69, 45 65, 44 63, 42 62, 41 59, 41 57, 41 56,

41 54, 42 53 )'

STEnvelope:

A rectangle that is defined by the combination of minimum and maximum X and Y values found in a given Geometry instance. The OGC standard method STEnvelope() returns the bounding box (a Polygon) for the instance on which it is invoked. All points of the original instance lie within the new Polygon.

STConvexHull:

If something is convex, then it is thought of as having a surface that is curved or rounded outward from the center. For example, the side of an apple is convex.

Reduce(tolerance):

A method that will simplify a given instance using the Douglas-Peucker algorithm.

The result is a an approximation of the original instance containing a fewer number of points. The accuracy of the new shape improves as the provided tolerance value approaches zero, but more points are necessary to provide that accuracy.

Instances to interact with one another

DECLARE @g geometry

= 'POLYGON((10 10, 40 10, 40 40, 10 40, 10 10))'

DECLARE @h geometry

= 'POLYGON((30 30, 50 30, 50 50, 30 50, 30 30))'

STDifference():

Returns a new instance consisting of all points from the base instance that do not contain points from the parameter instance.

STIntersection():

Returns a new instance containing only the points that are in common between the base instance and the parameter instance.

STUnion():

Returns a new instance containing all of the points of the base instance and the parameter instance merged together.

Working With Geography

• The Open Geospatial Consortium's Simple Features specification, which SQL Server 2008's Geometry data type is based upon, defines standards for working with spatial data using a flat-earth (projected planar) model.

• It defines how to work with paper maps of the world, but not globes.

• SQL Server team recognized that and implemented a second data type just for representing geospatial data using a true ellipsoidal model: Geography.

• Longitude is the horizontal angle (how far East or West from a Prime Meridian) and ranges from -180 degrees to 180 degrees (with -180 and 180 being the same). Latitude is the vertical angle (how far North or South from the Equator) and ranges from -90 degrees to 90 degrees (with -90 representing the South Pole and 90 representing the North Pole).

Imagine a situation (and if you already faced that problem, you don’t even need to imagine) in which your tempdb database (data and log files) needs to be relocated from its current location to a new one as part of a planned relocation or due to data files gone large. Current location, usually the default one, might just not be enough sometimes.

So is there a way to change the location of tempdb database files?

Well, just imagine how short and irrelevant this post would have been if the answer to this question was “Nope, there isn’t”, but since there is, and quite a simple one as a matter of fact, let’s see how it’s done (based on BOL):

1. Determine the logical file names of the tempdb database and their current location on the disk.

SELECT name, physical_name AS CurrentLocation

FROM sys.master_files

WHERE database_id = DB_ID(N'tempdb');

GO

(

Or use sp_helpfile:

USE tempdb

GO

sp_helpfile

GO

)

2. Change the location of the files:

USE master;

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = 'E:\SQLData\tempdb.mdf');

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = templog, FILENAME = 'F:\SQLLog\templog.ldf');

GO

You will get this message:

The file "tempdev" has been modified in the system catalog. The

new path will be used the next time the database is started.

The file "templog" has been modified in the system catalog. The

new path will be used the next time the database is started.

3. Stop and restart the instance of SQL Server.

4. Verify the file change.

SELECT name, physical_name AS CurrentLocation, state_desc

FROM sys.master_files

WHERE database_id = DB_ID(N'tempdb');

(

Or use sp_helpfile:

USE tempdb

GO

sp_helpfile

GO

)

5. Delete the tempdb.mdf and templog.ldf files from the original location (See section 1).

It’s known that tempdb database is deleted and recreated every time we restart the SQL Server service (when the instance of SQL Server is started), so we don’t need to physically move the data and log files, but only change file configuration in the database. The files are then created in the new location and until then uses data and log files in the existing location.

Important: If you are moving databases to a new drive/volume or another server (different drive letter), change the SQL Server Agent log path as well. If not, SQL Agent will fail to start. If the Database Default Locations path is not modified, creating a database may fail.

To change the SQL Agent log path:

1. In SQL Server Management Studio expand SQL Server Agent.

2. Right-click on Errorlogs.

3. Click on Configure.

4. Change the Error Log File path to the new desired location.

To change the Database Default Locations path:

1. In SQL Server Management Studio right-click on the SQL Server name.

2. Choose Properties.

3. Choose Database Settings.

4. Under "Database Default Locations" modify the Data and Log paths to the new, desired location.

Reading this posts title might make us smile: Me helping the optimizer? Isn’t it the one who supposes to help me?

Well, yes and no. The optimizer might help me getting the best execution pal for my queries (as long as I keep performing the right maintenance issues), but is some cases I can hint it to perform even better, and the way to do it is by re-scripting, re-quering and using nothing but some basic TSQL.

As always, an example shown might be worth a thousand words, and my purpose is to make my point with less than a half.

Lets take a look at a script of a procedure which job is to receive data of workers entering and exiting a factory and in addition to inserting it into a table, presenting it on screen for boarder guards:

SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER OFF
GO

CREATE PROCEDURE [dbo].[sp_TLA_Monitor]

—————————
@pUserNo      int      ,
@pSort        smallint ,
@pDoor        int      ,
@pFilterP     smallint = 0 ,
@pFilterV     smallint = 0
—————————

AS
DECLARE @ActLinkString varchar(8000)
SET nocount on

SET @ActLinkString = "

IF @pFilterP > 0 AND @pFilterP < 4
BEGIN
SET @ActLinkString =
'DECLARE @NUMERATOR int '+
'SET @NUMERATOR = ( SELECT MIN( MA.Numerator ) '+
' FROM TLA_OpenEvents MA  '+

CASE WHEN ( @pFilterP = 1 ) THEN 'WHERE DATEDIFF( day   ,  EventTime , GETDATE() ) < 1 ) '
WHEN ( @pFilterP = 2 ) THEN 'WHERE DATEDIFF( Hour  ,  EventTime , GETDATE() ) < '+CAST( @pFilterV  AS VARCHAR) +' ) '
WHEN ( @pFilterP = 3 ) THEN 'WHERE DATEDIFF( day   ,  EventTime , GETDATE() ) < '+CAST( @pFilterV  AS VARCHAR) +' ) '
ELSE ' ' END
END

SET @ActLinkString = @ActLinkString +
'SELECT C.Descript Controller , DE.Descript Device , '+
'cObjCode =  CASE WHEN ISNULL( DO.Code , 0 ) <> 0 THEN DO.Code ELSE CASE WHEN ( MA.Type >= 810 AND MA.Type <= 817 )  THEN MA.ControllerPhisicalID  ELSE MA.Device END END , '+
'cObjType =  CASE WHEN ISNULL( DO.Code , 0 ) <> 0 THEN 1100    ELSE CASE WHEN ( MA.Type >= 810 AND MA.Type <= 817 )  THEN 1200 ELSE 1300 END  END , DO.Descript Door , '+

'MA.Badge Card , W.No WCNo, W.Name WC , DP.No DepNo, DP.Name Dep ,'+
'OE.EventTime , ED.Descript Type ,'+
'OE.FirstOperator ,'+
'FirstOperatorDescr = (SELECT Emp_Name From Emp Where Emp_no = OE.FirstOperator ),'+
'OE.FirstTreatEventTime , '+
'OE.LastOperator  ,'+
'LastOperatorDescr  = (SELECT Emp_Name From Emp Where Emp_no = OE.LastOperator  ),'+
'OE.EndTime , '+
'OE.Numerator , OE.Code , ED.Color , '+
'OE.Severity , OE.Sensitivty ,OE.Priority , OE.Status , '+
'UserType = ISNULL( vwObj.ObjType , 0 ) , '+
'CarNo    = vwObj.ObjCarNo , '+
'EmpNo    = vwObj.ObjNo    ,  Emp_Name = vwObj.ObjName , '+
'xFunction = ( SELECT Descript FROM dvc_def WHERE code = MA.FunctionCode ) , '+
'Pic =  vwObj.ObjPic '+

'FROM TLA_Mov_Access MA '+
'left join vw_ObjectType   vwObj  on vwObj.ObjCode  =  MA.Emp_no AND MA.Tag_Type = vwObj.ObjType '+
'left join Work_c          W      on W.No           =  vwObj.ObjStation '+
'left join Dep             DP     on DP.No          =  vwObj.ObjDep '+
'join TLA_OpenEvents       OE     on OE.Numerator   =  MA.Numerator '+
'left join TLA_Devices     DE     on DE.Code        =  MA.Device '+
'join TLA_EventsDef        ED     on ED.Code        =  MA.Event '+
'left join TLA_Doors       DO     on DO.Code        =  DE.Door '+
'left join TLA_Controllers C      on C.Code         =  MA.ControllerPhisicalID '+
' join dbo.fnc_GetMapPerm('+CAST( @pUserNo AS VARCHAR )+', 12 )  GMP on GMP.Control = ISNULL(DO.Code,-1) '+ –210609

CASE WHEN ( @pFilterP = 0 ) THEN 'WHERE 1 = 1 '
WHEN ( @pFilterP = 1 ) THEN 'WHERE MA.Numerator > @NUMERATOR  '
WHEN ( @pFilterP = 2 ) THEN 'WHERE MA.Numerator > @NUMERATOR  '
WHEN ( @pFilterP = 3 ) THEN 'WHERE MA.Numerator > @NUMERATOR  '
WHEN ( @pFilterP = 4 ) THEN 'WHERE MA.Numerator > (SELECT MAX(Numerator) – '+CAST( @pFilterV  AS VARCHAR)+' FROM TLA_Mov_Access) ' ELSE 'WHERE 1 = 1' END +

CASE WHEN ( @pDoor >= 0 ) THEN ' AND DO.Code = '+CAST( @pDoor AS VARCHAR) ELSE ' ' END +

CASE @pSort
WHEN  0 THEN  ' ORDER BY OE.Numerator DESC '
WHEN  1 THEN  ' ORDER BY OE.Priority DESC '
WHEN  2 THEN  ' ORDER BY OE.Severity DESC '
WHEN  3 THEN  ' ORDER BY OE.Sensitivty DESC ' END

EXEC @ActLinkString

GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

As you can see, the procedure creates a string to be executed.

We noticed that recently query time of running this procedure is much longer than it used to be – a growth of hundreds of percents. Checking all maintenance issues (indexes, fragmentations etc.) didn’t help the query to run faster like it used to.

Then we ran the Execution Plan of the query and got this:

A kind of a complex one, as a query that uses lots of LEFT JOINs should look like.

Funny thing about it that when we looked at the details we saw in more than one place a huge difference between the estimated and the actual number of rows and between the estimated and the actual number of executions.

Checked again if statistics are updated. Well, they were.

So what is it? What makes the optimizer get the wrong impression? We assumed that if the estimated numbers were closer, much closer in fact, to the actual numbers, optimizer could have probably chosen a second way, different one and perhaps much better one, to execute the query.

Answer is simple: The more complex a query is, the more stages it goes along the way and the more JOINs, mostly of course LEFT JOINs it uses, makes the algorithm become much less accurate. Take for an example a 10% of a standard deviation of the optimizer in estimation at each level. and you got yourself one irrelevant Execution Plan.

So what’s the solution for this problem, you may ask.

A good thing to do would be trying to rescript the query in a way that the optimizer will go step-by-step and perform less complex simultaneous processes.

This query might work better if instead of using one SELECT Statement will all these JOINs, we will try to use temporary tables and devide the SELECT vertically instead of horizontally. In that way, optimizer will use much less JOINs per INSERT INTO and Execution Plan might be devided to more levels, but much more simple in each level.

It should be looking something like this:

SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER OFF
GO

CREATE PROCEDURE [dbo].[sp_TLA_Monitor_Test]

—————————
@pUserNo      int      ,
@pSort        smallint ,
@pDoor        int      ,
@pFilterP     smallint = 0 ,
@pFilterV     smallint = 0
—————————

/*
DOOR       = 1100;
CONTROLLER = 1200;
DEVICE     = 1300;
BUILDING   = 2000;
IMAGE      = 3000;
BUZZER     = 4000;
*/

AS
DECLARE @ActLinkString varchar(8000)
SET nocount on

SET @ActLinkString = "

IF @pFilterP > 0 AND @pFilterP < 4
BEGIN
SET @ActLinkString =
'DECLARE @NUMERATOR int '+
'SET @NUMERATOR = ( SELECT MIN( MA.Numerator ) '+
' FROM TLA_OpenEvents MA  '+

CASE WHEN ( @pFilterP = 1 ) THEN 'WHERE DATEDIFF( day   ,  EventTime , GETDATE() ) < 1 ) '
WHEN ( @pFilterP = 2 ) THEN 'WHERE DATEDIFF( Hour  ,  EventTime , GETDATE() ) < '+CAST( @pFilterV  AS VARCHAR) +' ) '
WHEN ( @pFilterP = 3 ) THEN 'WHERE DATEDIFF( day   ,  EventTime , GETDATE() ) < '+CAST( @pFilterV  AS VARCHAR) +' ) '
ELSE ' ' END
END

SET @ActLinkString = @ActLinkString +
'SELECT '+
'MA.Badge Card, '+
'MA.Tag_Type, '+
'MA.Emp_no, '+
'MA.Numerator Num1, '+
'MA.Event, '+
'MA.Device Dev1, '+
'MA.ControllerPhisicalID, '+
'MA.FunctionCode, '+
'MA.Type Type1, '+
'C.Descript Controller '+
'INTO '+
'#Tmp1 '+
'FROM '+
'TLA_Mov_Access MA '+
'LEFT JOIN TLA_Controllers C on MA.ControllerPhisicalID=C.Code '+

'SELECT '+
'T.Card, T.Tag_Type, T.Emp_no, T.Num1, T.Event, T.Dev1, T.Controller, T.ControllerPhisicalID, T.FunctionCode, T.Type1, '+
'T.UserType, T.CarNo, T.EmpNo, T.Emp_Name, T.Pic, T.ObjStation, T.ObjDep, '+
'OE.EventTime, '+
'OE.FirstOperator,'+
'FirstOperatorDescr = (SELECT Emp_Name From Emp Where T.Emp_no = OE.FirstOperator), '+
'OE.FirstTreatEventTime, '+
'OE.LastOperator, '+
'LastOperatorDescr = (SELECT Emp_Name From Emp Where T.Emp_no = OE.LastOperator), '+
'OE.EndTime, '+
'OE.Numerator, '+
'OE.Code, '+
'OE.Severity, '+
'OE.Sensitivty, '+
'OE.Priority, '+
'OE.Status, '+
'ED.Descript Type, '+
'ED.Color '+
'INTO '+
'#Tmp3 '+
'FROM '+
'#Tmp2 T '+
'JOIN TLA_OpenEvents OE on OE.Numerator=T.Num1 '+
'JOIN TLA_EventsDef ED on ED.Code=T.Event '+

CASE WHEN ( @pFilterP = 0 ) THEN 'WHERE 1 = 1 '
WHEN ( @pFilterP = 1 ) THEN 'WHERE T.Numerator > @NUMERATOR  '
WHEN ( @pFilterP = 2 ) THEN 'WHERE T.Numerator > @NUMERATOR  '
WHEN ( @pFilterP = 3 ) THEN 'WHERE T.Numerator > @NUMERATOR  '
WHEN ( @pFilterP = 4 ) THEN 'WHERE T.Numerator > (SELECT MAX(Numerator) – '+CAST( @pFilterV  AS VARCHAR)+' FROM TLA_Mov_Access) ' ELSE 'WHERE 1 = 1' END +

CASE WHEN ( @pDoor >= 0 ) THEN ' AND T.Code = '+CAST( @pDoor AS VARCHAR) ELSE ' ' END +

CASE @pSort
WHEN  0 THEN  ' ORDER BY T.Numerator DESC '
WHEN  1 THEN  ' ORDER BY T.Priority DESC '
WHEN  2 THEN  ' ORDER BY T.Severity DESC '
WHEN  3 THEN  ' ORDER BY T.Sensitivty DESC ' END

EXECUTE(@ActLinkString)

GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

And the Execution Plan of it will look something like this:

Try it. You will be surprised to find out how many times it helps queries to be executed much faster. Where it looks like there’s no hope, this solution just might be the one!