Introducción

Lo que vamos a hacer es ejecutar consultas que se encuentran en una base de datos de Access desde una aplicación escrita en VB .NET. Primero vamos a ver un poquito de teoria (Prometo, intentar ser breve).

La teoria

Empezare diciendo que una “Consulta” en Access es un conjunto de sentecias SQL (SELECT, INSERT, UPDATE, etc.) a las que se le asigna un nombre que representa su funcionalidad. Veamos un pequeño ejemplo para que se entienda mejor:

Consulta “AgregarCliente”

INSERT INTO TblClientes (RazonSocial, Domicilio)
VALUES (“Pablo Tilli”, “Mi casa”);

En este ejemplo vemos una consulta llamada “AgregarCliente”. Al ser ejecutada esta consulta se inserta un nuevo registro en una tabla llamada TblClientes. El registro que se agrega tiene dos campos: “RazonSocial” y “Domicilio”, que valen “Pablo Tilli” y “Mi casa” respectivamente.
Alguno de ustedes puede decir: “¿Para qué escribirlo en Access, si yo eso lo escribo en el código de mi aplicación y todo me funciona bien” y de hecho puede ser verdad, pero justamente mi objetivo aquí es tratar de convencerlos de que no lo hagan. ¿Que por qué digo eso, te preguntas? Bueno aquí les nombro algunas razones:

1) Imaginen que tenemos dos o más aplicaciones que muestran un listado de vendedores que tiene dos columnas: Código y Razón Social. Obviamente, todas las aplicaciones tendrán porciones de código que serán iguales, ya que seguramente para acceder a estos datos usaran el mismo query. Aquí tenemos un motivo: estamos repitiendo el Query en todas las aplicaciones. Esta bien, todavía no te convencí, así que acá va otra razón.

2) Supongamos que ahora el usuario quiere que el listado de vendedores también incluya el domicilio de los vendedores. En este caso deberíamos modificar el query en todas las aplicaciones para que también retorne el campo “Domicilio” (Lindo¿NO?). Pero si hubiéramos guardado el query en la base de datos, solo modificaríamos el query en ésta y todas las aplicaciones quedarían intactas. Obviamente, que asumimos que las aplicaciones generan los listados en forma dinámica, o sea que no usan una cantidad de columnas predefinidas. Que no te convencí, bueno sigamos.

3) Otra cuestión tiene que ver con que hay determinadas consultas SQL, que necesitan ser escrita por gente especializada en el tema, ya que la performance de la base de datos puede cambiar mucha según como están escritos los queries, que campos se indexen, etc. De hecho (Según el tamaño de la empresa) seguramente habrá un grupo encargado de la administración de la base de datos y por otro lado estarán los programadores que acceden a ella.
Trabajando de esta manera, al programador solo le diran como se llama la consulta que debe ejecutar para cada tarea que deba hacer (por ejemplo: AgregarUnCliente, BuscarUnVendedor, etc) y que parámetros pasarle a cada una, y así el programador ni siquiera sabe cual es la tabla donde esta grabando, ni los nombres reales de los campos (Ya que puede ser que no sean los nombres de los parámetros). Esta claro que esto brinda mas seguridad a la base de datos y aleja al programador del diseño de la base de datos.

Podría seguir con unas cuantas razones mas, pero no me quiero seguir extendiendo. Por ultimo quiero decir que elegí Access para que sea mas facil entender el tema, ya que seguramente la mayoria concozca esta herramienta, pero cuando se quiera hacer algo mas serio, deberíamos usar SQL Server u Orcale entre otros. En estos, no se llaman “Consultas” como en Access, sino “Procedimiento almacenados” y brindan muchas mas opciones que las “Consultas”, ya que incluso pueden ejecutar estructuras repetitivas, condiciones, etc . De hecho son bloques de codigo; como si se tratara de un procedimiento (Sub) en una aplicación, pero guardo en la base de datos (De ahí su nombre: Procedimiento almacenado).

Bueno, si no logre convencerlos, falle en mi objetivo, pero seguire intentando :) . Ahora si, basta de teoria y empecemos a trabajar un poco.

Las consultas que van del lado la base de datos

La base de datos que usaremos tiene solo una tabla, que se llama “TblClientes”. La tabla tiene los siguientes campos

NumeroDeCliente (Numero)
RazonSocial (Texto)
Domicilio (Texto)

Tambien tendremos tres “Consultas” que detallo a continuación:

Consulta “AgregarCliente”

PARAMETERS paramNumCliente Short, paramRazonSocial Text ( 255 ), paramDomicilio Text ( 255 );

INSERT INTO TblClientes ( NumeroDeCliente, RazonSocial, Domicilio )
VALUES  (paramNumCliente, paramRazonSocial, paramDomicilio);

Consulta “ModificarCliente”

PARAMETERS paramNumCliente Short, paramRazonSocial Text ( 255 ), paramDomicilio Text ( 255 );

UPDATE tblClientes
SET tblClientes.RazonSocial = [paramRazonSocial], tblClientes.Domicilio = [paramDomicilio]
WHERE tblClientes.NumeroDeCliente=[paramNumCliente];

Consulta “EliminarCliente”

PARAMETERS paramNumCliente Short;

DELETE tblClientes.NumeroDeCliente
FROM tblClientes
WHERE tblClientes.NumeroDeCliente=paramNumCliente;

Esto es todo del lado de la base de datos

La aplicación de prueba

La aplicación que vamos a realizar es muy simple, e incluso me pueden acusar de que es poco realista al igual que el diseño de nuestra base de datos, pero mi objetivo aqui, es concentrarnos sólo en lo referido a la ejecucion de una "Consulta", asi que nos alcanza este pequeño esquema para usar como ejemplo.

La idea de nuestra aplicacion es la siguiente:

1- Al pulsar el botón Agregar, se agrega en la tabla de clientes un registro con los datos cargados en las cajas de texto

2- Al pulsar el botón Modificar, se modificara el registro que tenga como "Numero de cliente" el especificado en la caja de texto que lleva el mismo nombre.

3- Al pulsar el botón Eliminar, se eliminara el registro que tenga el número de cliente especificado y no se tomaran en cuenta los datos ingresados en las otras cajas de textos (txtRazonSocial y txtDomicilio)

A continuacion podemos ver el codigo para hacer esto:

Private Cnn As OleDb.OleDbConnection

Private Sub cmdAgregar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdAgregar.Click
    EjecutarConsulta("AgregarCliente")
End Sub

Private Sub cmdModificar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdModificar.Click
    EjecutarConsulta("ModificarCliente")
End Sub

Private Sub cmdEliminar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdEliminar.Click
        EjecutarConsulta("EliminarCliente")
End Sub

'Creamos un procedimiento que ejecute la consulta que le especifiquemos
Private Sub EjecutarConsulta(ByVal NombreConsulta As String)
        Dim cmd As OleDb.OleDbCommand

        'Me conecto a la base
        Conectar()

        'Establezo cual es la consulta a ejecutar
        cmd = New OleDb.OleDbCommand(NombreConsulta, Cnn)

        'Avisamos que vamos a ejecutar una "Consulta"
        cmd.CommandType = CommandType.StoredProcedure

        'Cargo los valores de los campos
        CargarParametros(cmd.Parameters)

        'Ejecuto el comando
        cmd.ExecuteNonQuery()

        'Me desconecto de la base
        Desconectar()
End Sub

'Este procedimiento se encarga de cargar los parametros con la informacion ingresada por el usuario.
Private Sub CargarParametros(ByRef Parametros As OleDb.OleDbParameterCollection)
        'Cargo los valores de los parametros
        With Parametros
            .Add("paramNumCliente", txtNumCliente.Text)
            .Add("paramRazonSocial", txtRazonSocial.Text)
            .Add("paramDomicilio", txtDomicilio.Text)
        End With
End Sub

Public Sub Conectar()
        Cnn = New OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Prueba.mdb")
        Cnn.Open()
End Sub

Public Sub Desconectar()
        Cnn.Close()
End Sub

 

Conclusion

 

Mi intension aqui fue tratar de hacer una muy pequeña introduccion al hecho de tener por un lado los datos y por otro la aplicacion, pero que "sean los propios datos los que se manejen" y que asi el programador se concentre en la aplicacion y no tanto en la manera en que estos datos deben ser obtenidos. Como ya dije anteriormente tal vez Access no es la herramienta optima para lograr esta independencia, pero espero estar escribiendo proximamente algo sobre como hacerlo con SQL Server u otro, y asi ver que nos pueda brindar este tipo de herramientas.

Si alguien tiene algo para opinar, aconsejar, corregir, consultar o simplemente decir algo me lo comunican a mi mail ([email protected])