ultimo generador que ingrese
buenas tardes, tengo dos tablas relacionadas, una de estas tiene un generator y al momento de ingresar un registro en delphi incremento este por medio de gen_id, ok.
Como hago para saber exactamente cual numero generó tomarlo en una variable en delphi para luego ingresarlo en la otra tabla ? mil gracias por cualquier ayuda que me puedan brindar. |
Si está en una tabla, entonces te vale un select de la misma, no?
|
Cita:
gracias por la anotacion casimiro, el problema es que si en ese mismo instante otro usuario por casualidad inserta tambien un registro con el mismo numero de documento (este puede ser igual) podria provocar un error en los datos. |
Falta información por tu parte, ¿cómo aumentas el generador?, trigger, store procedure, desde delphi...
|
Cita:
|
Hola.
Para conocer el valor actual de un generador, puedes usar la función gen_id con un incremento de 0. Ejplo. select gen_id(gen_clientes, 0) from rdb$database NOTA: Utilizo rdb$database porqué sé que un select de esa tabla siempre va a devolver un único registro. Saludos. |
gracias guillotemarc enseguida lo pruebo.
|
Al estar relacionadas entiendo que por cada registro en la Tabla A puede haber x en la Tabla B, en este caso podrías utilizar el evento OnNewRecord de la tabla B.
Un Saludo. |
Cita:
Desde delphi, sí, vale, pero ?cómo?. El método propuesto por el compañero guillotmarc te devuelve, evidentemente, el último valor generado, pero si estás en un entorno multiusuario entonces puede no valerte si otro usuario ha pedido un nuevo número. |
Si trabajas con Firebird 2.1 o posterior puedes utlizar la clausula RETURNING.
No es recomendable que tú asignes el valor del campo ID, o de cualquier otro campo que obtiene su valor del próximo estado del generador. Para asignar los valores en este tipo de campos, es mejor dejar el código de asignación en un stored procedure -ejecutado en un AFTER INSERT-. A cómo tú lo has dicho, nunca sabes si un usuario va a ingresar un registro al mismo tiempo que lo haga otro usuario. Saludos, Chris |
Cita:
Saludos, |
No estoy muy seguro, pero creo que con los componentes que soporten Firebird 2.1 llamas al procedimiento Open, en lugar de llamar al ExecSQL como lo harías normalmente. Desconozco si esta funcionalidad es soportada por los componentes que no han sido desarrollados teniendo en cuanta las mejoras en la versión 2.1 de firebird.
|
Así parece ser Cris. Debería emplearse componentes o drivers que trabajen con las nuevas características de Firebird... Yo uso D6 y FB 1.5 por lo que no se mucho, pero otras personas que trabajan con Firebird 2.0 y 2.1 y cuentan con versiones modernas de Delphi no pueden leer el RETURNING con los componentes estándares.
Desconozco si Zeos ya soporta esto, creo yo que ni siquiera el nuevo Driver para DBX disponible en Delphi 2010 y XE Enterprise tiene soporte para esto. Saludos, |
Cita:
|
Sí, es una vergüenza que este driver solo esté en la versión Enterprise, debería estar a partir de la versión Professional.
NOTA: No sé si permite recuperar el valor returning de un insert, puesto que como no he podido pagar la burrada que cuesta un Enterprise, no tengo este driver. |
No necesitas un driver tan caro. Yo esto del RETURNING lo hago con los componentes IUB. Son muy buenos, rápidos y estables. Lo mejor de todo es que son gratis :)
|
Cita:
El punto es que debería haber soporte desde fábrica :mad: y no estar siempre dependiendo de componentes externos. Saludos, |
Resp
desde delhpi has un select. select gen_id(gen_clientes, 1) from rdb$database
ese valo lo insertar en tabla base y si necesitas insertalo en otra tabla ya lo tienes. |
gracias creo que esa es la respuesta ahorita la pruebo
Cita:
gracias voy a probar |
Cita:
Supón el siguiente escenario: Haces un inserción en la tabla facturas. El ID asignado a la nueva factura es #1,000. Sin embargo, por sinsustancias de la red u otro componente intermedio, hay un pequeño retraso en llegarle la notificación a tu aplicación de que la inserción fue exitosa. Mientras tu esperabas las respuesta del servidor, otro usuario factura y obtiene el número de factura siguiente. Al momento que tu aplicación ha recibido la respuesta y llama a gen_id, el valo devuelto será #1,002 y terminarás asociando productos a la factura que realmente no debiste hacerlo. El escenario anterior es mucho más probable de suceder en relación al número de usuarios que requieren la funcionalidad con el bug que te acabo de describir. Si son diez usuarios que esporadicamente facturan será poco probable que suceda, pero lo hará. Todo lo que puede salir mal saldrá mal, eso no hay que olvidarlo. Saludos, Chris EDITO: No me había fijado que habías sugerido utilizar "select gen_id(gen_clientes, 1)" para obtener un identificador único y luego utilizarlo para asignárselo a una nueva factura y sus detalles por ejemplo. De hecho esta es la solución adecuada para el problema. Es lo más seguro en términos de integridad de datos. Aunque te arriesgas a dejar números de facturas no consecutivos si ocurren errores posteriores. Pero eso no es tan grave como asociar productos a una factura a la que no van y dejar a otra sin descendencia. |
Creo que rastafarey se refiere a usar el ID devuelto por el generador, no pide otro después, por lo que no habría problema, el generador le entrega el 1000, aunque se corte la red o suceda cualquier cosa, el número que guardará será el 1000.
Eso me ha parecido entender que ha explicado. |
Cita:
|
La franja horaria es GMT +2. Ahora son las 06:04:16. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi