A valid point. My basic thinking... remember I'm a newbie... was that
this procedure would be used is several parts of the ASP app but the
different parts would require different fields of information. I'm
still designing the app so not sure on how useful this type of
procedure will be. But maybe I should rethink the below proc and
design several procs ie. LoginUser, UserExists, GetUserAddress,
GetUserAccountStatus - Would this be the more logic way of doing it
then? ( all the above 4 procs would be searched on username)
At the moment I'm the only developer on the project. So I know that I
won't "Drop Database", but the asp hacker might.
Thanks for pointing this out... It all helps when designing the site
and the best way to do things.
On Tue, 30 Jul 2002 16:01:13 +0100, "Tony Rogerson"
>Sort of defeats the point of using a stored procedure, unless you are
>writing a dynamic front end that is.
>You should really write a stored procedure per operation you want to do...
>CREATE PROCEDURE usp_FindUserName
> set nocount on
> select UserID, UserName
> from ...
> where ....
>You are also opening yourself up to somebody implanting sql, if the front
>end had access to the db or the ASP got hacked, what would stop this...
>That would implant the DROP DATABASE in your SQL and run it (assuming the
>user running had the access rights).