Not sure how you are doing this for now but (if you are using parametized
queries) basically parameters are not a macro substitution thing i.e. a
parameter value can't be used in a SQL Statement to provide the table name
(if can replace "values" not a table name or the name of the fields in the
SELECT clause etc...).
Not sure what is your logic but :
- I would likely hide this with a stored procedure
- You could also dynamically create the FROM clause.
- you can isnert data into the tabvle variable using an INSERT statement
Another option would be to go back earlier in the design. Isn't this table
part of the union ? If yes you could just always use the union with the
appropriate criteria. What is the concept difference between this table and
the union ?
Bascially the idea would be that this issue is not to be solved at the
SQLDataSource level. It would be IMO better to hide this behind what is
exposed by SQL Server....
--
Patrice
"Andrea Raimondi" <ra****@plug-in.ita écrit dans le message de groupe de
discussion :
Os**************@TK2MSFTNGP03.phx.gbl...
Hello peers!
I'm working on this application and I'm in need for some thoughtful advice
:-p
I have an SQLDataSource with params, select, etc.
One of my params is the table name, which can be programmatically set,
this is necessary because I may have a
simple table name or a union, hence I got to pick the correct one!
Unfortunately, I can't bind this parameter to a control, session or
whatever, my table names are embedded in my
source code as a constant array of strings.
Googling around I found out that SQLServer is being mislead by the
parameter position - I just want a table NAME there, not a
table variable!
Is there any way I can tell to the SQLDataSource that I need a table NAME
parameter? :D
Alternatively, how can I populate such a table variable so that it
contains the correct table contents?
Any hints?
TIA,
Andrew
