September 25, 2009 at 12:03 pm
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?
September 25, 2009 at 12:11 pm
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.
April 9, 2012 at 8:55 am
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
April 9, 2012 at 9:08 am
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?
April 9, 2012 at 9:17 am
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.
April 10, 2012 at 1:21 pm
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 17, 2012 at 3:53 am
...
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...)
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply