I'm not sure what you're trying to achieve. If you're talking about SQL injection then it can't happen with parameters. As an example, let's say you have this in VB code:Now, suppose a user was able to input data such that the value of someValue was "Hello World'); DELETE FROM Table1; INSERT INTO Table1 (SomeColumn) VALUES ('Hello World". That means that the actual SQL code that you would be executing would be:vb Code:
Dim sql As String = "INSERT INTO Table1 (SomeColumn) VALUES ('" & someValue & "')"I'm sure you would agree that that's not good. You would be inserting a row, then deleting every row, then inserting a row. Not what you had in mind from the SQL code that you wrote. It would be possible for a clever user to inject even more damaging SQL code into your statements.SQL Code:
INSERT INTO Table1 (SomeColumn) VALUES ('Hello World'); DELETE FROM Table1; INSERT INTO Table1 (SomeColumn) VALUES ('Hello World')
Now, let's say that your VB code looked like this instead:In that case the database would simply insert a single row with the value "Hello World'); DELETE FROM Table1; INSERT INTO Table1 (SomeColumn) VALUES ('Hello World" in the SomeColumn column. That's why allowing the user to insert literal values into an SQL statement is bad and using parameters is good. Unless at some point you actually execute the contents of the SomeColumn column as SQL then you're protected, no matter what it contains.vb Code:
Dim sql As String = "INSERT INTO Table1 (SomeColumn) VALUES (@SomeColumn)" myCommand.Parameters.AddWithValue("@SomeColumn", someValue)




Reply With Quote