April 3, 2017 at 9:18 am
Hi All,
I am passing table name as a variable in my stored prcoedure. Below is the stored procedure
Create procedure dbo.sp_Test
(
@tableName varchar(100),
@facilityID varchar(100)
)
AS
DEclare @SQL nvarchar(max)
SET @SQL = ' INSERT INTO [' + @tableName + ']' +
'(
facilityId)
Values
(
@facilityID )';
print @SQL;
exec sp_executesql @SQL
When I execute the stored procedure, I keep getting an error saying
INSERT INTO [tbltest1](
facilityId)
Values
(
@facilityID )
Msg 137, Level 15, State 2, Line 6
Must declare the scalar variable "@facilityID".
I think it is not recognizing the facilityID that I am passing as a parameter. Do I need to re declare all the parameters that I am passing in the stored procedure. I am passing at least 50 parameters.
April 3, 2017 at 9:25 am
You've got a PRINT @SQL line in your code: please will you post what it prints?
Also, please read about SQL injection, because you're wide open to it, and you could find yourself being bitten very hard.
John
April 3, 2017 at 9:28 am
You're not escaping your Dynamic SQL when you get to your variable. Thus the SQL you're executing is expecting a variable @facilityID,. which you haven't declared.
Try replacing the relevant part with:
SET @SQL = ' INSERT INTO [' + @tableName + ']' +
'(facilityId) VALUES (' + @facilityID + ');';
Although, as John said, consider injection here.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
April 3, 2017 at 9:30 am
anjaliagarwal5 - Monday, April 3, 2017 9:18 AMHi All,
I am passing table name as a variable in my stored prcoedure. Below is the stored procedureCreate procedure dbo.sp_Test
(@tableName varchar(100),
@facilityID varchar(100))
AS
DEclare @SQL nvarchar(max)
SET @SQL = ' INSERT INTO [' + @tableName + ']' +
'(
facilityId)Values
(
@facilityID )';print @SQL;
exec sp_executesql @SQL
When I execute the stored procedure, I keep getting an error saying
INSERT INTO [tbltest1](
facilityId)Values
(
@facilityID )
Msg 137, Level 15, State 2, Line 6
Must declare the scalar variable "@facilityID".I think it is not recognizing the facilityID that I am passing as a parameter. Do I need to re declare all the parameters that I am passing in the stored procedure. I am passing at least 50 parameters.
Inside your procedure, you're calling another procedure (sp_executesql). That procedure needs to get all the parameters needed.
You should also prevent sql injection by validating that your table name is a valid table. This is the way I do it.DECLARE @tableName sysname;
DECLARE @SQL nvarchar(max)
SELECT @SQL = ' INSERT INTO ' + QUOTENAME(name) +
'(
facilityId)
Values
(
@facilityID )'
FROM sys.tables
WHERE name = @tableName;
April 3, 2017 at 9:40 am
Thom A - Monday, April 3, 2017 9:28 AMYou're not escaping your Dynamic SQL when you get to your variable. Thus the SQL you're executing is expecting a variable @facilityID,. which you haven't declared.Try replacing the relevant part with:
SET @SQL = ' INSERT INTO [' + @tableName + ']' +
'(facilityId) VALUES (' + @facilityID + ');';Although, as John said, consider injection here.
Is there any workaround for this without writing a dynamic query? I have to pass the table name as a variable.
April 3, 2017 at 9:46 am
anjaliagarwal5 - Monday, April 3, 2017 9:40 AMIs there any workaround for this without writing a dynamic query? I have to pass the table name as a variable.
Not really. The fact that you're needing to do this at all suggest to me that your database may be poorly designed - perhaps not normalised. It wouldn't surprise me to see lots of table names with numbers in, something like Facilities001, Facilities002 and so on. Am I right?
John
April 3, 2017 at 9:47 am
anjaliagarwal5 - Monday, April 3, 2017 9:40 AMThom A - Monday, April 3, 2017 9:28 AMYou're not escaping your Dynamic SQL when you get to your variable. Thus the SQL you're executing is expecting a variable @facilityID,. which you haven't declared.Try replacing the relevant part with:
SET @SQL = ' INSERT INTO [' + @tableName + ']' +
'(facilityId) VALUES (' + @facilityID + ');';Although, as John said, consider injection here.
Is there any workaround for this without writing a dynamic query? I have to pass the table name as a variable.
No, but there's an option to prevent SQL Injection when using the method I posted and the complete set of parameters for sp_executesql.
April 3, 2017 at 9:47 am
John Mitchell-245523 - Monday, April 3, 2017 9:46 AManjaliagarwal5 - Monday, April 3, 2017 9:40 AMIs there any workaround for this without writing a dynamic query? I have to pass the table name as a variable.
Not really. The fact that you're needing to do this at all suggest to me that your database may be poorly designed - perhaps not normalised. It wouldn't surprise me to see lots of table names with numbers in, something like Facilities001, Facilities002 and so on. Am I right?
John
yes, you are. I hate to write this dynamic query.
April 3, 2017 at 9:59 am
anjaliagarwal5 - Monday, April 3, 2017 9:47 AMJohn Mitchell-245523 - Monday, April 3, 2017 9:46 AManjaliagarwal5 - Monday, April 3, 2017 9:40 AMIs there any workaround for this without writing a dynamic query? I have to pass the table name as a variable.
Not really. The fact that you're needing to do this at all suggest to me that your database may be poorly designed - perhaps not normalised. It wouldn't surprise me to see lots of table names with numbers in, something like Facilities001, Facilities002 and so on. Am I right?
John
yes, you are. I hate to write this dynamic query.
You really don't have much choice, if you have a database design like that and your table could be dynamic, then you SQL will need to be as well.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
April 3, 2017 at 10:03 am
Just realize that Dynamic SQL is a tool. There are times it is needed and appropriate and other times when it isn't. Learning how to write good Dynamic SQL is a good thing, even if you use it sparingly.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply