Skip to main content

Able to use sp_executesql without declaring variables!

From Denis blog I came to know recently that we are able to use sp_executesql without declaring the variables!

It really sounded strange to me. I thought it to be one another bug :)

So thought would dig deep into this and see what best I can conclude.

--Dummy table schema
Create table tblQuestion1
(
sno int identity,
fname varchar(50)
)
Go

--Lets add some dummy records into the table
Insert into tblQuestion1 values ('Alpha')
Insert into tblQuestion1 values ('Beta')
Insert into tblQuestion1 values ('Gamma')

--So-called strange script
Declare @strFetchData nvarchar(100)
Select @strFetchData = 'Select * from tblQuestion1'
Exec sp_executesql @alpha = @strFetchData

If you have noticed we haven't declared @alpha in the script but SQL hasn't complained about it!

I thought the easiest way to understand would be to go through sp_executesql procedure.

Sp_helptext sp_executesql
go

Result - "(server internal)" … so its not a stored proc.

I tried adding another dummy parameter!

Declare @strFetchData nvarchar(100)
Select @strFetchData = 'Select * from sys.sysobjects'
Exec sp_executesql @alpha = @strFetchData, @beta = N''

Just the @ alone is also taken without a variable name:

Declare @strFetchData nvarchar(100)
Select @strFetchData = 'Select * from sys.sysobjects'
Exec sp_executesql @ = @strFetchData, @beta = N''

The code still works.

I tried adding the third parameter! hurray it fails.

Declare @strFetchData nvarchar(100)
Select @strFetchData = 'Select * from sys.sysobjects'
Exec sp_executesql @alpha = @strFetchData, @beta = N'', @gamma = N''

So I guess during compilation SQL engine is ignoring undeclared variables for the first 2 parameters but not from the third parameter onwards.

That said, syntax of sp_executesql on a higher level is:

1. First parameter - SQL Stmt
2. Second parameter - Parameter Definition
3. Third parameter and going fwd -- Value for the parameters are assigned here. (Parameter mapping)

So once parameter mapping comes into play it fails. The first two parameters is being taken as a dummy placeholders!!!

Few more examples:

--This works
Declare @IntVariable int;
Declare @SQLString nvarchar(500);
Declare @ParmDefinition nvarchar(500);

Set @SQLString =
N'Select EmployeeID, NationalIDNumber, Title, ManagerID
From AdventureWorks.HumanResources.Employee
Where ManagerID = @ManagerID';
Set @ParmDefinition = N'@ManagerID tinyint';

Set @IntVariable = 197;
Exec sp_executesql @SQLString, @ParmDefinition,
@ManagerID = @IntVariable;

--This would fail
Declare @IntVariable int;
Declare @SQLString nvarchar(500);
Declare @ParmDefinition nvarchar(500);

Set @SQLString =
N'Select EmployeeID, NationalIDNumber, Title, ManagerID
From AdventureWorks.HumanResources.Employee
Where ManagerID = @ManagerID';
Set @ParmDefinition = N'@ManagerID tinyint';

Set @IntVariable = 197;
Exec sp_executesql @alpha = @SQLString, @ParmDefinition,
@ManagerID = @IntVariable;

Comments

Popular posts from this blog

Registry manipulation from SQL

Registry Manupulation from SQL Server is pretty easy. There are 4 extended stored procedure in SQL Server 2000 for the purpose of manupulating the server registry. They are: 1) xp_regwrite 2) xp_regread 3) xp_regdeletekey 4) xp_regdeletevalue Let us see each one of them in detail! About xp_regwrite This extended stored procedure helps us to create data item in the (server’s) registry and we could also create a new key. Usage: We must specify the root key with the @rootkey parameter and an individual key with the @key parameter. Please note that if the key doesn’t exist (without any warnnig) it would be created in the registry. The @value_name parameter designates the data item and the @type the type of the data item. Valid data item types include REG_SZ and REG_DWORD . The last parameter is the @value parameter, which assigns a value to the data item. Let us now see an example which would add a new key called " TestKey ", and a new data item under it called TestKeyValue :

Screen scraping using XmlHttp and Vbscript ...

I wrote a small program for screen scraping any sites using XmlHttp object and VBScript. I know I haven't done any rocket science :) still I thought of sharing the code with you all. XmlHttp -- E x tensible M arkup L anguage H ypertext T ransfer P rotocol An advantage is that - the XmlHttp object queries the server and retrieve the latest information without reloading the page. Source code: < html > < head > < script language ="vbscript"> Dim objXmlHttp Set objXmlHttp = CreateObject("Msxml2.XMLHttp") Function ScreenScrapping() URL == "UR site URL comes here" objXmlHttp.Open "POST", url, False objXmlHttp.onreadystatechange = getref("HandleStateChange") objXmlHttp.Send End Function Function HandleStateChange() If (ObjXmlHttp.readyState = 4) Then msgbox "Screenscrapping completed .." divShowContent.innerHtml = objXmlHttp.responseText End If End Function </ script > < head > < body > &l

Script table as - ALTER TO is greyed out - SQL SERVER

One of my office colleague recently asked me why we are not able to generate ALTER Table script from SSMS. If we right click on the table and choose "Script Table As"  ALTER To option would be disabled or Greyed out. Is it a bug? No it isn't a bug. ALTER To is there to be used for generating modified script of Stored Procedure, Functions, Views, Triggers etc., and NOT for Tables. For generating ALTER Table script there is an work around. Right click on the table, choose "Modify" and enter into the design mode. Make what ever changes you want to make and WITHOUT saving it right click anywhere on the top half of the window (above Column properties) and choose "Generate Change Script". Please be advised that SQL Server would drop actually create a new table with modifications, move the data from the old table into it and then drop the old table. Sounds simple but assume you have a very large table for which you want to do this! Then it woul