¿Por qué recibo este error de código de consulta? Cosas Personales

Porque estás rompiendo casi todas las reglas del libro. Hay varios problemas aquí, e incluso si lo hace funcionar, todo lo que tendría que hacer para romperlo sería escribir algo como “John” en uno de sus cuadros de texto. Escribiré algunos ejemplos, pero lo haré en C # para mi propia comodidad. Sin embargo, no se preocupe, los idiomas son más o menos los mismos.

1. Parametrice sus consultas. En lugar de lo que estás haciendo, haz algo como:

var change = “algún valor”;
var member = “algún miembro”;

var sql = “ACTUALIZAR miembros SET req = @request, change = @change WHERE member = @member;”;
utilizando (var connection = new SqlConnection (“…”))
utilizando (comando var = nuevo SqlCommand (sql, conexión))
{
command.Parameters.Add (“@ request”, SqlDbType.NVarChar, 50) .Value = change;
command.Parameters.Add (“@ member”, SqlDbType.NVarChar, 50) .Value = member;

conexión abierta ();
command.ExecuteNonQuery ();
}

EDITAR: se me pidió que proporcionara la respuesta en VB.NET, y lo haré para el primer ejemplo de código. Sin embargo, realmente no debería ser necesario, dado que los idiomas son (al menos para este ejemplo) idénticos. De todos modos, aquí hay una traducción de este ejemplo:

Imports System.Data Imports System.Data.SqlClient Module Example Sub Main() Dim member As String = "Some Member" Dim change As String = "Some Change" Dim sql As String _ = "UPDATE members SET req = @request, change = @change WHERE member = @member;" Using connection As SqlConnection = New SqlConnection("...") Using command As SqlCommand = New SqlCommand(sql, connection) command.Parameters.Add("@request", SqlDbType.NVarChar, 50).Value = change command.Parameters.Add("@member", SqlDbType.NVarChar, 50).Value = member connection.Open() command.ExecuteNonQuery() End Using End Using End Sub End Module

Si no haces esto, eres vulnerable a los ataques de inyección SQL. Además, esto es un poco más fácil de leer, administrar y depurar, ¿verdad?

2. Capa su arquitectura

Tiene un código que toca la base de datos y la interfaz de usuario en el mismo método. Esto es malo. Debe haber al menos tres capas. Necesitas al menos:

– “Capa de acceso a datos”
Esta es su base de datos + cualquier forma que elija para administrar sus datos desde el código. Esto podría ser un ORM (mapeador relacional de objetos), o puede hacerlo usted mismo, como lo está haciendo. Sin embargo, debe estar separado del resto de su código. Trate de imaginar que el mecanismo que usa para almacenar datos, su base de datos, podría cambiar. Tal vez necesite soportar una base de datos de documentos. Tal vez necesite respaldar el almacenamiento local de datos y la sincronización con una base de datos más adelante. Realmente no importa, pero crea la capa. Me lo agradecerás más tarde.

– “Capa de lógica de negocios”
Aquí es donde su programa “sucede”. Cualquier funcionalidad que necesite implementar, impleméntela aquí. A esta capa no le importa cómo se almacenan sus datos, ni sabe sobre su interfaz de usuario. Solo lógica. Piénsalo. ¿Qué sucede si necesita ofrecer una versión web de su aplicación más adelante? ¿Cambiar el diseño de interacción por completo? ¿Ofrecer una aplicación móvil? Si no tiene su lógica de negocios separada, cambiar su diseño de interacción será muy difícil. Y crear un nuevo front-end esencialmente requerirá que vuelva a escribir su lógica, con nuevos errores, más depuración y mucho tiempo invertido.

– “capa de interfaz de usuario”
Esta es tu interfaz de usuario. No más. No menos. No debería saber sobre sus datos, o sobre su lógica, realmente. Debería mostrar la salida de su capa de lógica de negocios y debería poder enviarle comandos. Cuanto más delgada pueda hacer esta capa, mejor.

Ahora, hay muchos escenarios en los que puede necesitar más de 3 capas, pero nunca necesitará menos.

3. Separe sus preocupaciones

En su código, tiene una mezcla impía de objetos que hacen cosas muy diferentes malladas juntas. Esto será muy difícil de mantener. En su ejemplo, parece estar tomando dos datos, un “miembro” y un “cambio”, como cadenas y luego persistiendo los datos directamente. Pero ni los miembros ni los cambios son cadenas. Estos son conceptos. No conozco sus requisitos ni el propósito de su programa, por lo que no puedo hacer una sugerencia definitiva aquí, pero hay muchas prácticas que podrían funcionar en esta situación.

POO clásico
El miembro es un objeto y necesita que ocurra algún evento de “cambio” en el miembro.

public class Member { public void Change(string someValue) { // do whatever you need to do, // then call data layer to save.

// IE
DataLayer.Save (esto);
}
}

Demostración pública nula (Miembro someMember, string someValue)
{
member.Change (someValue);
}

EDITAR: Y en VB

Public Class Member

Cambio secundario público (ByVal someValue As String)
‘haz lo que tengas que hacer,
‘luego llame a la capa de datos para guardar.

‘IE
DataLayer.Save (Me)
End Sub

Clase final

Public Sub Demo (ByVal someMember As Member, ByVal someValue As String)
member.Change (someValue)
End Sub

Código orientado al servicio
Agrupe funcionalidades similares en servicios. Si se trata principalmente de miembros, algo así como

MemberService.ChangeMember(member, change);

O, si se trata principalmente del cambio, y cambian muchas cosas diferentes, algo como:

ChangeService.ChangeMember(member, change);

4. Use métodos pequeños y maneje excepciones
Haga un esfuerzo para hacer que cada método (función o sub en VB) haga lo menos posible y sea lo más breve posible. Esto facilita la comprensión, el mantenimiento y la depuración de su código.

También facilita el manejo de excepciones. Si algo puede salir mal, maneje la excepción, vea si sucedió. Incluso si desea que falle de manera más general, o si desea que el programa se bloquee en caso de error, maneje y vuelva a lanzar la excepción. Registre lo que sucedió o agregue información al objeto de excepción.

try { var sql = "UPDATE members SET req = @request, change = @change WHERE member = @member;"; using (var connection = new SqlConnection("...")) using (var command = new SqlCommand(sql, connection)) { command.Parameters.Add("@request", SqlDbType.NVarChar, 50).Value = change; command.Parameters.Add("@member", SqlDbType.NVarChar, 50).Value = member;

conexión abierta ();
command.ExecuteNonQuery ();
}
}
catch (excepción SqlException)
{
// algo salió mal
// al menos lo registramos
Log.LogError (excepción, “Error al comunicarse con la base de datos”);

// todavía queremos fallar, así que solo pasa la excepción
lanzar;
}
captura (excepción desconocida)
{
// algo salió mal
// al menos lo registramos
Log.LogError (desconocido, “Algo más salió mal”);

// todavía queremos fallar, así que solo pasa la excepción
lanzar;
}

EDITAR: Una vez más, traducido

Imports System.Data Imports System.Data.SqlClient

Ejemplo de módulo

Sub principal()

Tratar

Dim member As String = “Algún miembro”
Dim change As String = “Some Change”

Dim sql As String _
= “ACTUALIZAR miembros SET req = @request, change = @change WHERE member = @member;”

Uso de la conexión como SqlConnection = New SqlConnection (“…”)
Usando el comando As SqlCommand = New SqlCommand (sql, connection)

command.Parameters.Add (“@ request”, SqlDbType.NVarChar, 50) .Value = change
command.Parameters.Add (“@ member”, SqlDbType.NVarChar, 50) .Value = miembro

conexión abierta ()
command.ExecuteNonQuery ()

Terminar de usar
Terminar de usar

Capturar ex como SqlException

‘ algo salió mal
‘por lo menos lo registramos
Log.LogError (por ejemplo, “Error al comunicarse con la base de datos”)

“todavía queremos fallar, así que solo pasa la excepción
Lanzar

Captura desconocida como excepción

‘ algo salió mal
‘por lo menos lo registramos
Log.LogError (desconocido, “Error al comunicarse con la base de datos”)

“todavía queremos fallar, así que solo pasa la excepción
Lanzar

Intento final

End Sub

Módulo final

El siguiente ejemplo es un poco complicado, pero como dije, otra práctica posible es envolver y volver a lanzar. En este ejemplo, tiene dos categorías de excepciones que afectan al usuario final: las que desea mostrar como mensaje de error al usuario y las que desea bloquear el programa.

EDITAR: Esta vez traduciré con anticipación.

' The only this even slightly different ' in VB is inheritance syntax

Excepción heredada de clase pública
Herencia Excepción

Public Sub New (ByVal innerException como excepción, mensaje ByVal como cadena)
MyBase.New (mensaje, interiorExcepción)
End Sub

Clase final

Y el ejemplo original

public class ErrorMessageException : Exception { public ErrorMessageException(Exception innerException, string message) : base(message, innerException) {

}
}

clase pública CatestrophicException: Exception
{
CatestrophicException pública (Excepción innerException, mensaje de cadena)
: base (mensaje, interiorExcepción)
{

}
}

// y luego en tu método

tratar
{
var sql = “ACTUALIZAR miembros SET req = @request, change = @change WHERE member = @member;”;
utilizando (var connection = new SqlConnection (“…”))
utilizando (comando var = nuevo SqlCommand (sql, conexión))
{
command.Parameters.Add (“@ request”, SqlDbType.NVarChar, 50) .Value = change;
command.Parameters.Add (“@ member”, SqlDbType.NVarChar, 50) .Value = member;

// todavía queremos fallar, así que solo pasa la excepción
lanzar una nueva ErrorMessageException (excepción, “Lo siento, intente nuevamente más tarde”);
}
captura (excepción desconocida)
{
// algo salió mal
// al menos lo registramos
Log.LogError (desconocido, “Algo más salió mal”);

// todavía queremos fallar, así que solo pasa la excepción
lanzar nueva CatestrophicException (no conocida, “pánico”);
}

// y tu método de entrada
Programa de clase
{

tratar
{
// hacer lógica de programa
}
catch (ErrorMessageException ex)
{
// muestra mensaje de error
}
captura (catástrofe de excepción catastrófica)
{
// iniciar sesión y bloquearse
}
captura (excepción de excepción)
{
// olvidamos algo
}
}