Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 2005 » T-SQL (SS2K5) » "Variable" for switching Table Names
Add to briefcase

"Variable" for switching Table Names Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
battery_acid_h
Posted Friday, September 25, 2009 12:03 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, May 01, 2013 2:30 PM
Points: 48, Visits: 130
I have a MS NAV database where company data for each company has separate tables in a single database.

These tables are named in the following way:

[Cronus Canada$GL Entry] (for Cronus Canada)
[Cronus USA$GL Entry] (for Cronus USA)

There is a separate table listing the companies in the database.

The user would like to be able to switch between companies when running the reports, but this means querying two different tables and currently two different reports, each with identical SQL script.

Is it possible to switch between these two companies' tables by using a variable or similar? How can this be achieved?
Post #793996
kramaswamy
Posted Friday, September 25, 2009 12:11 PM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Yesterday @ 1:53 PM
Points: 785, Visits: 1,534
There's two options for you.

One way is you have a stored procedure that will take the table name, and will have a series of IF-ELSE statements, each of which simply invokes a stored procedure that handles that particular table.

The other way is to use dynamic SQL. You can use the sp_executeSQL command. See this page for more details: http://msdn.microsoft.com/en-us/library/ms188001.aspx.

Basically you'd do something like this:

CREATE PROCEDURE sp_DynamicSQL
(
@TableName VARCHAR(MAX)
)
AS
BEGIN
DECLARE @Statement VARCHAR(MAX)
SET @Statement = 'SELECT * FROM ' + @TableName ' WHERE 1 = 1 '

EXEC sp_executeSQL @Statement
END

More details on the exact functionality can be found on that page.
Post #794000
ssssqlguy
Posted Monday, April 09, 2012 8:55 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 10, 2012 1:23 PM
Points: 3, Visits: 8
You can do what karamaswamy above mentioned; or you can also create an indexed view against these tables (assuming their schema is the same). This way, your queries can hit the view instead of switching between the tables during runtime execution.

Note that using Dynamic SQL is an expensive SQL operation. You may have to try out these options (dynamic sql, if..else, indexed view) and see which one works best for you.

Cheers
Post #1280181
Lynn Pettis
Posted Monday, April 09, 2012 9:08 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 3:18 AM
Points: 21,588, Visits: 27,375
ssssqlguy (4/9/2012)
You can do what karamaswamy above mentioned; or you can also create an indexed view against these tables (assuming their schema is the same). This way, your queries can hit the view instead of switching between the tables during runtime execution.

Note that using Dynamic SQL is an expensive SQL operation. You may have to try out these options (dynamic sql, if..else, indexed view) and see which one works best for you.

Cheers


I'm assuming in the definition of the view you would add the actual table name the data is coming from so that could be used as part of the filter condition in the where clause, correct?


Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1280188
ssssqlguy
Posted Monday, April 09, 2012 9:17 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 10, 2012 1:23 PM
Points: 3, Visits: 8
Yep. You could absolutely filter by the table-name contained within the View's defnition; or, if you know the customer name - use that. With the later approach way you're negating the dependency on coding against a 'table name' per se.
Post #1280196
Eric M Russell
Posted Tuesday, April 10, 2012 1:21 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 5:03 AM
Points: 1,162, Visits: 3,328
ssssqlguy (4/9/2012)
You can do what karamaswamy above mentioned; or you can also create an indexed view against these tables (assuming their schema is the same). This way, your queries can hit the view instead of switching between the tables during runtime execution.

Note that using Dynamic SQL is an expensive SQL operation. You may have to try out these options (dynamic sql, if..else, indexed view) and see which one works best for you.

Cheers

Perhaps you meant to say Partitioned View, one which unionizes all of the tables of like schema. This could possibly an indexed as well, but I think we're really talking about a partitioned view.

"Wise people understand the 10,000 things without going to each one.
They know them without having to look at each one,
and they transform all without acting on each one." - The Tao Te Ching: Verse 47
Post #1281101
Eugene Elutin
Posted Tuesday, April 17, 2012 3:53 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 10:59 AM
Points: 2,525, Visits: 4,324

...
Note that using Dynamic SQL is an expensive SQL operation.
...


What do you mean by "expensive"? It's as affordable as anything else.
Just use it properly with sp_executesql and parameters to stop possible sql injection.
I think, in this case, using dynamic SQL is totally justified and will allow to achieve the best performance (for sure it will be better than using IF statements...)

_____________________________________________
"The only true wisdom is in knowing you know nothing"
"O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!"
(So many miracle inventions provided by MS to us...)

How to post your question to get the best and quick help
Post #1284777
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.