ultimo generador que ingrese

[[Delphius]]

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,

[Casimiro Noteví]

Empezado por Delphius

[..] creo yo que ni siquiera el nuevo Driver para DBX disponible en Delphi 2010 y XE Enterprise tiene soporte para esto.
Saludos,

Pues con el dineral que cuesta, ya podían haberlo puesto.

[guillotmarc]

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.

[[Chris]]

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

[[Delphius]]

Empezado por Chris

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

Gracias por el dato.

El punto es que debería haber soporte desde fábrica y no estar siempre dependiendo de componentes externos.

Saludos,

[rastafarey]

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.

[[Chris]]

Empezado por rastafarey

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.

Existe una posibilidad de introducir un bug al sistema al basarte del valor del generador para determinar el ID del registro recién agregado.

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.