Parece un título un tanto extraño pero harto de buscar el más apropiado, o al menos el que me parecía mas ingenioso, he acabado escogiendo el mas evidente en la historia que narra esta entrada.
Este es el protagonista:
Como podeis ver, se trata una notificacion de error, que es lo que se puede desprender de la imagen.
Un dato mas: la aplicación utiliza AdoExpress y DataSnap, accediendo a un servidor de SQL Server.
Con ese supuesto, quizás la intuición nos llevaría a suponer que el problema surge en una actualizacion, es decir, en un Update (más que nada por la caché de datos y el sistema de conciliacion). O quizás a causa de un trigger, un disparador del gestor de datos, que ha podido alterar el contenido del registro (se supone que lanzado desde otro proceso). O la mas probable, a causa de la interacción de otro usuario, que ha decidido caprichosamente modificar la misma ficha de un cliente o de un artículo, suponiendo que fuera este el cambio. Son ideas que a uno le pueden venir a la mente intentando encontrar un sentido al mensaje de error.
El problema es que no era una actualización sino un borrado (ese dato ya lo aporto ahora) y eso ya es un poco mas dificil de digerir. Manuel trataba de borrar la ficha de un cliente, en una de esas tardes en las que parte del tiempo se nos va en la depuración del codigo que hemos escrito. Y la aplicación siempre se obstinaba en enviarnos un mensaje que tenía poco sentido o ninguno. Porque entre otras cosas, solo quedabamos en la empresa a esas horas el y yo, y no había nada que pudiera afectar al registro desde el momento en el que el presionaba el ok del formulario hasta que se rascaba la cabeza.
Bueno. Cierto es que tengo que admitir que tenía poco sentido porque pensabamos, lo habiamos leído y eramos capaces de perjurar que era así, que si optabamos por un modo de actualización upWhereChanged en nuestro proveedor TDataSetProvider, toda vez que en una sentiencia de actualizacion iban a compararse los campos marcados como clave primaria y aquellos que habían sido modificados, en una sentencia de borrado tan solo iban a compararse los que contenian el flag pfInKey, o lo que es lo mismo, los que el usuario había marcado como clave primaria.
Ese es el problema… ¡uno da por supuesto cosas que no siempre son verdad!…
Cuenta una leyenta urbana que en el presidio de Ula-Ula los presos esperaban con paciencia en el corredor de la muerte. Uno de ellos, el protagonista de esta historia se llamaba Palomo Confiado. Y cuentan además que habían pasado los años y desde su llegada al penal, ya nunca habían podido ejecutar a nadie. El director del presidio tenía una regla inmutable: Para que una ejecución se llevara a efecto, tenía que eliminar la ficha del recluso de su aplicación. Así que cada vez que tenía que cumplir con su cargo y enviar un recluso al otro mundo, ejecutaba su aplicación y tras localizar la ficha del reo, simplemente bastaba pulsar el botón de suprimir y se ponía en marcha el mecanismo que iniciaba el tramite de la ejecución.
Hasta la llegada de Palomo al presidio todo funcionaba bien. Los presos iban desfilando por el corredor de la muerte, animando las aburridas tardes de la ciudad. Pero… siempre hay un pero. Palomo Confiado cambió todo de la noche a la mañana porque había nacido con buena estrella.
Un día le dijo Palomo al programador del presidio, que por cierto, también programaba en Delphi con AdoExresss y DataSnap:
-Para que quieres pasar trabajo asignando la fecha de alta cada vez que ingresa un nuevo preso. No. No te preocupes que de eso ya se encarga tu gestor de datos. Olvidate de asignar el valor desde Delphi y limítate a poner como valor por defecto el retorno de la función GetDate(), en el campo FECHAALTA de tu tabla de PRESOS.
Aquella tarde el programador siguió el consejo de Palomo y desde aquel momento ya no pudieron ejecutar a nadie más… 😉
Delphi Básico 
Comentarios recientes