SQL Server : Using Quotes In Linked Server Queries

Doing an OpenQuery across a linked server can get ugly very fast and it is often best to avoid them.
The basic syntax of an OpenQuery is :
SELECT * FROM OPENQUERY(YourLinkedServerName, ‘SELECT FIELD1, FIELD2 FROM YOURTABLE’)
From a coding perspective, this gets ugly if you have to incorporate string parameters; thus, utilizing many quotes.  For Example:
SELECT * FROM OPENQUERY(YourLinkedServerName, ‘SELECT FIELD1, FIELD2 FROM YOURTABLE WHERE FIELD1 = ”ID105” ‘)
Microsoft made this easier with the built-in stored procedure that allows you to avoid multi-layered quotes:  sp_executesql
The above can become:
DECLARE @PARAM char(5)
SELECT  @PARAM = ‘CA105’
EXEC YourLinkedServer.master.dbo.sp_executesql
N’SELECT FIELD1, FIELD2 FROM YOURTABLE WHERE FIELD1 = @p1′,
N’@p1 char(5)’,
@PARAM
But, what if your WHERE clause becomes:
WHERE FIELD2 in (”ID105”,”ID107”,”ID109”,”ID112”,”ID116”,
”ID119”,”ID400”,”ID404”,”ID101”,”ID102”,”ID115”,”ID106”,”ID111”,”ID117”,”ID412”,”654Z”,”ID103”,”ID121”,”ID401”,”ID403”,”ID407”,”ID108”,”ID113”,”ID114”,”ID120”,”ID123”,”ID405”,”ID409”,”ID100”,”ID110”,”ID124”,”ID408”,”ID104”,”ID118”,”ID406”,
”ID413”)
There are multiple ways to go about this but here is one cheap method for dealing with the quotes:
DECLARE @TSQL NVARCHAR(2000);
DECLARE @CODES NVARCHAR(500);
DECLARE @OPENQUERY NVARCHAR(100);
DECLARE @LINKED_SQL NVARCHAR(2700)
SET @CODES = ”’ID105”,”ID107”,”ID109”,”ID112”,”ID116”,
”ID119”,”ID400”,”ID404”,”ID101”,”ID102”,”ID115”,”ID106”,”ID111”,”ID117”,”ID412”,”654Z ”,”ID103”,”ID121”,”ID401”,”ID403”,”ID407”,”ID108”,”ID113”,”ID114”,”ID120”,”ID123”,”ID405”,”ID409”,”ID100”,”ID110”,”ID124”,”ID408”,”ID104”,”ID118”,”ID406”,
”ID413”’;
SELECT @TSQL = ‘SELECT … WHERE FIELD2 IN (‘+ @CODES + ‘)’  
— CLEAN UP THE QUOTES FOR THE OPENQUERY
—————————————————–                 
SET @TSQL = REPLACE(@TSQL, ””,”””)  ;
SET @TSQL = @TSQL + ”’)’;
SET @OPENQUERY = ‘SELECT * FROM OPENQUERY(GHDB, ”’;
SET @LINKED_SQL = (@OPENQUERY+@TSQL)
EXEC sp_executesql @LINKED_SQL

SQL Server : Using $partition Function

Recently, I needed to validate date-range value on each partition on a partitioned table.  To do this, I utilized the SQL Server "$Partition" function.  Per MSDN, "$Partition returns the partition number into which a set of partitioning column values would be mapped for any specified partition function."

 

The syntax is:

 

[ database_name. ] $PARTITION.partition_function_name(expression)

 

This handy function can also be used to obtain column information, row counts, and other information you might want to know per partition:

 

–STEP ONE:

–Get the name of your partition function:

SELECT NAME FROM SYS.partition_functions

 

NAME

TableAPartitionFunc

 

–STEP TWO:

–Get the name of the column from which your table is partitioned

SELECT c.name AS PartitionedColumnName

FROM  sys.tables t

JOIN  sys.indexes  i

ON (i.object_id = t.object_id

AND i.index_id < 2)

JOIN  sys.index_columns  ic

ON(ic.partition_ordinal > 0

AND ic.index_id = i.index_id and ic.object_id = t.object_id)

JOIN  sys.columns c

ON (c.object_id = ic.object_id

AND c.column_id = ic.column_id)

WHERE t.object_id = LOWER(object_id(‘yourtablename’))

 

PartitionedColumnName

DatePort

 

–STEP THREE:

–Use acquired data to query your partition values:

 

SELECT DISTINCT $partition.TableAPartitionFunc(DatePort) AS PartitionNumber,

CONVERT(VARCHAR(8), DatePort, 1) AS RangedDate, ‘yourtablename’ AS PartitionedTable

from yourtablename

ORDER BY $partition. TableAPartitionFunc(DatePort)

 

PartitionNumber

RangedDate

PartitionedTable

1

5/13/2013

yourtablename

2

5/14/2013

yourtablename

3

5/15/2013

yourtablename

4

5/16/2013

yourtablename

 

SQL Server : Difference Between SP_SEND_DBMAIL & XP_SENDMAIL


Recently, I decided to send email notifications via SQL Server’s XP_SENDMAIL() if a stored procedure were unable to complete its processing.  For the same stored procedure, I was ALSO rolling back the transaction in the event of failure. However, I noticed that whenever the transactions failed, then I would not get the email.

After some research, I discovered that email messages sent using XP_SENDMAIL()  would be rolled back (not sent) if the transaction is rolled back.  However, I learned that if I were to use another SQL Server method, SP_SEND_DBMAIL(), then the email would be sent regardless of the end result of the transaction.

Therefore; in sum, if you want the email message to be sent regardless of the end result of the transaction you’ll need to use SP_SEND_DBMAIL().   Also, since XS_SENDMAIL() is apparently going to be deprecated, SP_SEND_DBMAIL may be the way to go for you. 

It appears that other important differences between the two email methods are:
1.      XP_SENDMAIL requires a MAPI client installed, such as Outlook, on the server. This is the only option for SQL Server 2000 and before.
2.      SP_SEND_DBMAIL is an SMTP solution, added for SQL Server 2005 and later.

Happy coding.