2013-04-11 5 views
0

Une partie de notre solution est une page qui affiche des informations spécifiques à l'entreprise à l'aide d'un code ASP Gridview. Notre méthode de construction du SQL qui alimente le Gridview consiste à utiliser C# pour créer une instruction personnalisée SELECT basée sur une série d'entrées utilisateur.Le nom de variable '@' a déjà été déclaré

Une fois que l'utilisateur applique les filtres à travers une button click, C# boucles à travers toutes leurs sélections (check boxes and text boxes), puis à ces sélections se propage une méthode distincte qui construit une clause WHERE pour ajouter à une simple déclaration SELECT. Nous utilisons un Table-Valued Function in the FROM statement, et le seul paramètre d'entrée est le Querystring et cela ne change pas tout au long du processus. Une fois la requête assemblée en utilisant C#, nous appliquons cette requête au SqlDataSource sous la forme Select Command. Cependant, nous avons récemment découvert une erreur SQL très bizarre que nous avons jamais vu auparavant:

Erreurs:

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

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

Nous ne déclarons pas toutes les variables dans notre SQL. Comme indiqué plus haut, le seul paramètre d'entrée provient de la Querystring, et nous avons accès à ce paramètre à l'aide à la fois QueryStringParameters dans le ASP:SqlDataSource du côté ASP et "int.Parse(Request.QueryString["id"]).ToString()" du côté C# lors de la construction de la requête SQL

Après avoir recherché cette erreur, je n'ai pas encore trouvé d'instance où la déclaration de variable est vide La plupart des gens obtiennent des erreurs similaires quand ils ont déclaré une variable tels que '@email' or '@address' deux fois.Nous avons pas de double déclaration ations, et le fait que la variable dans l'erreur n'est pas définie provoque un mal de tête massif.

Est-ce que quelqu'un a déjà vu quelque chose comme ça ou avez-vous des suggestions sur la façon de déboguer davantage?

Je posterai du code si besoin est, mais nous sommes surtout intéressés à voir si quelqu'un a déjà vu une erreur comme celle-ci.

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(); 

La fonction de chaîne de recherche est une méthode 500 ligne que nous ne pouvons pas publier en ce moment. Il est utilisé partout dans notre solution et fonctionne comme il se doit. Il enchaîne les chaînes pour créer la requête.

Voici comment la fonction SearchString les paramètres ajoute:

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

Lorsque le ABCFiltersTxBx est analysé dans une chaîne séparées par des virgules.

+0

Avez-vous regardé le SQL généré des requêtes qui causent des erreurs? Je commencerais là, et chercher partout où un '@' est utilisé. Je suppose que la cause de l'erreur deviendra plutôt évidente. – Servy

+0

Oui, nous avons regardé le SQL lorsque cette page se charge et rien ne casse, et après la clause Where est ajouté et rien ne casse là non plus. – user2271111

+0

Alors, quand est-ce que ça casse? À quoi ressemble le SQL à ce moment? – Servy

Répondre

1

je devrais sonner en tant que superviseur en question ici:

OK, donc nous avons compris ce qui se passait.

Ce que nous n'avions pas réalisé était que la SQLDataSource prenait nos clauses WHERE et les utilisait comme SelectParameters.Chaque paramètre que nous voulions ajouter à la requête qui alimenterait le SQLDS était ensuite ajouté en tant que SelectParameter sans que nous le réalisions, et comme nous n'avions pas fait de déclarations de paramètres explicites, les paramètres ont été ajoutés avec juste "" comme nom , conduisant à l'erreur de "@" a déjà été déclaré ". La partie la plus embarrassante de tout cela est que notre API a déjà pris en compte les noms de paramètres, mais nous avons inconsciemment exclu cette partie. Merci à tous pour votre lecture et votre aide. Nous apprécions grandement que vous preniez votre temps pour nous aider à réfléchir sur notre solution ici.

Donc je suppose que l'emporter de cette erreur tout est en 2 parties:

  1. Apprenez à connaître votre API. Quand vous réalisez que vous avez tout gâché par vous-même, remerciez gracieusement ceux qui ont pris le temps de vous aider ici sur StackOverflow (ou partout où vous cherchez de l'aide), car leur temps est précieux aussi. "'@' Est déjà déclaré" indiquerait que vous avez déclaré des paramètres sans nom, alors lors du débogage, regardez le SQLDS que vous utilisez et trouvez les paramètres qui n'ont pas été explicitement nommés.

Encore une fois, merci à tous ceux qui ont lu et offert d'aider. C'est grandement apprécié.

Questions connexes