变量名“ @”已被声明

Question

Part of our solution is a page that displays company-specific information using an ASP Gridview . Our method of constructing the SQL that feeds the Gridview is by using C# to build a custom SELECT statement based on a series of user inputs.

Once the user applies their filters through a button click , C# loops through all of their selections ( check boxes and text boxes ) and then propagates those selections to a separate method which constructs a WHERE clause to append to a simple SELECT statement. We use a Table-Valued Function in the FROM statement , and the only input parameter is from the Querystring and this does not change throughout the process.

Once the query has been assembled using C#, we apply this query to the SqlDataSource as the Select Command . However, we have recently discovered a very bizarre SQL error that we haven't seen before:

Errors :

"The variable name '@' has already been declared .

Variable names must be unique within a query batch or stored procedure. "

We aren't declaring any variables in our SQL. As stated above, the only input parameter comes from the Querystring , and we access this parameter using both QueryStringParameters in the ASP:SqlDataSource on the ASP side and “ int.Parse(Request.QueryString["id"]).ToString() ” on the C# side while constructing the SQL query.

After researching this error, I have yet to find an instance where the variable declaration is empty. Most people are getting errors similar to this when they have declared a variable such as '@email' or '@address' twice. We have no double declarations, and the fact that the variable in the error is not defined is causing a massive headache.

Has anyone seen anything like this before or have any suggestions on how to further debug?

I'll post some code if need be, but we are mostly interested to see if anyone has seen an error like this before.

Code :

string MainQueryStr = ResultsPages.SearchString(SearchVariables(), Request,
                ProjectsSqlds, 0, "SELECT DISTINCT dbo.{0}.* FROM dbo.{0}(" + int.Parse(Request.QueryString["id"]).ToString() + ")", 
                "getXyzById", "AbcId");
        StringBuilder SearchQueryStr = new StringBuilder();
        SearchQueryStr.Append(MainQueryStr);
        SearchQueryStr.Append(" ORDER BY AbcName");
        ProjectsSqlds.SelectCommand = SearchQueryStr.ToString();

The search string function is a 500 line method that we can't post right now. It is used all over our solution and works as it should. It stitches together strings to create the query.

This is how the SearchString function appends the parameters:

 l.Add(ResultsPages.NewSearchQueryString(ABCFiltersTxBx, SearchQueryStringVariableType.String,
            "{1}.AbcID IN (" + ABCFiltersTxBx.Text + ")"));

Where the ABCFiltersTxBx is parsed into a comma separated string.

Answer 1

I should chime in as the supervisor in question here:

OK, so we figured out what was happening.

What we didn't realize was that the SQLDataSource was taking our appended WHERE clauses and using them as SelectParameters. Each parameter we wanted to add to the query that would ultimately feed the SQLDS was then being added as a SelectParameter without us realizing it, and because we hadn't made any explicit parameter declarations, the parameters were added with just "" as the name, leading to the error of "'@' has already been declared".

The most embarrassing part of this whole thing is that our API has already accounted for Parameter Names, but we had unwittingly excluded this part. Thank you all very much for reading and attempting to help. We thoroughly appreciate you taking your time to help us brainstorm our solution over here.

So I suppose the take-home of this whole error is in 2 parts:

1. Know your API. When you realize that you screwed it up on your own, graciously thank those that took the time to help you here on StackOverflow (or wherever you seek help), as their time is valuable as well.

2. "'@' is already declared" would indicate that you have parameters being declared without a name, so when debugging, look through the SQLDS you are using and find any parameters that haven't been explicitly named.

Again, thank you to all who read and offered to help. It's greatly appreciated.