Aplicaciones de Bases de Datos con Delphi - II

Transcripción

1 Guías técnicas Grupo Danysoft: Aplicaciones de Bases de Datos con Delphi - II Equipo Grupo Danysoft junio de (902)

2 Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de datos con Delphi Este documento se ha realizado utilizando Doc-To-Help, distribuido por : Danysoft Internacional Avda de España Alcobendas Madrid Tfno Fax danysoft@danysoft.com - Página 2/7

3 Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de Datos con Delphi Aplicaciones de bases de datos con Delphi Una estrategia para su desarrollo (2da. entrega) En la primera entrega vimos como los componentes ClientDataSet y DataSetProvider nos permiten separar la lógica de datos de la lógica de acceso a datos. También vimos cómo algunas características de estos componentes hacen más fácil la resolución de actualizaciones incluso en escenarios complejos como el de las relaciones maestro/detalle. En todos los casos no sólo no tenemos que preocuparnos por la generación de las sentencias SQL de INSERT, DELETE y UPDATE ya que el componente DataSetProvider se encarga de generarlas por nosotros. Tampoco tenemos que preocuparnos por el orden en el que debemos resolver las actualizaciones sobre todo en el caso de relaciones maestro/detalle ya que el DataSetProvider sabe muy bien cómo hacer su trabajo. Cuando resolvemos las actualizaciones a dos tablas que mantienen una relación maestro/detalle entre sí, el orden en el que las resolvemos depende del tipo de actualización. Por ejemplo, si estamos insertando una orden, entonces debemos actualizar primero la tabla maestro (Orders) y luego la tabla detalle (Items). Si por el contrario estamos eliminando una orden, debemos eliminar primero él o los registros del detalle (Items) y luego el registro del maestro (Orders). El proceso de resolución de actualizaciones La resolución de actualizaciones es tarea del componente DataSetProvider. Podemos personalizar este proceso ya sea modificando aspectos generales por medio de propiedades o escribiendo nuestro propio proceso de resolución de actualizaciones. UpdateMode La propiedad UpdateMode del DataSetProvider nos permite controlar la generación de las sentencias SQL de DELETE y UPDATE. Cuando eliminamos o modificamos un registro debemos proveer información suficiente para localizar el registro en cuestión. Esto lo hacemos por medio de la cláusula WHERE. Esta propiedad controla precisamente qué campos deben ser incluidos en la cláusula WHERE generada. El valor upwhereall incluye todos los - Página 3/7

4 Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de datos con Delphi campos. El valor upwherechanged incluye sólo los campos modificados y los campos que forman la clave primaria. El valor upwherekeyonly incluye sólo los campos que forman la clave primaria. Los campos incluidos en la cláusula WHERE tienen impacto sobre el control de concurrencia y el rendimiento. En un entorno de varios usuarios concurrentes es posible que dos usuarios modifiquen el mismo registro al mismo tiempo. Para comprender bien este problema debemos tener bien claro el proceso completo. Un usuario abre un formulario ante lo que nuestra aplicación obtiene datos de la base de datos. Como el ClientDataSet mantiene los cambios en memoria es posible que otro usuario obtenga los mismos datos, los modifique y aplique las modificaciones antes que el primer usuario lo haga. Aquí es donde debemos controlar la concurrencia. Al incluir todos los campos en la cláusula WHERE, el DataSetProvider utiliza los valores originales para localizar el registro en cuestión. Esto significa que si otro usuario ha modificado el registro luego de que el primer usuario los haya obtenido y antes de que haya aplicado los cambios, el registro no será localizado y la actualización del primer usuario fallará. Esto es válido para todos los campos salvo para los campos BLOB. En este caso no tenemos forma de detectar si otro usuario ha modificado el mismo registro. Dependiendo del nivel de control de concurrencia que necesitemos implementar podemos utilizar el valor upwhereall (alto), upwherechanged (medio) o upwherekeyonly (bajo). Si la tabla que estamos actualizando tiene muchos campos está claro que el valor upwherekeyonly tendrá mejor rendimiento que upwhereall. No es lo mismo hacer una comparación que cincuenta. ProviderFlags Para resolver ambos problemas a la vez, es decir, implementar un alto control de concurrencia y obtener el mejor rendimiento posible al mismo tiempo, lo más común es crear un campo que actúe como bandera y nos permita determinar si el registro ha sido modificado con sólo evaluar su valor. Cada vez que insertamos, eliminamos o modificamos un registro, le asignamos un valor nuevo a este campo. Luego, sólo deberíamos incluir en la cláusula WHERE este campo y los campos que forman la clave primaria. Para ello debemos utilizar la propiedad ProviderFlags de cada uno de los campos del DataSet utilizado por el DataSetProvider para obtener datos. La propiedad ProviderFlags es un conjunto de valores de los cuales en este caso nos interesa sólo pfinwhere. El valor True le indica al DataSetProvider que el campo debe ser incluido en la cláusula WHERE. El valor False indica que no lo debe incluir. - Página 4/7

5 Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de Datos con Delphi Eventos El componente DataSetProvider genera una serie de eventos que nos permiten personalizar el proceso de actualización. El siguiente gráfico muestra la secuencia de eventos que genera el DataSetProvider: El evento BeforeApplyUpdates se genera antes de comenzar el proceso de actualización. Es importante tener en cuenta que el proceso de actualización puede implicar la actualización de varios registros y varias tablas. Podemos escribir código en este evento para realizar tareas previas al inicio del proceso de actualización como por ejemplo asignarle un nuevo valor al campo utilizado como bandera para verificar si un registro ha sido modificado por otro usuario. El evento BeforeUpdateRecord se genera antes de actualizar cada registro. En relaciones maestro/detalle este evento se genera para cada registro del maestro y para cada registro del detalle. En este evento podemos personalizar totalmente el proceso de actualización e informarle al DataSetProvider por medio del parámetro Applied que nos hemos encargado del registro y que no debe resolver su actualización. El evento AfterUpdateRecord se genera después de actualizar cada registro. En este evento podemos realizar tareas complementarias como actualizar otras tablas. Por ejemplo, podríamos actualizar el campo OnOrder de la tabla productos (Parts) para cada ítem (Items) de una orden (Orders). En este evento no tenemos que preocuparnos por controlar transacciones ya que el DataSetProvider se encarga de hacerlo por nosotros. Incluso podemos llamar al método ApplyUpdates de otros ClientDataSet que el DataSetProvider seguirá teniendo cuidado de controlar las transacciones. Veamos en detalle como sería la secuencia. En el caso de una nueva orden, se inicia una transacción al insertar el registro maestro. Los registro del detalle son insertado en el contexto de la misma transacción del registro maestro y si actualizamos otras tablas en este evento todo se hará en el contexto de la misma transacción. Si ocurre un error al actualizar alguna de las tablas se generará una excepción y la transacción será finalizada cancelando todos los cambios realizados. - Página 5/7

6 Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de datos con Delphi Consultas complejas Otro problema que podemos resolver con facilidad en el componente ClientDataSet es la utilización de consultas complejas o la actualización de vistas de sólo lectura. La siguiente sentencia SQL podría resultar en un conjunto de sólo lectura: SELECT Items.OrderNo, Items.ItemNo, Items.PartNo, Parts.Description, Parts.ListPrice, Items.Qty, Items.Discount FROM Items INNER JOIN Parts ON (Items.PartNo = Parts.PartNo) WHERE Items.OrderNo = :OrderNo Con los componentes ClientDataSet y DataSetProvider, no. Es más, en el ClientDataSet podremos asignarles valores a los campos Description y ListPrice sin ninguna dificultad simplificando la creación de una interface de usuario amigable. Sin embargo, para que el DataSetProvider pueda resolver las actualizaciones a este conjunto de datos debemos hacer algo más. La propiedad ProviderFlags de los campos también nos permiten resolver situaciones como estás. En este caso no queremos que la sentencia SQL generada automáticamente por el DataSetProvider contenga los campos Description y ListPrice ya que estos campos no forman parte de la tabla Items. Lo que debemos hacer entonces es asignarle a la propiedad ProvierFlags.pfInUpdate el valor False. Esto le indica al DataSetProvider que estos campos no deben ser incluidos en las sentencias SQL de INSERT y UPDATE. Claro que también debemos asignarle el valor False a la propiedad ProviderFlags.pfInWhere ya que tampoco deben ser incluidos en la cláusula WHERE. OnGetTableName En ocasiones el componente DataSetProvider no puede determinar el nombre de la tabla que debe actualizar. Para estas situaciones genera el evento OnGetTableName en el cual debemos proveer el nombre de la tabla que debe ser actualizada en el parámetro TableName. En una sentencia SQL como la anterior los componentes de acceso a datos basados en BDE y en ADO pueden determinar el nombre de la tabla que debe ser actualizada. Sin embargo, los componentes de acceso a datos basados en InterBase Express no pueden. En cualquier caso, si el DataSetProvider no puede determinar el nombre de la tabla que debe actualizar y no proveemos un manejador para el evento OnGetTableName, genera un mensaje de error indicando que no puede determinar el nombre de la tabla que debe actualizar. Campos persistentes El uso de campos persistentes nos ofrece la ventaja de trabajar con los objetos TField de manera visual en tiempo de diseño. Podemos asignarles valores a sus propiedades y manejadores de eventos para sus eventos. Sin embargo hay ocasiones en las cuales no podremos utilizar campos persistentes debido a que el tipo de objeto descendiente de la clase TField puede variar de una base de datos a otra o de una tecnología de acceso a datos a otra. Por ejemplo, utilizando el BDE para acceder a tablas Paradox - Página 6/7

7 Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de Datos con Delphi obtendremos un objeto de tipo TStringField para el campo Description de la sentencia SQL anterior. Utilizando ADO para acceder a tablas MSAccess obtendremos un objeto de tipo TWideStringField para el mismo campo. Si en el ClientDataSet hemos creado campos persistentes entonces no será posible cambiar de una base de datos a otra y de una tecnología de acceso a datos a otra con mucha facilidad. La única solución es no crear campos persistentes y asignar valores a las propiedades y manejadores de eventos a los eventos de los campos por código en tiempo de ejecución. Es mucho más incómodo trabajar de esta forma pero es la única solución que nos dará libertad para elegir la base de datos y la tecnología de acceso a datos utilizada. En lo que respecta a las propiedades de los campos, podemos crear campos persistentes en los DataSet utilizados por el DataSetProvider para obtener los datos e indicarle al DataSetProvider que queremos que propague estos valores al ClientDataSet. De esta forma podríamos resolver parte del problema y sólo nos restaría asignar manejadores de eventos por código. La propiedad Options.poIncFieldProps del DataSetProvider nos permite controlar este comportamiento. Conclusiones Hemos visto las características del componente DataSetProvider para el manejo del proceso de actualización. Nos ofrece la ventaja de generar automáticamente las sentencias SQL de actualización y ejecutarlas en el orden correcto. También nos permite personalizar el proceso de actualización modificándolo en todo o en parte. Además, las sentencias SELECT complejas o las vistas de sólo lectura no son un problema para el DataSetProvider. En la próxima entrega veremos cómo gestionar la resolución de errores de actualización. Más información En el curso de tecnicas avanzadas de programación Delphi, del cual puede ver más información y contenidos en o contactando con formación@danysoft.com - Página 7/7