|
Try this:
idTextBox.Text = "Jones;DROP TABLE Table";
string sql = "Select * from Table where name = " + idTextBox.Text; Or better still, don't try it - just think about it. Can the user type that into idTextBox? Oh yes! And what happens to your database? 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
I have a confession to make, sometimes I open your profile just to see the picture 
|
|
|
|
|
I'm not sure whether to be flattered that you like it, or disturbed that you felt a need to say it! 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
That's exactly the effect I was looking for
|
|
|
|
|
Glad to have been of assistance then!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
0) I haven't written a stored procedure since I started using ADO.net. Before that, with ODBC, I had to write stored procedures in order to have transactions -- that was the only reason we used stored procedures.
1) Stored procedures are not inherently faster than SQL in code.[^]
2) Stored procedures offer some benefits, but I doubt most people capitalize on them (I wouldn't).
3) If you use stored procedures, you still need to have SQL (EXEC statements basically) in code anyway.
4) Most people write stored procedures simply because someone else said they should, not because they know what they're doing.
5) A properly-developed Data Access Layer may remove any need for stored procedures. If there is a need, then stored procedures may be used by the DAL and such details will be hidden from the user.
6) Stored procedures are fragile.
6.1) I have had stored procedures "just disappear" (that was with SQL Server 6, I doubt the problem still exists, but it makes me nervous).
6.2) Stored procedures are too easy to change in the field. All code changes should be in source control, properly built, and deployed to the field in a controlled manner. SQL in code accomplishes that.
As mentioned, you absolutely must use parameterized statements. I think one reason people insist on stored procedures is because they force the developer to use parameters. But inline SQL can (and should) use parameters and a well-disciplined developer will have no trouble doing so. I have written several families of classes that make data access with parameters a no-brainer. Here[^]'s one.
|
|
|
|
|
Stored procedures can help reduce network traffic, as the EXEC statements are typically shorter than the statements in the SP's. Naturally, this depends on if network traffic is an issue at all (e.g., if the SQL runs on the same machine as the C#, it wouldn't be an issue... it also wouldn't be an issue of the data being transferred dwarfs the SQL code size).
DLL's are just as fragile as stored procedures. At my previous job, we had to work with a system that had hundreds of DLL's and OCX's. The systems constantly got out of sync. SP's have one advantage in this respect... you fix them in one location (the database) and they are fixed everywhere. That's kinda nice (at least for systems where there is a primary database server). The other advantage/disadvantage is that you can see the stored procedure code, while it is difficult to see DLL code (without, say, Reflector). That means that you can easily check if the wrong code is in use, but it also means its more tempting for others to modify it on the spot without bothering with version control.
PIEBALDconsult wrote: I have had stored procedures "just disappear"
SP's should be kept under version control. Sadly, the tools to do this are not excellent. Though, I remember a tool from Redgate under development that is supposed to help with this.
PIEBALDconsult wrote: Stored procedures are too easy to change in the field.
Shhh, don't tell this to Microsoft... they might think making things "too easy" is a bad idea. 
Depending on the scenario, this may actually be a good thing. Rather than trying to deploy the code to each computer that uses it, you can simply update the SP's on the server and you're done. This also brings up security concerns. It can be difficult or impossible to control security if you allow the clients to run arbitrary SQL statements. If you have stored procedures, you can control exactly what executes on the server. This is a very important point, as it may be the single greatest advantage stored procedures have over plain SQL code.
PIEBALDconsult wrote: one reason people insist on stored procedures is because they force the developer to use parameters
string firstName = "'; DROP TABLE Whatever; --";
string cmd = "EXEC SelectData '" + firstName + "'";
Both stored procedures and plain SQL are susceptible to SQL injection.
|
|
|
|
|
aspdotnetdev wrote: Stored procedures can help reduce network traffic
Yes, but mine never go across a network so that argument has no weight for me.
aspdotnetdev wrote: you fix them in one location (the database) and they are fixed everywhere
Not if you have many clients each with his own database. And you should be putting the code in a version control system, that makes at least two places.
aspdotnetdev wrote: It can be difficult or impossible to control security if you allow the clients to run arbitrary SQL statements.
That's what a DAL is for.
aspdotnetdev wrote: If you have stored procedures, you can control exactly what executes on the server.
You can. But do you? It's much easier with compiled code.
aspdotnetdev wrote: Both stored procedures and plain SQL are susceptible to SQL injection.
Huh, OK.
|
|
|
|
|
Always Stored Procedure because
it will provide protection from SQL injection attacks,
it enable conditional and procedural logic,
it provide better management of Compilation and storing or Execution plan
it enable of security model and
stored procedure code is a lot more readable
modified on Wednesday, October 27, 2010 2:35 AM
|
|
|
|
|
|
use store procedures in database because if you have any problem, you only needs change the proc to resolve
|
|
|
|
|
ok, now i can see that this is possible;
class Animals: IEnumerable<Animals> {};
forget about the IEnumerable, im just trying to show some generic type of itself... im just bothered... where can we make use of this (a generic type of itself) in the real world?
|
|
|
|
|
|
Yep, even our animals are smart enough to enumerate themselves.
|
|
|
|
|
hahah... good one, but that didnt help...
think fast, be brave and dont stop.
|
|
|
|
|
I'll have to think about it. Gimme 7.5 million years...
|
|
|
|
|
Thank god, Apple didn't fall on you
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKQUFK[M`UKs*$GwU#QDXBER@CBN%
R0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -----------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
What a beautiful answer: Totally useless, sarcastic and technically correct in all respects at the same time.
I want to 5 you, but I know I shouldn't .
|
|
|
|
|
One i can think is a tree or a graph, where each node is defined as the collection of all its children.
|
|
|
|
|
yeah, i thought of the same with nodes... but the thing is, on an engineering standpoint we already have better implimentations of a node... wont a collection as a node just bloat everything?  newez, was just hoping for something 'unique' that it can solve with... or maybe im just crossing the line where it says 'bad design on generics' here... 
|
|
|
|
|
what im really fussing about is that this can be more than just on collections... its generic interfaces, objects, and what nots on itself... u know... 
think fast, be brave and dont stop.
|
|
|
|
|
Does class A : IComparable<A> { } count?
|
|
|
|
|
rights... now i feel stupid... hehehe... got my 5 here... thanks...
think fast, be brave and dont stop.
|
|
|
|
|
How about a factory
public class GenericFactory<T> where T : new()
{
public T Create(){
return new T();
}
}
|
|
|
|
|
no, the guy up there got it... i wanted to see the declared type (itself) being passed back into the generic... (with some sense into it)
think fast, be brave and dont stop.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
