Parameterized table names?

Question

Parameterized table names?

Raymond van Laake

SSCarpal Tunnel

Points: 4212
More actions
February 6, 2013 at 8:33 am

#273808

Hey,
We're going SQL2012 in a few weeks... does this version support parameterized table names? Currently we use dynamic SQL, it would be great if that wasn't necessary anymore.
For example:
DECLARE @tbl VARCHAR(MAX) = 'EMPLOYEES'
SELECT * FROM @tbl
Looked it up on google, but saw no mention this is possible in 2012, so I thought lets ask here...
Thx, Raymond

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 1

Nope.

To be honest, that's something I strongly recommend against. It's a pain, it's a security hole if you're not incredibly careful and it suggests bad design (you wouldn't write a C# class that could operate on any type of object or struct passed in, why do it in SQL?)

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Raymond van Laake SSCarpal Tunnel Points: 4212 More actions · Answer 2

Hi,

Thanks for your reply, was afraid this would be the outcome.

The reason I need it is: my users can create a "campaign", and based on what's needed within that specific campaign a table is created. So at any time suddenly a new table can be present that is named dbo.Campaign00001, dbo.Campaign00002 etc.

All through a user-interface, they cannot access SQL directly.

e4d4 SSCertifiable Points: 5777 More actions · Answer 3

If tables have the same structure use a partitioned view, or bind and unbind table to view, or in SQL 2012 use synonym, all depend on your needs.

demonfox SSCertifiable Points: 6289 More actions · Answer 4

Raymond van Laake (2/7/2013)
Hi,
Thanks for your reply, was afraid this would be the outcome.
The reason I need it is: my users can create a "campaign", and based on what's needed within that specific campaign a table is created. So at any time suddenly a new table can be present that is named dbo.Campaign00001, dbo.Campaign00002 etc.
All through a user-interface, they cannot access SQL directly.

if the database is still in design phase , may be you can getaway with Entity Attribute model ;

having the user create the table , I don't think that kind of stuff I would prefer.

~ demonfox
___________________________________________________________________
Wondering what I would do next , when I am done with this one :ermm: