FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Corregir un generador
Hola, estoy utilizando un generador como parte de la clave primaria de una tabla y me funciona bien.
El problema es que si se borra un registro y este es el último, me gustaría poder corregir el generador para que en el siguiente nuevo le asigne el mismo número (es decir no se pierda el número de secuencia). Vale, esto es fácil de hacer, basta con poner el generador al número correcto y ya está. Sin embargo, la cosa no es tan simple cuando estamos en un entorno multiusuario, ya que mientras comparo el valor actual del generador con el número del registro que borro, es posible que otro usuario haga una solicitud de valor del generador, y entonces el resultado final quedaría erróneo. He pensado en realizar la comprobación en el evento after delete, y si el registro que se borró es el último, que sea ahí donde se ajuste el contador, pero no estoy seguro de que ocurriría si diese la casualidad de que durante la ejecucición de ese trigger, otro usuario solicitase un número. Las posibilidades de que sea en el mismo momento son pocos, pero la ley de murphy seguro que se aplica. ¿Que me podéis sugerir? Salu2. |
#2
|
||||
|
||||
Hola,
Cita:
Una alternativa es olvidarse de los generadores y crear un recurso propio dentro de la base de datos (por ejemplo una tabla de contadores) para asignar los valores en secuencia. Es importante asegurar que cada vez que se utiliza la tabla de contadores, se haga de forma exclusiva (para escritura, ya que para lectura no es posible) , mediante el bloqueo del contador en cuestión y gestionar la posible duplicación de valores (índices únicos, claves primarias, triggers, ...). Saludos. Última edición por kinobi fecha: 24-07-2003 a las 14:02:34. |
#3
|
|||
|
|||
Gracias por la respuesta.
Estoy de acuerdo contigo en lo que comentas, pero me parecen más las ventajas de usar un generador frente a tener que desarrollar un contador con sus bloqueos, y por eso me decidí a usarlos a pesar de todo. ¿Y lo que comentaba de hacerlo en el trigger del evento after delete?. Creo que no se puede garantizar que el trigger se ejecute completamente sin que otra instrucción sql se cuele por medio de la ejecución, ¿o sí? Salu2. |
#4
|
||||
|
||||
Cita:
En resumen, fueron diseñados con la idea de proporcionar un mecanismo que asegurara valores únicos, pero no para garantizar la secuencia (sin huecos). Saludos. Última edición por kinobi fecha: 24-07-2003 a las 14:39:28. |
#5
|
|||
|
|||
Yo te sugiero lo tener la siguiente estructura :
una tabla de FACTURAS (por ejemplo) con los campos : FACTURA INTEGER NOT NULL NUMFACTURA INTEGER NOT NULL Creas la clave primaria usando el fichero FACTURA Define un UNIQUE para el Campo NUMFACTURA Creas dos generadores uno cada para campo El generador del campo FACTURA lo usas desde la aplicacion, para asignarle un valor. Pero el generador para NUMFACTURA usalo en el Trigger de la tabla BEFOREINSERT y ahi le introduces el NUMFACTURA. Y justamente es ahi donde podrias comprobar si hay huecos o asignarle un valor nuevo desde el generador. De esa manera te aseguras que no habra huecos entre registros y los huecos que habra solo sera a nivel del campo usado como clave primaria. Yo en caso de mantenimentos de FACTURAS con cabecera y detalle lo que hago es generar el campo NUMFACTURA en el Trigger BEFOREUPDATE atraves de un campo de control (Booleano) para indicar cuando quiero que realmente me genere el numero de factura (NUMFACTURA). De esta manera puedo grabar la cabecera para introducir lineas de detalle, sin problemas de FOREIGNKEY's y cuando finalmente el usuario da por hecha la factura (BOTON OK,je je ), justamente es ese momento cuando se genera el NUMFACTURA. En un sistema multiusuario me asegura la continuidad de numeracion y no se perderan numeraciones si un usuario cancela (BOTON CANCEL, jeje) despues de haber tenido que grabar la cabecera y algunas lineas en el proceso de "añadir una factura nueva". Vaya rollo solte!!!! jejejeje No se hasta me ha parecido bonito asi tan bien explicado, espero que parezca bonito e interesante, sino puee naa!! Espero que te sirva y saludos a todos !!!!!! |
#6
|
||||
|
||||
Hola,
Cita:
Como hemos comentado en el hilo, basar una secuencia sin huecos en el uso de generadores es imposible en un entorno multi-transaccional como InterBase, a no ser que se recurra a procesos auxiliares (externos a los propios generadores); de ahí que no comprenda cuál es la mejora de añadir un segundo generador. Saludos. |
#7
|
|||
|
|||
Hola:
Es posible que lo que os diga sea una tontería, pero yo el sistema que explico a mis alumnos para conseguir secuencias de números de facturas sin huecos es, sencillamente, no llamar al generador hasta que toda la información está disponible (cabecera y líneas de la factura) y se haya confirmado la ejecución de la factura. Una vez que ese proceso se ha realizado, no se puede eliminar esa factura; si se desea eliminar del sistema habrá que insertar una factura de abono (idéntica a la realizada pero con las cantidades negativas). El único problema que puede presentar es un fallo en la BD tras haber creado la cabecera de la factura y no haber metido todavía las líneas, ya que habría que hacer un rollback (y el generador no se entera). Para ello, si se produce ese fallo, como el nº de la factura ya está reservado, se reintenta la inserción de cabecera y líneas sin llamar al generador, usando ese número. Hasta donde lo he probado, funciona perfectamente en entornos multiusuario. Si alguien cree que puede fallar le agradecería que lo comentara en este foro Un saludo Nacho |
#8
|
||||
|
||||
Hola,
Cita:
Saludos. Última edición por kinobi fecha: 25-07-2003 a las 10:40:40. |
#9
|
|||
|
|||
Hola,
está claro que no se puede mantener una secuencia sin huecos, ya que en el momento en el que el usuario borre un registro antiguo, ya quedará el hueco. Yo no pretendo que el programa busque el hueco y el próximo registro que se inserte, lo haga usando ese hueco. Me quería centrar en un problema concreto, que es el borrado del último registro que añadí, es decir, ya tengo el número de la secuencia y el registro se añadió, pero ahora lo borro. Me gustaría ajustar la secuencia, pero claro, en ese momento puede otro usuario pedir un número y ahí está el problema. No tiene solución sin poder bloquear el generador mientras se actualiza. Como esto no se puede hacer, pues tendré que meter código o bien ignorar el problema y que no se ajuste (esto es lo mejor, lo más sencillo, lo más rápido, pero no le gusta a mi jefe ) Salu2. |
#10
|
|||
|
|||
Cita:
Cita:
select max(campo) + 1 from tabla y calcularlo siempre en el BeforePost de la tabla mirando que sea una insercion (o bien por medio de un trigger) |
#11
|
||||
|
||||
Hola Cadetill,
Cita:
Y es un artificio porque es artificial crear una factura con importes (o cantidades) negativas. Nadie vende -1000 Kilos de manzanas, ni tampoco vende 1 Kilo de manzanas a -2 Euros. Que sea un artificio no significa que no pueda ser habitual y también correcto. Saludos. |
#12
|
||||
|
||||
También hay que tener en cuenta, que una factura de abono no es necesario que contenga nombres de productos.
Puede ser un Abono de X euros, por el motivo que sea, un descuento que se omitio en la factura anterior, algún producto defectuoso y otros muchos motivos por los que se acuerda el abono. Un truco suele ser dar de alta un Producto llamado Abono-Euros y otro Abono-Centimos, para hacer un abono de 112,39 € le ponemos -112 del primero y -39 del segundo. Por otra parte el abono no tiene por que ser negativo, si lo será la anotación contable. que disminuirá el debe de la cuenta del Cliente (430) y por lo tanto quedará la deuda enjugada en el próximo cobro. A mi juicio si se hace una factura negativa suele ser por devolución del producto completo, para así volver a actualizar el almacén, es decir devolver los productos al fichero de Almacén. Aunque contablemente las devoluciones irían a la cuenta(608). Un Saludo a todos. Última edición por marcoszorrilla fecha: 27-07-2003 a las 19:38:38. |
#13
|
||||
|
||||
Hola,
Cita:
Saludos. |
#14
|
||||
|
||||
Totalmente de acuerdo, pero además añado otro asunto importante, podemos hallarnos en un trimestre distinto al que se produjo el error y entoncés ya habremos hecho el ingreso de IVA correspondiente.
Con esto la cuenta 475 que habríamos dejado cuadrada en su momento por las diferencias entre 477 y 472, quedaria descuadrada. Un Saludo. |
#15
|
|||
|
|||
pos nada, solo disculparme por el pequeño mal entendido de las palabras de kinobi
Creo que ha quedado bastante claro el tema |
|
|
|