Visual Basic y SQL Server

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server

1


Edición 1.0 Prohibida la reproducción total o parcial Sin nuestro consentimiento Derechos de copia reservados www.LibrosDigitales.NET

2


Presentación del Caso a Desarrollar Objetivos En este primer módulo se desarrollaran los siguientes puntos: ü ü ü ü ü ü ü ü

Presentación del escenario de trabajo. Criterios para la estandarización de la base de datos. Modelo lógico y físico de la base de datos. Creación de tablas de la base de datos. Definir la integridad de la base de datos. Creación del diagrama de la base de datos Cargar datos de muestra. Mecanismo de seguridad de SQL Server.

3


Presentación del escenario de trabajo Comercial Lima S.A.C. es una empresa que se dedica a la comercialización de diversos productos, donde la atención al cliente se describe en los siguientes pasos: ü

El cliente elabora su pedido y es anotado en una hoja de pedido.

ü

Se verifica en el almacén si existe stock del pedido del cliente.

ü

Si no hay problema de stock, se procede a elaborar la boleta ó factura, y el documento pasa a caja. Si hay problema de stock, se realiza las correcciones respectivas en la hoja de pedido, y pasamos al paso 2.

ü

El cliente pasa a caja a cancelar.

ü

Con el documento cancelado, el cliente pasa a despacho a recoger sus productos.

En estos momentos todo el procedimiento de atención al cliente es manual por lo que se tienen los siguientes problemas: ü

Atención lenta.

ü

No se tiene un control de stock adecuado, por lo tanto nunca se sabe cuanto es el stock real de cada artículo.

ü

Control de ingresos manual, por lo que el cierre de caja lleva muchas horas.

ü

La elaboración de informes para el gerente es lenta ya que todo tipo de resumen del día es manual.

ü

No existe ningún tipo de estadística para la toma de decisiones futuras.

La empresa atiende un promedio de 30 personas por hora con tendencia a aumentar, por lo que es necesario implementar un sistema computarizado.

J Se adjunta al libro el modelo de datos en Erwin

4


Reglas de Negocio Las reglas de negocio son el conjunto de condición que la empresa establece para realizar sus transacciones con sus clientes. Para este caso las condiciones son mínimas y se enumeran a continuación: ü

Solo compra con factura a sus proveedores.

ü

Vende con factura o boleta.

ü

Solo vende al contado y en efectivo.

ü

Cuando el cliente compra mas de seis unidades por artículo se aplica un descuento que se define para cada artículo.

5


Criterios para estandarizar la base de datos Debemos tener en cuenta que cuando realizamos el modelo de una base de datos cumpla con un mínimo de objetivos básicos, que los explico a continuación: ü

Debe almacenar toda la información de la actividad de la empresa para la cual esta diseñada.

ü

No debe guardar información redundante. Hay casos en los que es necesario para facilitar otras operaciones, pero debe ser bien analizado.

ü

Debe ser de fácil mantenimiento. Las inserciones, actualizaciones y eliminaciones no deben ser complejas desde el punto de vista de la programación.

ü

Debe ser de fácil consulta. Si deseamos obtener cierta información debe ser en base a una consulta sencilla, o en todo caso las operaciones a realizar no deben ser complejas, en algunos casos no se puede evitar la complejidad, pero hay que tratar de minimizarla.

Generalmente el desarrollo del un sistema recae sobre un equipo, cuando hablamos sobre estandarización de la base de datos, nos referimos al conjunto de criterios que asume el equipo de trabajo como normas para el desarrollo del sistema. Esto quiere decir que no todos los equipos de trabajo tienen los mismos estándares, puede que coincidan en alguno de ellos, pero no es una norma. Estandarizar una base de datos trae muchas ventajas, y algunas de ellas son: ü

Todas las personas del equipo desarrollan el sistema asumiendo los mismos criterios.

ü

Si alguien del equipo tiene que retirarse por alguna razón, cualquier otra persona del equipo puede reemplazarlo.

ü

Es fácil que una persona nueva se integre al equipo.

Recomendaciones ü ü ü

ü ü

El nombre de las entidades deben estar en singular. Los nombres de las columnas en lo posible deben ser únicos en toda la Base de Datos. Las columnas que correspondes a Claves Foráneas deben tener el mismo nombre de la columna que corresponde a la clave primaria de la tabla con la que se relaciona. No usar espacios en blanco, letras acentuadas, la letra ñ, ni subrayado al dar nombre a las tablas y columnas. Usar un prefijo para el nombre de las columnas cuando sea necesario. Por ejemplo el atributo Nombre se repite en las entidades Empresa, y Vendedor, para diferenciarlas se utiliza el prefijo Nom, por lo tanto a las columnas se le asigna los siguientes nombre NomEmpresa y NomVendedor, tal como lo puede apreciar en el modelo físico.

6


Modelo Lógico y Físico de la Base de Datos Introducción Para llegar a un modelo lógico de la base de datos es necesario antes realizar algunos pasos que por las características de este manual solo los mencionare. ü

Recoger información de las personas que trabajan en la empresa.

ü

Recoger una copia de los diferentes tipos de documentos que utiliza la empresa.

ü

Informarse de las proyecciones que la empresa tiene para el futuro.

ü

Identificar las entidades y sus relaciones.

ü

Identificar los atributos de cada entidad.

ü

Normalizar el modelo.

En este caso son pocos pasos y aparentemente sencillos, pero es importante comentar que en muchas empresas se requiere de personal altamente calificado y con experiencia para realizar el análisis, cuyos factores pueden ser: ü

Tamaño de la empresa.

ü

Volumen de información.

ü

Reglas de negocio bastante complejas, etc.

J

Información detallada sobre el correcto Diseño de Bases de Datos lo entrará en www.LibrosDigitales.NET

7


Modelo Lógico A continuación se muestra el modelo lógico que se ha diseño para nuestro caso, lo que se quiere con este modelo es que sea útil y a la vez fácil de entender.

Figura 1.1 Modelo Lógico de la Base de Datos.

8


Modelo Físico Luego de tener el modelo lógico, debemos pasarlo al modelo físico, donde definimos el nombre real de cada columna en la base de datos, con su respectivo tipo de dato y nulidad respectivamente. El modelo físico se define para un tipo de motor de base de datos, en nuestro caso se trata de SQL Server, y el resultado es el siguiente:

Figura 1.2 Modelo Físico de la Base de Datos. Para implementar este modelo utilizaremos técnicas de scripting. La integridad de datos, si bien se puede definir en una herramienta de modelamiento de datos como ERwin, se definirá ejecutando las sentencias del Lenguaje de Definición de Datos (DDL) de SQL, desde la herramienta SQL Server Query Analyzer.

9


Creación de la Base de Datos 1. Inicie SQL Server Enterprise Manager. 2. Conéctese a su servidor de bases de datos (de ser necesario, registre previamente el servidor).

Figura 1.3 SQL Server Enterprise Manager.

10


Creación de la Base de Datos 1. Haga clic sobre la carpeta Base de datos utilizando el botón secundario del ratón. 2. Del menú contextual, ejecute Nueva base de datos. Aparece el diálogo Propiedades de la base de datos. 3. En el control Name de la ficha General, digite BDLima. 4. Todos los demás parámetros los dejaremos con sus valores por defecto, así que hacemos clic sobre el botón Aceptar.

Figura 1. 4 Creación de la Base de Datos.

J Estamos preparando un manual de Access, pronto en www.LibrosDigitales.NET

11


Creación de las Tablas La creación de las tablas se hará mediante la ejecución de un script SQL que se encuentra en el archivo CreaTabla.sql. 1. En su aplicación SQL Server Enterprise Manager, haga clic sobre el botón Herramientas que se encuentra en la barra de herramientas. 2. En el menú desplegable, haga clic sobre Analizador de consultas SQL para cargar el Analizador de Consultas de SQL. 3. En el control desplegable de su barra de herramientas (Combo), seleccione la base de datos BDLima. 4. En el menú Archivo, ejecute el comando Abrir. Aparece el diálogo Abrir archivo de consulta. 5. Ubique en la carpeta donde se encuentran los archivos y seleccione el archivo CreaTablas.sql. Luego, haga clic en el botón Abrir.

Figura 1. 5 Analizador de Consultas. 6. Este script crea todas las tablas definidas en el modelo físico de la base de datos. Para ejecutarlo, en el menú Consulta haga clic en el comando Ejecutar, o haga clic sobre el botón Ejecutar consulta de la barra de herramientas.

12


Visualización de las tablas desde Enterprise Manager 1. Conmute al Enterprise Manager. 2. Expanda la carpeta Base de datos. Luego expanda BDLima, 3. Haga clic con el botón secundarios del Mouse en Tablas y ejecute el comando actualizar. También puede verificar las tablas que se han creado ejecutando la siguiente consulta:

use BDLima select * from sysobjects where type = 'u' GO

13


Definición de la integridad de datos La integridad de datos se puede definir de manera gráfica desde el Enterprise Manager. Sin embargo, utilizaremos el Analizador de consultas para familiarizarnos con las sentencias SQL del Lenguaje de Definición de Datos.

Creación de llaves primarias La sintáxis de la sentencia SQL que permite añadir una llave primaria a una tabla es la siguiente:

ALTER TABLE nombre_tabla ADD CONSTRAINT nombre_llave_primaria PRIMARY KEY ( columna(s)_llave_primaria ) Donde: ü ü ü

nombre_tabla es el identificador de la tabla a la que pertenece la llave primaria. nombre_llave_primaria es el nombre de la restricción llave primaria, y además el nombre del índice asociado a la restricción. columna(s)_llave_primaria son los nombres de la columna o columnas que se desean definir como la llave primaria de la tabla.

Para verificar la definición de la restricción puede utilizar el procedimiento almacenado del sistema sp_help entregándole como parámetro el nombre de la tabla.

SP_HELP nombre_tabla

14


Definir las Claves Primarias del Modelo A continuación pasaremos a describir las claves primarias de cada una de las tablas y los criterios que se han tenido en cuenta para su regla de formación, usted debe completar escribiendo la instrucción SQL que permita crearla. El nombre de la clave primaria debe tener la siguiente regla de formación pk_xxxxx, donde xxxxx es el nombre de la tabla.

J Obtenga información adicional en www.LibrosDigitales.NET Descripción de cada tabla Tabla: Linea Clave Primaria IdLinea Comentario Los artículos están agrupados en líneas (ó categorías), cada línea representa una clase de artículo y esta identificada por un número correlativo. Esta columna es de tipo IDENTITY. Además, cada línea tiene un prefijo y su propio contador los cuales se utilizan para generar el código de cada artículo. Por ejemplo la línea que corresponde a licores su prefijo es LIC y los artículos tienen los siguientes códigos LIC00001, LIC00002, LIC00003, etc. Tabla: Articulo Clave Primaria IdArticulo Comentario Para generar el código del artículo es necesario tener en cuenta la línea a la cual pertenece, para determinar el prefijo y el número correlativo que le corresponde. Por ejemplo si pertenece a la línea de Granos su prefijo es GRA y los códigos de los artículos serian GRA00001, GRA00002, GRA00003, etc. Tabla: Unidad Clave Primaria IdUnidad Comentario La unidad determina la unidad de comercialización de cada artículo.

15


Tabla: Empresa Clave Primaria IdEmpresa Comentario Para generar el código de la empresa se utiliza la siguiente plantilla E#####, por ejemplo E00001, E00002, E00003, etc. El control del correlativo se lleva a cabo en la tabla Control. Tanto los clientes como proveedores están registrados en esta tabla, esto por que un cliente de un artículo, puede ser proveedor de otro artículo diferente. Las columnas cliente y Proveedor determinan si es cliente, proveedor ó ambos. Tabla: Vendedor Clave Primaria IdVendedor Comentario Para generar el código de un vendedor se utiliza la siguiente plantilla V#####, por ejemplo V00001, V00002, V00003, etc. El control del correlativo se lleva a cabo en la tabla Control. Tabla: TipoDoc Clave Primaria IdTipoDoc Comentario Esta tabla permite clasificar los documentos y controlar cada correlativo de los documentos de salida. Esta clave primaria es de tipo IDENTITY. El contenido de esta tabla inicialmente es: IdTipoDo DesTipoDoc c 1 Factura (Venta) Factura 2 (Compra) 3 Boleta (Venta)

Accion

Serie

Salida

1

Contado r 18

Ingreso

0

0

Salida

1

1

La columna Accion, determina si el documento es de ingreso ó de salida, si el documento es de ingreso su número lo determina el proveedor, solamente se controla la serie y el número del documento cuando es de salida (Venta).

16

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Tabla: Documento Clave Primaria IdDocumento Comentario Cada documento tiene un número correlativo que lo identifica, este correlativo es controlado en la tabla Control. Todos los documentos de compra y venta están registrados en esta tabla, la columna IdTipoDoc determina la clase de documento y columna Numero guarda el número real del documento. Tabla: Detalle Clave Primaria IdDocumento, IdArticulo Comentario En este caso la clave primaria esta formada por dos columnas, y los valores de estas columnas se obtienen de las entidades Documento y Artículo. Esta clave primaria garantiza que en un documento no se repita un artículo. Tabla: Control Clave Primaria Parametro Comentario Esta clave primaria garantiza que no se repitan los parámetros. Los parámetros que tenemos en esta tabla y un ejemplo de los valores que pueda tener se muestran a continuación: Parametro Documento Empresa IGV Vendedor

Valor 1 11 18.0 12

Es importante mencionar que la tabla Control tiene códigos disponibles. Que el parámetro Empresa tenga valor 11, significa que hay 10 empresas registradas, y si ingresamos una nueva su código debe ser E00011 y el valor del parámetro se incrementaría en uno, o sea su nuevo valor sería 12. El parámetro IGV es de solo lectura cuando se realiza una venta, su valor es estable en el tiempo y no depende de la empresa, sino del gobierno.

17


Creación de llaves foráneas La sentencia SQL para definir una restricción llave foránea es la siguiente:

ALTER TABLE nombre_tabla_secundaria ADD CONSTRAINT nombre_llave_foránea FOREIGN KEY ( columna_llave_foránea ) REFERENCES nombre_tabla_primaria Donde: ü

nombre_tabla_secundaria es el identificador de la tabla a la que pertenece la llave foránea.

ü

nombre_llave_foránea es el nombre de la restricción llave foránea..

ü

columna_llave_foránea es el nombre de la columna que se desea definir como la llave foránea de la tabla secundaria.

ü

nombre_tabla_primaria es el identificador de la tabla primaria con la que la llave foránea relaciona a la tabla secundaria. La tabla primaria debe tener definida como llave primaria la columna con el atributo común con la tabla secundaria.

Para verificar la definición de la restricción puede utilizar el procedimiento almacenado del sistema sp_help.

18


Definir las Claves Foráneas del Modelo A continuación usted debe construir la instrucción SQL para definir la clave foránea de cada una de las tabla. Tabla: Articulo Instrucción SQL

Tabla: Documento Instrucción SQL

Tabla: Detalle Instrucción SQL

19


Creación de un diagrama de base de datos SQL Server permite crear diagramas que muestran las relaciones de toda o parte de la base de datos. Para crear un diagrama de base de datos: 1. En el Enterprise Manager, expanda su base de datos BDLima. 2. Haga clic sobre Diagramas utilizando el botón secundario del mouse. 3. Del menú contextual ejecute Nuevo diagrama de base de datos. Se carga el Asistente para Diagramas de Base de Datos. 4. Haga clic en el botón Siguiente. 5. En la lista Tablas disponibles, seleccione la tabla que desea mostrar en el diagrama, y haciendo clic en el botón Agregar, muévala a la lista Tablas que agregar al diagrama. 6. Repita el punto 5 con todas las tablas que desea mostrar en el diagrama. Para nuestro diagrama, seleccione todas las tablas. 7. Haga clic en el botón Siguiente. Luego, en el botón Finalizar. 8. Espere que SQL Server le responda que el diagrama ha sido generado. Luego, haga clic en el botón Aceptar. 9. Para finalizar, salve el diagrama como ModeloBDLima.

20


Figura 1. 6 Esquema de la Base de Datos.

21


Carga de los datos de muestra Para cargar datos de muestra se debe ejecutar la instrucción SQL INSERT, para nuestro caso se ha preparado un archivo llamado CargaDatos.SQL, lo que usted tiene que hacer, es simplemente cargarlo en el analizador de consultas y ejecutarlo.

Figura 1.7 Datos de Muestra.

Visualización del contenido de las tablas Para revisar el contenido de una tabla podemos utilizar el Enterprise Manager, ó la instrucción SQL SELECT en el Analizador de Consultas. Veamos un ejemplo:

use BDLima select * from articulo GO

22


El mecanismo de seguridad de SQL Server En esta parte, veremos cómo se maneja la seguridad en SQL Server, y qué es lo que determina lo que un usuario puede hacer en la base de datos a la que se conecta. Un usuario, para realizar labores efectivas sobre una base de datos, debe efectuar un esquema de seguridad de dos etapas: 1. La autenticación, que define a través de una cuenta de identificación de usuario, si éste puede acceder a una base de datos de SQL Server, y 2. Los permisos de validación, que determinan qué actividades puede realizar el usuario sobre la base de datos.

Modos de autenticación SQL Server Acerca de la autenticación, SQL Server soporta dos mecanismos de seguridad: ü

La autenticación integrada con Windows NT, que permite que un usuario acceda a SQL Server utilizando su cuenta de usuario Windows NT, y

ü

La autenticación SQL Server, que establece que el usuario debe tener una cuenta SQL Server, adicional a la cuenta Windows NT para poder acceder a SQL Server.

El mecanismo de seguridad SQL Server Para explicar qué es lo que determina que un usuario pueda acceder a SQL Server, y ejecutar acciones sobre una base de datos, lo haremos en base a la autenticación SQL Server. Se cuenta con un servidor Windows NT identificado como MiNTServer (ver Figura 1.8); éste tiene instalado el servidor de bases de datos SQL Server de nombre MiSQLServer. A su vez, el servidor SQL cuenta con las bases de datos: Ventas, Personal, y Finanzas. Las cuentas de usuario NT smatsukawa y lvillalba permiten a los propietarios de dichas cuentas acceder a determinados recursos del servidor Windows NT. Como los propietarios de estas cuentas NT acceden al servidor SQL utilizando el mecanismo de autenticación SQL Server, necesitan contar con cuentas de identificación para SQL Server (Login IDs). El administrador del servidor SQL ha creado para ellos los login IDs sergio y mila respectivamente. El login ID sergio le permite a la cuenta NT smatsukawa acceder a las bases de datos Ventas y Finanzas. El login ID mila otorga acceso a las bases de datos Personal y Finanzas a la cuenta NT lvillalba.

23


Figura 1.8 Autentificación de usuarios en SQL Server.

Los roles de bases de datos Para que una persona pueda realizar operaciones en una base de datos SQL debe estar registrada como usuario de la base de datos. Las operaciones que un usuario puede realizar sobre la base de datos están determinadas por los permisos de validación que se le han concedido. SQL Server ha concebido los roles de bases de datos como un mecanismo de administración de la seguridad en una base de datos. Por ejemplo, el rol db_datareader establece que todos los usuarios que pertenecen a este rol solo pueden efectuar operaciones de lectura sobre la base de datos a la que pertenece el rol. Cada base de datos cuenta con su propio conjunto de roles de bases de datos. En el diagrama, tanto el login ID sergio, como el login ID mila tienen acceso a la base de datos Finanzas ya que ambos están mapeados a los usuarios sergio y mila respectivamente, de dicha base de datos. Ambos pueden leer las tablas y vistas de la base de datos Finanzas porque los usuarios sergio y mila pertenecen al rol db_datareader. Adicionalmente, el usuario sergio puede modificar la data de la base de datos porque también pertenece al rol db_datawriter. Sin embargo, el administrador o el dueño de la base de datos podrían determinar que, por ejemplo, el usuario sergio no pueda leer ni escribir sobre algunas tablas revocándole el permiso sobre dichas tablas. En otras palabras, lo que un usuario puede hacer en una base de datos está determinado por el rol o roles al que el usuario pertenece, y por los permisos específicos sobre los objetos de la base de datos. En el mismo diagrama de la Figura 1.8, el login ID mila está mapeado al usuario dbo (database owner - propietario de la base de datos) de la base de datos Personal. Por lo tanto, mila como propietaria de la base de datos no tiene ninguna restricción sobre ella. Toda base de datos tiene su usuario dbo, el que pertenece de manera predeterminada al rol db_owner de dicha base de datos.

24


Y, ¿en el caso de la autenticación integrada a Windows NT? En este caso, el usuario accede a una base de datos utilizando su cuenta de usuario NT sin necesidad de contar con un login ID SQL Server. Para que esto sea posible, la cuenta de usuario NT debe estar mapeada a un usuario de la base de datos a la que debe tener acceso.

En resumen ü

Una cuenta de usuario NT otorga acceso a los recursos del servidor Windows NT.

ü

Un login ID de SQL Server permite acceder a una o mas bases de datos del servidor SQL.

Un usuario de base de datos específica los roles a cumplir en la base de datos, y los permisos específicos sobre los objetos de la base de datos. Para que un login ID o una cuenta de usuario NT puedan ejecutar tareas en la base de datos deben tener mapeado un usuario de la base de datos.

25


Acceso a Datos Objetivos En este segundo módulo desarrollaremos los siguientes puntos: ü

OLE DB.

ü

ActiveX Data Object (ADO)

ü

Conexión con la Base de Datos.

ü

Ejecución de Comandos.

ü

Manejo de Resultados.

26


OLE DB Es una arquitectura de base de datos que proporciona integración universal de datos a través de una red empresarial, desde un gran sistema a un equipo de escritorio, independientemente del tipo de datos. OLE DB es una estrategia de acceso a datos más generalizada y más eficaz que ODBC, debido a que permite el acceso a un mayor número de tipos de datos y está basada en el Modelo de objetos componentes (COM). OLE DB es una estratégica de programación de sistemas de Microsoft para obtener acceso a los datos de una organización. OLE DB es una especificación abierta diseñada para desarrollar sobre el éxito de ODBC proporcionando un estándar abierto para tener acceso a todas las clases de datos. Mientras que ODBC se creó para tener acceso a bases de datos relacionales, OLE DB está diseñado para orígenes de datos relacionales y no relacionales, incluyendo las bases de datos ISAM/VSAM de los grandes sistemas y las bases de datos jerárquicas; almacenes de sistemas de archivos y correo electrónico; datos de texto, gráficos y geográficos, objetos de negocios personalizados, etc. OLE DB define una colección de interfaces de tipo COM que encapsulan varios servicios de los sistemas de administración de bases de datos. Estas interfaces permiten la creación de componentes de software que implementen dichos servicios. OLE DB tiene tres tipos de componentes: Proveedores de datos, receptores de datos y Componentes de servicio. La Figura 2.1 muestra un esquema de la arquitectura OLE DB.

Figura 2. 1 Arquitectura OLE DB.

27


Proveedores de datos (Data Providers) Los proveedores de datos son aplicaciones, como Microsoft SQL Server o Exchange, o bien componentes del sistema operativo, como un sistema de archivos, que dispone de datos a los que otras aplicaciones pueden necesitar tener acceso. Dichos proveedores de datos exponen interfaces OLE DB a las que los componentes de servicio o los receptores de datos pueden tener acceso de forma directa. Existe también un proveedor de OLE DB para ODBC, dicho proveedor pone los datos ODBC a disposición de los receptores de datos OLE DB.

Receptores de Datos (Data Consumers) Los receptores de datos son aplicaciones que utilizan los datos expuestos por los proveedores de datos. ADO es la interfaz de programación para utilizar OLE DB. Cualquier aplicación que utilice ADO es un receptor de datos OLE DB.

Componentes de Servicio (Service Components) Los componentes de servicio son componentes OLE DB que procesan y transportan datos. Entre dichos componentes se incluyen los procesadores de consultas y los motores de cursores. La arquitectura OLE DB está separada en componentes, de modo que no es preciso que los proveedores de datos tengan la capacidad inherente de proporcionar datos de forma comprensible para ADO. Estos componentes de servicio otorgan a ADO la capacidad de recibir datos OLE DB de proveedores que no ofrecen control de conjuntos de resultados o interpretación de consultas SQL de un modo intrínseco.

28


ActiveX Data Object (ADO) ADO se ha diseñado como una interfaz a nivel de aplicación, fácil de usar para cualquier proveedor de datos OLE DB, incluyendo bases de datos relacionales y no relacionales, sistemas de correo electrónico y de archivos, texto y gráficos, y objetos empresariales personalizados, así como orígenes de datos ODBC existentes. Prácticamente todos los datos disponibles en la empresa están disponibles mediante el uso de la tecnología de acceso a datos de ADO. ADO es fácil de utilizar, independiente del lenguaje, utiliza un tráfico de red mínimo y posee menos capas entre la aplicación cliente y el origen de datos (de manera que proporciona un acceso a datos ligero y de alto rendimiento). Las características generales de ADO son: ü ü ü ü ü ü ü ü ü ü

Fácil de utilizar. Alto rendimiento. Control de cursores mediante programación. Tipos complejos de cursores, incluyendo cursores de proceso por lotes y cursores de cliente y servidor. Capacidad de devolver múltiples conjuntos de resultados desde una única consulta. Ejecución de consulta síncrona, asíncrona o controlada por eventos. Objetos reutilizables y de propiedades modificables. Administración avanzada de caché de recordsets. Flexibilidad: funciona con tecnologías existentes de base de datos y con todos los proveedores OLE DB. Excelente detección de errores.

La semántica sencilla de ADO y su aplicación universal implica mínimo entrenamiento de los programadores, programación rápida de aplicaciones y bajo costo de mantenimiento.

Modelo de Objetos ADO El modelo de objetos de ADO define una colección de objetos programables que admiten el Modelo de Objeto Componente (COM) y Automatización OLE para aprovechar la tecnología denominada OLE DB. El modelo de objetos de ADO (cuando se compara con otros objetos de acceso a datos como RDO o DAO) es más plano (tiene menos objetos) y más sencillo de utilizar. El modelo de objetos ADO consta de tres componentes principales: el objeto Connection, el objeto Command y el objeto RecordSet, En la Figura 2.2 puede apreciar la relación que existe entre los objetos ADO.

29


Figura 2.2 Modelo de Objetos ADO. El modelo de objetos ADO se diferencia del los modelos de objetos RDO y DAO en que muchos de los objetos se pueden crear independientemente unos de otros. Por ejemplo, puede crear un objeto RecordSet sin crear primero de forma explicita un objeto Connection. ADO crea implícitamente el objeto Connection necesario. En el modelo de objetos de ADO hay siete objetos, como se describe a continuación: Objeto: Connection Mantiene información de conexión, el tipo de cursor, la cadena de conexión, el tiempo de espera de la consulta, el tiempo de espera de la conexión y la base de datos. Objeto: Command Mantiene información acerca de un comando, como una cadena de consulta, definiciones de parámetro, etcétera. El objeto Command es útil cuando desee definir parámetros de consultas ó ejecutar procedimientos almacenados que devuelva parámetros de resultados. Los objetos Command admiten varias propiedades para describir el tipo y el propósito de la consulta y para ayudar a ADO a optimizar la operación. Objeto: Recordset Un conjunto de filas devueltas de una consulta, que incluye un cursor en las filas. Puede abrir un objeto Recordset (es decir, ejecutar una consulta) sin tener que abrir de forma explícita un objeto Connection. Sin embargo, si crea un objeto Connection en primer lugar, puede abrir múltiples objetos Recordset en la misma conexión.

30

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Objeto: Error Contiene información ampliada acerca de condiciones de error producida por el proveedor de datos. Como una única instrucción puede generar dos o más errores, la colección Errors puede contener más de un objeto Error al mismo tiempo. Objeto: Field Contiene información acerca de una única columna de datos de un recordset. El objeto Recordset utiliza la colección Fields para que contenga a todos sus objetos Field. Esta información de Field incluye el tipo de datos, la precisión y la escala numérica. Objeto: Parameter Es un parámetro individual asociado a un objeto Command. El objeto Command utiliza la colección Parameters para que contenga a todos sus objetos Parameter. Los objetos Parameter de ADO se pueden generar automáticamente enviando consultas a la base de datos. Sin embargo, también puede generar esta colección mediante programación para mejorar el rendimiento en tiempo de ejecución. Objeto Property Una característica definida por el proveedor de un objeto ADO. Los objetos ADO tienen dos tipos de características: integradas y dinámicas. Las propiedades integradas son las que están implementadas en ADO y se encuentran disponibles para cualquier objeto nuevo de ADO. Las propiedades dinámicas están definidas por el proveedor de datos subyacente y aparecen en la colección Properties para el objeto de ADO apropiado. Por ejemplo, una propiedad puede indicar si un objeto Recordset admite transacciones o actualizaciones. Ésta es una de las principales características de ADO, que permite al proveedor de servicios de ADO presentar interfaces especiales.

31


Colecciones ADO Los objetos ADO se agrupan en colecciones, como se puede apreciar en la Figura 2.3.

Figura 2.3 Colecciones ADO. Errors La colección Errors contiene todos los objetos Error creados en respuesta a un único fallo relacionado con el proveedor. Parameters La colección Parameters contiene todos los objetos Parameter de un objeto Command. Fields La colección Fields contiene todos los objetos Field de un objeto Recordset. Properties La colección Properties contiene todos los objetos Property de una instancia específica de un objeto.

32


Cargar la Librería de Objetos ADO Para poder usar los objetos ADO en un proyecto de Visual Basic es necesario en primer lugar cargar la librería correspondiente, para lo cual debe seguir los siguientes pasos: 1. Inicie Visual Basic con un proyecto de tipo Estándar. 2. Del menú Proyecto ejecute el comando Referencias. 3. En el diálogo Referencias, seleccione la opción Microsoft Actives Data Object 2.0, (Como se muestra en la Figura 2.4) y luego haga clic en el botón Aceptar.

Figura 2.4 Librería de Objetos ADO. Ahora esta en condiciones de utilizar los objetos ADO en su proyecto.

33


Conexión con una Base de Datos A continuación tenemos un ejemplo típico para la conexión con una base de datos SQL Server.

Option Explicit Public cn As ADODB.Connection Public Sub Main() Dim adoErr As ADODB.Error Set cn = New ADODB.Connection On Error GoTo TrataError With cn .Provider = "SQLOLEDB" .ConnectionString = "Data Source=NombreDelServidor;" & _ "Initial Catalog=NombreDeLaBD;" & _ "User Id=LoginId;" & _ "Password=Password" .Open End With MsgBox "Conexión Conforme" MDIPrincipal.Show Exit Sub TrataError: Beep For Each adoErr In cn.Errors MsgBox adoErr.Description Next End Sub

Se asume que la variable pública será utilizada para que los otros objetos accedan a la base de datos.

34


Ejecución de Instrucciones Transact-SQL El objeto Connection permite ejecutar instrucciones Transact-SQL, como se ilustra a continuación. Para una instrucción que no retorna resultados

Conecction.Execute CommandText, RecordsAffected, Options

Para una instrucción que retorna un conjunto de resultados

Set RecordSet = Conecction.Execute( CommandText, RecordsAffected, Options )

Ejemplos Ilustrativos Insertar un nuevo vendedor

CmdSQL =

“Insert Into Vendedor( IdVendedor, ApeVendedor, “ & _ “NomVendedor, DirVendedor, TelVendedor ) “ & _ “Values( ‘V55555’, ‘Roman Sanchez’, ‘David’, “ & _ “‘Los Olivos’,‘534-4597’ )” Cn.Execute cmdSQL, Rows, adCmdText If Rows = 1 Then MsgBox “Proceso ejecutado correctamente” End If

Actualizar el stock de un artículo

CmdSQL = “Update Articulo ” & _ “Set Stock = 1200 “ & _ “Where IdArticulo = ‘LIC00001’” Cn.Execute cmdSQL, Rows, adCmdText If Rows = 1 Then MsgBox “Proceso ejecutado correctamente” End If

35

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Crear un ResordSet

Dim rs As ADODB.Recordset Dim cmdSQL As String cmdSQL = "Select * From Linea" Set rs = cn.Execute(cmdSQL) Set dbDatLinea.DataSource = rs

36


Objeto Command El objeto Command también permite ejecutar instrucciones Transact-SQL, la ventaja es que permite crear parámetros y pueden ser reutilizados. Creación de un objeto Command (Caso 1)

Dim cmd as New ADODB.Command

Creación de un objeto Command (Caso 2)

Dim cmd as ADODB.Command Set cmd = New ADODB.Command

Establecer las propiedades del objetos Command

cmd.ActiveConnection = cn cmd.CommandText = InstrucciónTransactSQL cmd.CommandType = TipoDeComando

Crear un Parámetro

Dim prm as ADODB.Parameter Set prm = cmd.CreateParameter( Name, Type, Direction, Size, Value ) cmd.Parameters.Append prm

Acceso a un Parámetro

cmd.Parameters(“NombreDelParametro”).Value

Ejecutar el comando que no retorna filas

cmd.Execute RecordsAffected, Parameters, Options

37

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Ejecutar un comando que retorna un conjunto de resultado

Set rs = cmd.Execute( RecordsAffected, Parameters, Options )

38


Manejo de Resultados Para el manejo de un conjunto de resultados debemos usar el objeto RecordSet, Crear un objeto RecordSet (Caso 1)

Dim rs As New ADODB.RecordSet

Crear un objeto RecordSet (Caso 2)

Dim rs As ADODB.RecordSet Set rs = New ADODB.RecordSet

Establecer las principales propiedades del RecordSet

Rs.ActiveConnection = cn Rs.Source = InstrucciónTransactSQL Rs.CursorType = TipoDeCursor Rs.CursorLocation = UbicaciónDelCursor Rs.LockType = TipoDeBloqueo

Abrir el RecordSet

rs.Open Source, ActiveConnection, CursorType, LockType, Options

Verificar el estado de un RecordSet

Select Case rs.State Case adStateClosed MsgBox “Esta Cerrado” Case adStateOpen MsgBox “Esta Abierto” Case adStateConnecting MsgBox “Esta conectándose” Case adStateExecuting MsgBox “Esta Ejecutando un Comando” Case adStateFetching MsgBox “Esta Cargando filas” End Select

39

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Acceso a los campos de un RecordSet

Rs!NombreDelCampo

Enlazar un campo con un control, por ejemplo TextBox

Set Text1.DataSource = rs Text1.DataField = “NombreDelCampo”

Desplazarnos por las filas de un RecordSet

Rs.MoveFirst Rs.MovePrevious Rs.MoveNext Rs.MoveLast

‘ ‘ ‘ ‘

Primera fila Fila anterior Fila Siguiente Ultima Fila

Cuando nos desplazamos por encima del primer registros, la propiedad BOF toma valor TRUE, y si nos desplazamos más haya del último registro la propiedad EOF toma valor TRUE. Verificar el estado de edición de un RecordSet

Select Case rs.EditMode Case adEditNone MsgBox “No Esta en Edición” Case adEditProgress MsgBox “El registro actual esta en edición” Case adEditAdd MsgBox “El registro actual es uno nuevo” Case adEditDelete MsgBox “El registro actual se ha eliminado” End Select

Agregar un nuevo registro

Rs.AddNew

40

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Grabar los cambios realizados

Rs.Update

Cancelar los cambios

Rs.CancelUpdate

Eliminar el registro actual

Rs.Delete

Cerrar un RecordSet

Rs.Close Set rs = Nothing

Manejo del puntero de registro El RecordSet tiene una propiedad llamada BookMark que es un puntero al registro actual, si deseamos guardar este valor en una variable, esta variable debe ser de tipo Variant. Esta propiedad es de lectura y escritura es tiempo de ejecución.

41


Objetos del Servidor Objetivos En este tercer modulo desarrollaremos los siguientes puntos: ü ü ü ü ü

Creación de procedimientos almacenados. Uso de parámetros de entrada y salida en un procedimiento almacenado. Uso de valor de retorno de un procedimiento almacenado. Creación de vistas. Criterios para el uso de vistas.

42


Procedimientos almacenados Un procedimiento almacenado es un objeto que se almacena en la base de datos, y que ejecuta una serie de instrucciones SQL cuando es invocado.

Ventajas de los procedimientos almacenados ü

La lógica de la aplicación puede ser compartida con otras aplicaciones. Los procedimientos almacenados pueden encapsular la lógica de negocios en una sola ubicación, y estar disponible para muchas aplicaciones.

ü

Proporciona un mecanismo de seguridad. Se puede otorgar a un usuario permiso para ejecutar un procedimiento almacenado aun cuando no tenga permiso para acceder a las tablas referenciadas por el procedimiento almacenado.

ü

Mejora el rendimiento del sistema y reduce el tráfico en la red. El uso de lógica condicional determina qué sentencias se ejecutarán y cuáles no.

Creación de procedimientos almacenados Procedimiento que no recibe ni devuelve parámetros

CREATE PROCEDURE nombre_procedimiento AS instrucción_sql

Procedimiento que recibe parámetros

CREATE PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ = valor ] , @parámetro2 tipo_dato [ = valor ] , ... AS instrucción_sql

Procedimiento que recibe y entrega parámetros

CREATE PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ = valor ] , @parámetro2 tipo_dato [ = valor ] OUTPUT , ... AS instrucción_sql

43


ü

Un procedimiento almacenado puede hacer referencia a tablas, vistas y otros procedimientos almacenados, así como a tablas temporales. Estas últimas solo existen mientras el procedimiento se está ejecutando.

ü

La sentencia CREATE PROCEDURE no se puede combinar con otras sentencias SQL en el mismo batch.

ü

En un procedimiento almacenado no se puede ejecutar: CREATE DEFAULT, CREATE PROCEDURE, CREATE RULE, CREATE TRIGGER y CREATE VIEW.

ü

Para crear un procedimiento almacenado se debe ser miembro de alguno de los siguientes roles: sysadmin, db_owner, o db_ddladmin, o debe tener el permiso para crear procedimientos.

Obtención de la definición de un procedimiento almacenado Tabla sistema sysobjects

del Almacena

sysdepends

syscomments

Procedimiento

Nombre del procedimiento almacenado Nombre de los objetos dependientes del procedimiento almacenado Sentencia que definió el procedimiento almacenado

44

sp_help [ nombre_procedimiento ] sp_depends nombre_procedimiento sp_helptext nombre_procedimiento


Modificación de un procedimiento almacenado Para modificar un procedimiento almacenado conservando su asignación de permisos, ejecute la sentencia ALTER PROCEDURE. La definición previa del procedimiento será reemplazada por la definición establecida en ALTER PROCEDURE.

ALTER PROCEDURE nombre_procedimiento [ @parámetro1 tipo_dato [ = valor ] , @parámetro2 tipo_dato [ = valor ] OUTPUT , ... ] AS instrucción_sql

Eliminación de un procedimiento almacenado DROP PROCEDURE nombre_procedimiento

Ejecución de un procedimiento almacenado Procedimiento que no recibe ni devuelve parámetros

CREATE PROCEDURE nombre_procedimiento AS instrucción_sql EXECUTE nombre_procedimiento

Procedimiento que recibe parámetros

CREATE PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ = valor ] , @parámetro2 tipo_dato [ = valor ] , ... AS instrucción_sql EXECUTE nombre_procedimiento

parámetro1 , parámetro2 , ...

45

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Procedimiento que recibe y entrega parámetros

CREATE PROCEDURE nombre_procedimiento @parámetro1 tipo_dato [ = valor ] , @parámetro2 tipo_dato [ = valor ] OUTPUT , ... AS instrucción_sql EXECUTE nombre_procedimiento @var_salida OUTPUT , ...

parámetro1 ,

J En www.LibrosDigitales.NET, encontrará manuales sobre éste tema.

46


Estado de un procedimiento almacenado Un procedimiento almacenado tiene un valor de estado, denominado código de retorno, para indicar el estado de su ejecución. Se especifica el código de retorno para un procedimiento mediante la instrucción RETURN. Al igual que con los parámetros OUTPUT, debe guardar el código de retorno en una variable cuando se ejecute el procedimiento almacenado para utilizar su valor en el programa que realiza la llamada. Por ejemplo, la variable @result del tipo int se utiliza para almacenar el código de retorno del procedimiento almacenado mi_procedimiento:

DECLARE @result int EXECUTE @result = mi_procedimiento Los códigos de retorno suelen utilizarse en los bloques de control de flujo dentro de los procedimientos almacenados con el fin de establecer el valor del código de retorno para cada situación de error posible. Puede utilizar la variable @@ERROR después de una instrucción Transact-SQL para detectar si se ha producido un error durante la ejecución de la instrucción. Ejemplo Ilustrativo Procedimiento Ejemplo

CREATE PROCEDURE usp_ejemplo @valor1 smallint, @valor2 smallint, @resultado smallint OUTPUT AS If @valor1 is null or @valor2 is null return -1 SET @resultado = @valor1 * @valor2 return 0 GO

Prueba 01

Declare @Ret Int, @Prod SmallInt Exec @Ret = usp_ejemplo 56, 80, @Prod OutPut Select 'Código de Estado' = @Ret, Producto = @Prod Go'El resultado es ' , @salida GO

47

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server El resultado de esta prueba es: Código de Estado Producto ---------------- -------0

4480

(1 filas afectadas)

Prueba 02

Declare @Ret Int, @Prod SmallInt Exec @Ret = usp_ejemplo Null, 80, @Prod OutPut Select 'Código de Estado' = @Ret, Producto = @Prod Go

El resultado de esta prueba es: Código de Estado Producto ---------------- --------1

NULL

(1 filas afectadas)

48


Ejecutar un procedimiento desde Visual Basic Para ejecutar un procedimiento almacenado debemos utilizar un objeto Command, y si el procedimiento tiene parámetros debemos agregarle objetos de tipo Parameter al objeto Command; uno por cada parámetro del procedimiento.

Ejemplo Ilustrativo Como ejemplo ilustrativo crearemos un formulario que permita ejecutar el procedimiento usp_ejemplo. Formulario Utilizado El formulario que utilizaremos es el que se muestra en la siguiente figura:

El nombre de los controles es: Control TxtN1 TxtN2 TxtProd CmdCalcular CmdLimpiar CmdCerrar

Descripción Cuadro de texto para ingresar el primer número. Cuadro de texto para ingresar el segundo número. Cuadro de texto para el resultado. Botón de comando que ejecuta el procedimiento almacenado. Botón de comando que limpia los controles. Botón de comando que cierra el procedimiento.

49

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Ejecución del Procedimiento Almacenado El procedimiento almacenado es ejecutado cuando el usuario hace clic en el botón calcular, el script de este botón es el siguiente:

Private Sub cmdEjecutar_Click() On Error GoTo TrataError Dim cmd As ADODB.Command Dim prm As ADODB.Parameter ' Creamos en Objeto Command Set cmd = New ADODB.Command With cmd .ActiveConnection = cn .CommandText = "usp_Ejemplo" .CommandType = adCmdStoredProc End With ' Creamos los parámetros Set prm = cmd.CreateParameter("Ret", adInteger, adParamReturnValue) cmd.Parameters.Append prm Set prm = cmd.CreateParameter("N1", adSmallInt, adParamInput) cmd.Parameters.Append prm Set prm = cmd.CreateParameter("N2", adSmallInt, adParamInput) cmd.Parameters.Append prm Set prm = cmd.CreateParameter("Prod", adSmallInt, adParamOutput) cmd.Parameters.Append prm ' Asignar Datos a los parametros cmd.Parameters("N1").Value = txtN1.Text cmd.Parameters("N2").Value = txtN2.Text ' Ejecutar el Procedimiento cmd.Execute ' Verificar el Estado de la Ejecución If cmd.Parameters("Ret").Value = 0 Then txtProd.Text = cmd.Parameters("Prod").Value Else MsgBox "Falló el Procedimiento", vbOKOnly + vbCritical, "Error" End If ' Destruir el objeto Command Set cmd = Nothing Exit Sub TrataError: MsgBox Err.Description, vbOKOnly + vbCritical, "Error" End Sub

J Este y el resto de programas se encuentran en www.LibrosDigitales.NET.

50


Vistas Es un objeto que almacena una consulta predefinida y que proporciona un modo alternativo de visualización de datos sin tener que redefinir la consulta.

CREATE VIEW v_Con_Empresa(IdEmpresa,NomEmpresa,Direccion,RUC, Telefono,Contacto,Cliente,Proveedor) AS SELECT IdEmpresa,NomEmpresa,DirEmpresa,RUC,TelEmpresa,Contacto, CASE Cliente WHEN 1 THEN 'Si' WHEN 0 THEN 'No' ELSE '' END, CASE Proveedor WHEN 1 THEN 'Si' WHEN 0 THEN 'No' ELSE '' END FROM Empresa GO

Para ejecutar la vista:

SELECT * FROM v_con_Empresa Una vista puede incluir: ü ü ü ü ü

Un subconjunto de filas o columnas de una tabla La unión de dos o mas tablas Un join de dos o mas tablas Un resumen estadístico de una o mas tablas Un subconjunto de otra vista, o combinación de vistas y tablas.

Ventajas de las vistas ü ü ü

El usuario accede a la data importante o apropiada para él. Limita el acceso a datos sensibles. Oculta la complejidad del modelo de datos. Un join de múltiples tablas se convierte en un simple SELECT para el usuario. Desde el punto de vista del usuario, una vista es una "tabla" pues puede ejecutar en ella todas las operaciones de datos: SELECT, INSERT, UPDATE y DELETE.

51


Creación de vistas

CREATE VIEW nombre_vista [ ( lista_columnas ) ] [ WITH ENCRYPTION ] AS instrucción_select [ WITH CHECK OPTION ] Las siguientes restricciones se aplican a la creación de vistas: ü ü ü

No se puede definir una vista con ORDER BY, COMPUTE, COMPUTE BY o SELECT INTO. No pueden hacer referencia a tablas temporales. No pueden hacer referencia a mas de 1024 columnas.

Ejemplo Ilustrativo

CREATE VIEW v_Rep_Articulo(Linea,IdArticulo,DesArticulo,Unidad, Stock, PreCosto,Dscto,PreVenta) AS SELECT L.DesLinea, A.IdArticulo, A.DesArticulo, U.DesUnidad, A.Stock, A.PreCosto, A.Dscto, A.PreVenta FROM Linea L INNER JOIN Articulo A ON L.IdLinea = A.IdLinea INNER JOIN Unidad U ON A.IdUnidad = U.IdUnidad GO

Crea una vista de nombre v_rep_Articulo en la que se combina datos de las tablas Linea, Articulo y Unidad. El resultado de esta vista podría utilizarse en una consulta o un reporte.

Obtención de la definición de una vista Tabla sistema sysobjects sysdepends

de Almacena

Procedimiento

syscomments

Nombre de la vista Nombre de los objetos dependientes de la vista Sentencia que definió la vista

syscolumns

Columnas definidas en la vista

52

sp_help [ nombre_vista ] sp_depends nombre_vista sp_helptext nombre_vista sp_columns nombre_vista


Modificación de la definición de una vista ALTER VIEW nombre_vista AS nueva_sentencia_select

Eliminación de una vista DROP VIEW nombre_vista

Ocultando la definición de una vista Ejecute CREATE VIEW con la opción WITH ENCRYPTION.

Modificación de datos a través de vistas Desde el punto de vista del usuario, una vista es una "tabla" ya que él puede ejecutar sobre la vista las sentencias SELECT, INSERT, UPDATE y DELETE. Estas sentencias ejecutadas sobre la vista afectan a las tablas dependientes de ella. Deben tenerse en cuenta las siguientes consideraciones al momento de crear las vistas: ü ü ü ü

La modificación no puede afectar a más de una de las tablas dependientes. Las vistas con columnas computadas deben ser de solo lectura ya que producen error cuando se trata de ejecutar modificaciones a través de ellas. Las columnas no nulas que no son referenciadas en la vista pueden producir errores cuando se ejecuta una modificación a través de la vista. Si el SELECT asociado a la vista ha sido definido con una cláusula WHERE, el uso de la opción WITH CHECK OPTION al momento de crear la vista hará que las modificaciones que se hagan a través de ella respeten el criterio del WHERE.

53


Ejecutar una Vista desde Visual Basic Desde una aplicación cliente veremos una vista como si fuera una tabla, por lo tanto debemos invocarla en una instrucción SELECT, como se hace con cualquier otra tabla.

Ejemplo Ilustrativo En este ejemplo tenemos un control DataList con un listado de las líneas, donde el usuario al seleccionar una de ellas se muestra sus respectivos artículos en un control DataGrid, como se muestra en el siguiente gráfico:

El nombre de los controles es: Control DBLstLinea

Descripción Control DataList donde se muestra todas las líneas que se encuentran grabadas en la tabla Linea. DBGrdProducto Control DataGrid donde se muestra los artículos de la línea seleccionada en el control DataList.

54

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Variables del Formulario

Option Explicit Private rsLinea As New ADODB.Recordset Private rsArticulo As New ADODB.Recordset

Programar el Formulario En el evento Load del formulario cargamos el control DBLstLinea.

Private Sub Form_Load() With rsLinea .ActiveConnection = cn .CursorType = adOpenStatic .CursorLocation = adUseClient .Open "Select DesLinea From Linea" End With Set DBLstLinea.RowSource = rsLinea DBLstLinea.ListField = "DesLinea" DBLstLinea.BoundColumn = "DesLinea" End Sub

J Es importante sus opiniones y sugerencias para mejorar el contenido y poder remitirles la siguiente entrega, hágalo en www.LibrosDigitales.NET.

55

Aplicaciones Cliente-Servidor con Visual Basic y SQL Server Programar el control DBLstLinea Cuando el usuario selecciona una línea correspondientes en el control DBGrdArticulo.

se

deben

cargar

los

artículos

Private Sub DBLstLinea_Click() If rsArticulo.State = adStateOpen Then rsArticulo.Close End If With rsArticulo .ActiveConnection = cn .CursorLocation = adUseClient .CursorType = adOpenStatic .Open "Select * From v_rep_articulo " & _ "Where Linea = '" & Trim(DBLstLinea.BoundText) & "'" End With Set DBGrdArticulo.DataSource = rsArticulo End Sub

J Este y los otros programas los puede bajar de www.LibrosDigitales.NET.

56


Próxima Entrega

Edición 1.1 Dentro de una semana Prohibida la reproducción total o parcial Sin nuestro consentimiento Derechos de copia reservados www.LibrosDigitales.NET

57

Visual Basic y SQL Server

Recommend Documents