Re: Query SQL using variables.
- From: "Mr. Arnold" <MR. Arnold@xxxxxxxxxx>
- Date: Wed, 2 Jan 2008 05:25:11 -0500
"Tom Shelton" <tom_shelton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:eWvLkiQTIHA.3940@xxxxxxxxxxxxxxxxxxxxxxx
On 2008-01-02, Mr. Arnold <MR> wrote:
"Tom Shelton" <tom_shelton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uVZbrPQTIHA.3916@xxxxxxxxxxxxxxxxxxxxxxx
On 2008-01-02, Stephany Young <noone@localhost> wrote:While I, personally, would not use concatenation unless there was no
practical alternative and/or it was in a 'safe' environment, let's put
things in perspective and moderate your warning say that there could be a
security risk.
The significance of that risk depends on a number of factors that all
have
to 'come together' simultaneously to allow a 'SQL injection attack'.
As for the other issues, (quoting, dates/times, formatting, etc.), they
are
bread and butter issues and don't cause concatenation to be 'bad'.
Let's start off 2008 by encouraging people to use good practices rather
than
kicking them in the teeth for using a practice that some MIGHT consider
to
be 'bad'.
That's exactly what I was doing. I was warning him of the potential
risks of using concatenation to form his query strings. I don't believe
my warning was of a dire or overly sentationalist nature. It is a bad
practice - even in "safe" environments.
I don't consider it to be a bad practice. I have used them both over the
years Dynamic SQL statements and Stored Procedures. And for the OP to learn
the basics, I see nothing wrong with his approach. For simple pulling of
data from a database table, I don't see the harm.
There maybe no harm in his particular case. But, why do you want to
teach someone a method that can be a potential security risk in another
context - especially without telling them so? To me it is the same as
warning people to use Option Strict On. It's not strictly necessary,
but it is a bad practice - except in rare circumstances. The OP could
just have easily used a parameterized query in this case (you don't have
to make a stored proc to take advantage of parameters). And not only
would he gain the advantage of not having to worry about proper quoting
and sql injection attacks - but might have gotten a little speed boost
if this query is executed multiple times - since sqlserver caches the
execution paths of parameterized queries, just as it does stored procs.
I am not teaching him anything. I gave him a solution to his problem. If this blew his mind, then I wouldn't be going too much beyond that at this time.
.
- References:
- Query SQL using variables.
- From: R . Rafii
- Re: Query SQL using variables.
- From: Mr. Arnold
- Re: Query SQL using variables.
- From: R . Rafii
- Re: Query SQL using variables.
- From: Tom Shelton
- Re: Query SQL using variables.
- From: Stephany Young
- Re: Query SQL using variables.
- From: Tom Shelton
- Re: Query SQL using variables.
- From: Mr. Arnold
- Re: Query SQL using variables.
- From: Tom Shelton
- Query SQL using variables.
- Prev by Date: Re: Query SQL using variables.
- Next by Date: Re: What is wrong with this mutex code
- Previous by thread: Re: Query SQL using variables.
- Next by thread: Re: Query SQL using variables.
- Index(es):