Problemas con comillas

Tengo que estar de acuerdo con Eduardo.

Las consultas parametrizadas no sólo harán que no tengas que preocuparte de
las comillas, formato de fechas y cosas así. Sino que además son más
eficientes y seguras. Se reutiliza el plan de ejecución y se impide la
inyección de código SQL.

Si el usuario mete en la caja de texto "'; DROP TABLE NombreTabla; " y tu
estás construyendo la instrucción SQL concatenando con el cuadro de texto,
imagina qué pasa.

Otra cuestión acerca de hacer aplicaciones que funciones con cualquier
sistema de bases de datos:

¿Cuantas veces en la vida de una aplicación se ha cambiado el sistema de
base de datos?


Saludos:

Jesús López



"Edie" escribió en el mensaje
news:

esta solucion es buena si tu aplicacion no es de tipo distribuida de lo
contrario es ina mala opción.

por ejemple si en algun momento deses cambiar el provider de base de datos
tu aplicacion implicaria demaciados cambios...

pero es una buena opcion ya que estas clases se encargan de hacer lo
anterior, validar tu SQLQuery pero solo para el provider en que han sido
creadas...

"Eduardo A. Morcillo [MS MVP VB]" escribió:

Usa parametros. Por ejemplo:

Dim cmd As New SqlCommand

cmd.Connection = conexion
cmd.CommandText = "INSERT INTO TABLA (Campo1, Campo2) VALUES(@CAMPO1,
@CAMPO2)"

cmd.Parameters.Add("@CAMPO1", txtCampo1.Text)
cmd.Parameters.Add("@CAMPO2", txtCampo2.Text)

Try
conexion.Open()
cmd.ExecuteNonQuery()
Finally
conexion.Close()
End Try

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Eso de la seguridad es un poco relativo, si tu sentencia es por ejemplo
"select * from facturas where factura=" & var
que mas da que a continuacion añada drop?, en casi cualquier consulta
entiendo que no pueden convivir 2 instrucciones, se generaria error no?

"Jesús López" escribió en el mensaje
news:

Tengo que estar de acuerdo con Eduardo.

Las consultas parametrizadas no sólo harán que no tengas que preocuparte
de las comillas, formato de fechas y cosas así. Sino que además son más
eficientes y seguras. Se reutiliza el plan de ejecución y se impide la
inyección de código SQL.

Si el usuario mete en la caja de texto "'; DROP TABLE NombreTabla; " y tu
estás construyendo la instrucción SQL concatenando con el cuadro de texto,
imagina qué pasa.

Otra cuestión acerca de hacer aplicaciones que funciones con cualquier
sistema de bases de datos:

¿Cuantas veces en la vida de una aplicación se ha cambiado el sistema de
base de datos?


Saludos:

Jesús López



"Edie" escribió en el mensaje
news:

esta solucion es buena si tu aplicacion no es de tipo distribuida de lo
contrario es ina mala opción.

por ejemple si en algun momento deses cambiar el provider de base de
datos
tu aplicacion implicaria demaciados cambios...

pero es una buena opcion ya que estas clases se encargan de hacer lo
anterior, validar tu SQLQuery pero solo para el provider en que han sido
creadas...

"Eduardo A. Morcillo [MS MVP VB]" escribió:

Usa parametros. Por ejemplo:

Dim cmd As New SqlCommand

cmd.Connection = conexion
cmd.CommandText = "INSERT INTO TABLA (Campo1, Campo2) VALUES(@CAMPO1,
@CAMPO2)"

cmd.Parameters.Add("@CAMPO1", txtCampo1.Text)
cmd.Parameters.Add("@CAMPO2", txtCampo2.Text)

Try
conexion.Open()
cmd.ExecuteNonQuery()
Finally
conexion.Close()
End Try

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

No señor, por lo menos en SQL Server y en otros sistemas de base de datos
está permitido mandar más de una sentencia SQL en el mismo proceso por
lotes. Así que de relativo nada, tienes un agujero de seguridad como la boca
del metro.

Saludos:

Jesús López

Pues me dejas frito, tengo un monton de casos de estos, ¿aparte de usar
parametros que solucion se le puede dar?

"Jesús López" escribió en el mensaje
news:Oj7z$

No señor, por lo menos en SQL Server y en otros sistemas de base de datos
está permitido mandar más de una sentencia SQL en el mismo proceso por
lotes. Así que de relativo nada, tienes un agujero de seguridad como la
boca del metro.

Saludos:

Jesús López

¿Mejor que usar consultas parametrizadas?. Pues usar procedimientos
almacenados que es aún más seguro, ya que con estos, no es necesario dar
permisos para acceder directamente a las tablas. Si los usuarios tienen
permiso para SELECT, UPDATE y DELETE en una tabla. ¿Qué les impide desde el
Excel usando MSQUERY o desde cualquier otra herramienta como desde el Access
usando una consulta de paso a través, ejecutar DELETE FROM Tabla? cualquier
usuario malintencionado y con no demasiados conocimientos lo podrá hacer.

Saludos:

Jesús López



"Cid" escribió en el mensaje
news:

Pues me dejas frito, tengo un monton de casos de estos, ¿aparte de usar
parametros que solucion se le puede dar?

"Jesús López" escribió en el mensaje
news:Oj7z$

No señor, por lo menos en SQL Server y en otros sistemas de base de datos
está permitido mandar más de una sentencia SQL en el mismo proceso por
lotes. Así que de relativo nada, tienes un agujero de seguridad como la
boca del metro.

Saludos:

Jesús López