Essayer de déterminer quelle serait l'approche la plus efficace d'utiliser une sous-requête dans une déclaration de SQL en ligne. Inline SQL n'est pas quelque chose que j'ai beaucoup d'expérience avec, mais je n'ai d'autre choix à mon organisation hélas.
if (BatchNotate.Count() > 0)
{
query += " AND BatchNotate= @BatchNotate";
}
cmd.Parameters.AddWithValue("@BatchNotate", batchNotate);
3 Réponses :
Pourriez-vous faire quelque chose comme ça?
Cela n'a pas de sens pour moi le coalesce (@batchnotate, null) n'a aucune fonctionnalité.
J'ai édité ma réponse. Est-ce que ça fait plus de sens? Il est très possible que je ne comprends pas correctement la question.
Oui @isaac qui corrige le bogue, je ne suis pas sûr que ce soit la fonctionnalité que l'OP veut, mais au moins cela a du sens.
Utilisez ceci: si la variable (@invariable) est NULL, il sera "par défaut à b. si c'est autre chose, il va comparer contre cela.
aucun de ceux qui travaillaient pour ce que je suis après. Voici ce que j'ai fini par faire. C'est un peu haçonneux, mais ça marche. Utilisation: P> if (batchNotate.Count() > 0)
{
query += " AND ({@BatchNotate})";
}
string batchNotateParamNames = SqlHelper.AddParametersOR(cmd.Parameters, "BatchNotate", "@B0", SqlDbType.VarChar, 1, batchNotate);
cmd.CommandText = query.Replace("{@BatchNotate}", batchNotateParamNames);
Cette solution est mûr pour une attaque d'injection SQL
S'il vous plaît expliquer plus loin pourquoi ??? Addparameters limite le paramètre Varcharne (1) - une attaque va donc avoir lieu avec 1 caractère?
bien sûr - s'il est appelé avec le nom de champ défini sur 1 = 1); DROP Table DBO.VW_RMISPAYMENT; - et élément défini sur NULL ou NOTNULL
Je peux voir que cependant de nom de terrain est défini de manière programmatique et non accessible à l'utilisateur final.
Je questionne que - de nombreuses attaques d'injection sont effectuées en modifiant les fichiers de configuration et tels que. Vous ne devriez pas prendre de variables et l'introduire dans une requête
Le potentiel d'attaque d'injection n'est pas la même chose qu'une attaque d'injection. Selon le contexte, une attaque d'injection est très réelle. Je vais aller avec un peu de bon sens et bouger avec ma solution. À peu près sûr, je peux éviter de configurer une variable dans un fichier de configuration ou d'un autre scénario impartial. Merci pour les commentaires.
Ou vous pouvez utiliser les meilleures pratiques et résoudre le problème de la façon dont j'ai suggéré d'utiliser une requête paramétrée.
Vous voudrez peut-être étudier sur paramètres de valorisation de table Ici . Ensuite, vous pourriez utiliser quelque chose comme
... où ... et (existe (Sélectionnez 42 à partir de @batchnotations sous forme de bn où bn.batchnotate = vw_rmispayment.batchnotate) ou vw_rmispayment.batch_notate est null) ... Où@batchnotations est un paramètre valorisé de la table avec une ligne pour chaque valeur que vous souhaitez traiter.