¿como obtener id del registro recien insertado?

[arrayman]

Buenas, Pues eso tengo una aplicacion que utiliza dbexpress para conectarse con firebird actualmente uso procedimientos almacenados como este

Código SQL [-]
CREATE OR ALTER PROCEDURE SP_GEN_CCLIENTES_ID 
returns (ID Integer)
AS 

begin
  ID=GEN_ID(GEN_CCLIENTES_ID,1);
  SUSPEND;
end

para obtener una clave unica y usarla en las inserciones.
pero pienso que debe existir otra forma en la que puedas averiguar que
id asigno un triger con un codigo similar al anterior

la principal desventaja de mi sistema es que tiende a generar huecos.

en fin si alguien lo hace de otro modo ... estaria bien conocerlo

un saludo.

[[oscarac]]

y porque genera los huecos?
cual es el motivo?

[[Chris]]

Usa la clausula RETURNING.

[arrayman]

creo que si metes el codigo en un triguer habra menos posibilidad de fracaso en la insercion pues supongo que saltara cuando el registro se ha validado y
va a ser insertado. con mi sistema yo tengo que reservar el id antes de grabar y si la insercion falla el codigo ya ha sido reservado si el usuario decide no volver a intentarlo o simplemente pulso donde no era y cancela el hueco esta.
no es gran diferencia, tb es curiosidad.

gracias mirare el link de returning en cuanto pueda ahora me voy a sobar
que es tarde y mañana es mañana.

[arrayman]

esta bien no pude resistirme y lo mire,

desconocia esa información, muy bueno pero la verdad que yo hago las inserciones via tclientdataset, es decir las hace el por mi.
no se si habra alguna opcion de configuración para que genere ese tipo
de sentencia y me devuelva la primarykey, si no se pierde en comodidad
pero me viene genial para los casos en que lo tenga que hacer a mano.

muchas gracias.

[ecfisa]

la principal desventaja de mi sistema es que tiende a generar huecos.

Los generadores se diseñaron para garantizar la unicidad en entornos multiusuario y no es relevante que sean consecutivos. Las 'brechas' numéricas son
muy normales con su uso.
El tema de los 'huecos' se presenta por ejemplo cuando: El usuario A obtiene el identificador 500, seguidamente el usuario B recibe el 501,
el C el 502, etc. Entonces el usuario A decide abortar haciendo un rollback, el generador continuará la secuencia sin importar la posición 500.

Para hacer códigos consecutivos podés incrementar un campo mediante un trigger y usar un procedimiento almacenado para obtener el próximo código.

Por ejemplo:

Código SQL [-]
SET TERM ^;
CREATE TRIGGER TABLA_CODIGO_AI FOR TABLA_CODIGO ACTIVE AFTER INSERT POSITION 0
AS
BEGIN
  UPDATE TABLA_CODIGO SET NUM_CODIGO = NUM_CODIGO + 1;
END^

CREATE PROCEDURE SP_PROXIMOCODIGO RETURNS (PROXCOD CHAR(8))
AS
DECLARE VARIABLE NUMERO INTEGER;
BEGIN
  SELECT NUM_CODIGO FROM TABLA_CODIGO INTO NUMERO;
  NUMERO = NUMERO + 1;
  PROXCOD = LPAD(TRIM(CAST(NUMERO AS VARCHAR(8))), 8, '0');
END^
SET TERM ;^

El procedimiento te devolverá el próximo siguiente código. (00000001,00000002,00000003,..)

Un saludo.

[arrayman]

ok, lo se, no pasa nada con los huecos, mi interes era descubrir otras formas y a ser posible mejores (como en todo pa unas cosas si pa otras no).

de todos modos detallare un poco mejor, como dije uso tclientdataset, y en el beforepost es donde obtengo el id via store proc. lo hasigno al campo correspondiente del clientdataset y hago un applyupdates.

es por eso que aunque vuestros aportes son magnificos, como dije salvo para casos concretos en que lo haga a mano, no veo como usarlo pues es el propio clientdataset el que genera los insert y no se como recuperar el id o como configurarlo para que lo gestion el.

la comodidad que ofrece el clientset (gestiona el solito los insert y los updates y de un modo bastante flexible) me hace pensar que a mi no me vale la pena el beneficio en fin gracias

un saludo y muchas gracias

[guillotmarc]

Empezado por arrayman

ok, lo se, no pasa nada con los huecos, mi interes era descubrir otras formas y a ser posible mejores (como en todo pa unas cosas si pa otras no).

de todos modos detallare un poco mejor, como dije uso tclientdataset, y en el beforepost es donde obtengo el id via store proc. lo hasigno al campo correspondiente del clientdataset y hago un applyupdates.

es por eso que aunque vuestros aportes son magnificos, como dije salvo para casos concretos en que lo haga a mano, no veo como usarlo pues es el propio clientdataset el que genera los insert y no se como recuperar el id o como configurarlo para que lo gestion el.

la comodidad que ofrece el clientset (gestiona el solito los insert y los updates y de un modo bastante flexible) me hace pensar que a mi no me vale la pena el beneficio en fin gracias

un saludo y muchas gracias

Yo lo hago igual que tú, ya que si dejas que sea la misma base de datos la que asigne los ID, entonces te encuentras varios problemas.

La base de datos (los triggers) solo le da valores al guardar los datos, por lo tanto, cuando haces relaciones maestro-detalle, no tienes la clave del maestro hasta que no lo hayas guardado (y eso te obliga a recorrer a posteriori los detalles, para asignarles la clave de relación).

En cualquier para recuperar el ID, una vez asignado por la base de datos, tienes varias opciones :

a) Utilizar la cláusula returning en el INSERT. El problema es que tienes que personalizar la sentencia INSERT con la que se dará de alta el registro, y por lo tanto no puedes usar el ClientDataset para dar de alta el registro.

b) Lanzar una consulta : select max(ID) from TABLA, para averiguar el último ID asignado. El problema es que si hay varias personas trabajando a la vez, puedes obtener un valor erroneo.

c) Puedes consultar el generador, utilizando un incremento de 0. Es decir : gen_id(NOMBRE_GENERADOR, 0). Esto es más rápido de ejecutar, pero tiene el mismo problema que la solución anterior.

Personalmente me sigo quedando con asignar manualmente el ID desde Delphi, en el AfterInsert de un registro. Pero en lugar de utilizar un procedimiento almacenado (más que nada porqué con tanto procedimiento por eso, al final molestan para manejar los que hacen algo "de verdad"), simplemente lanzo una consulta

select gen_id(NOMBRE_GENERADOR, 1) from rdb$database

Saludos.

[arrayman]

ok, muchas gracias por compartir vuestras experiencias. la verdad no conocia la posibilidad de usar la select para lanzar el gen_id en lugar de los procedimientos, si es cierto que es un poco molesto si tienes muchos procedimentos.

nuevamente gracias y un saludo.

[[Al González]]

Empezado por guillotmarc

[...] Personalmente me sigo quedando con asignar manualmente el ID desde Delphi, en el AfterInsert de un registro[...]

select gen_id(NOMBRE_GENERADOR, 1) from rdb$database

Es lo que hago también. Desde el mismo momento en que "nace" un registro en el TClientDataSet, éste ya trae su identificador, es decir, le asigno el ID con el que tentativamente será guardado en la base de datos. Esto por las razones que explicas, Marc. Y es que hasta para existir efímeramente sin ser nunca guardado, resulta útil que un registro tenga su "asa".

También decir que en muchos casos utilizo un sólo generador para todas las tablas, contrario a la costumbre de un generador por tabla. De hecho, al tener cada registro un identificador único, que jamás se repetirá en ninguna otra tabla, se consiguen ventajas interesantes, como hacer uniones verticales sin problemas por duplicidad de IDs y un mayor control en tareas de depuración y manejo de entidades.

A fin de decidir si utilizo o no un sólo generador para toda la base de datos, primero estimo cuántos años necesitaría la aplicación para gastar los 2,147,483,647 IDs que como máximo da en valores positivos un entero con signo de 32 bits (considerando también en ello a los posibles registros cuya captura sea iniciada pero nunca guardada). En la mayoría de los casos, porque no manejo volúmenes de información astronómicos, resulta que no vale la pena usar un generador por tabla.

Claro está, ya me planteo si no sería buena idea comenzar a utilizar IDs de 64 bits, y con ello la aplicación quedaría reforzada contra cualquier usuario increíblemente obsesivo que pase toda su vida apretando constantemente los botones Agregar y Cancelar.

En resumen, debemos quitarnos esa vieja idea de que el campo ID es para numerar registros (para algo así son los campos "NUMERO", "CLAVE", "CODIGO", etc.). El campo ID es para darle unicidad a cada registro de una tabla e identificarlos a nivel interno (el usuario de la aplicación no tiene por qué conocer la existencia de este campo), es la "asa" por la cual se tomarán para su manejo y relación con otros registros, pero no se muestran en ninguna interfaz de usuario o reporte. En pocas palabras, es lo que suelen llamar clave / llave primaria artificial, que no por ser "artificial" es mala, al contrario.

Bueno, ya me explayé demasiado (para variar).

Un abrazo con o sin hueco.

Al González.

[Casimiro Notevi]

Al, los generadores en Firebird son de 64 bits:

Generators store and return 64-bit values in all versions of Firebird. This gives us a value range of:
-263 .. 263-1 or -9,223,372,036,854,775,808 .. 9,223,372,036,854,775,807

Así que si algún loco compulsivo de las teclas que pueda crear 1 registro por segundo... tardaría 9223372036854775807 segundos en "acabarlos", o sea:
Un siglo=86400*365*100 segundos = 3156300000
9223372036854775807/3153600000=2924712086 siglos = 2924712 milenios

Creo que me he equivocado con los cálculos
Enlace a documento sobre generadores.

[[Al González]]

Empezado por Casimiro Notevi

Al, los generadores en Firebird son de 64 bits.

Algo me suponía o había leído, pero (corrígeme si me equivoco) creo que en Firebird 1.5 son de 32 bits. Y bueno, de cualquier manera me referí a los campos ID donde normalmente se guardan estas llaves, que por lo general son de 32 bits, y pensando a futuro, con Firebird 2, cambiar a enteros de 64 bits.

[Casimiro Notevi]

Me parece recordar que en FB1.5 eran de 64 bits, aunque no estoy seguro.
Entonces para lo que indicas puede ser más interesante usar los campos del tipo GUID, esos que son algo así como: 6ef41c55-03ff-4941-9382-290813ad46c2, creo haber leído algo sobre que son aconsejable para lo que comentas y vienen, creo, en FB2.0 en adelante.
Aunque todavía no los he visto, puede que me esté confundiendo.

[guillotmarc]

Empezado por Al González

Es lo que hago también. Desde el mismo momento en que "nace" un registro en el TClientDataSet, éste ya trae su identificador, es decir, le asigno el ID con el que tentativamente será guardado en la base de datos. Esto por las razones que explicas, Marc. Y es que hasta para existir efímeramente sin ser nunca guardado, resulta útil que un registro tenga su "asa".

Exacto, esa es la razón para asignar el ID en el AfterInsert y no en el BeforePost. Puesto que para mantener la relación en los registros maestros-detalles, es muy conveniente tener la identidad del registro maestro nada más crearlo, y no tener que esperar a guardarlo para poder relacionar sus detalles.

Empezado por Al González

También decir que en muchos casos utilizo un sólo generador para todas las tablas, contrario a la costumbre de un generador por tabla. De hecho, al tener cada registro un identificador único, que jamás se repetirá en ninguna otra tabla, se consiguen ventajas interesantes, como hacer uniones verticales sin problemas por duplicidad de IDs y un mayor control en tareas de depuración y manejo de entidades.

A fin de decidir si utilizo o no un sólo generador para toda la base de datos, primero estimo cuántos años necesitaría la aplicación para gastar los 2,147,483,647 IDs que como máximo da en valores positivos un entero con signo de 32 bits (considerando también en ello a los posibles registros cuya captura sea iniciada pero nunca guardada). En la mayoría de los casos, porque no manejo volúmenes de información astronómicos, resulta que no vale la pena usar un generador por tabla.

Claro está, ya me planteo si no sería buena idea comenzar a utilizar IDs de 64 bits, y con ello la aplicación quedaría reforzada contra cualquier usuario increíblemente obsesivo que pase toda su vida apretando constantemente los botones Agregar y Cancelar.

En resumen, debemos quitarnos esa vieja idea de que el campo ID es para numerar registros (para algo así son los campos "NUMERO", "CLAVE", "CODIGO", etc.). El campo ID es para darle unicidad a cada registro de una tabla e identificarlos a nivel interno (el usuario de la aplicación no tiene por qué conocer la existencia de este campo), es la "asa" por la cual se tomarán para su manejo y relación con otros registros, pero no se muestran en ninguna interfaz de usuario o reporte. En pocas palabras, es lo que suelen llamar clave / llave primaria artificial, que no por ser "artificial" es mala, al contrario.

Bueno, ya me explayé demasiado (para variar).

Un abrazo con o sin hueco.

Al González.

Muy interesante observación, alguna vez lo había pensado también pero nunca lo he llevado a la práctica.

Supongo que la ventaja de mantener generadores independientes por tabla es la facilidad de seguir la correlación entre sus registros y sobretodo la facilidad para manejar unos códigos cortos en las consultas manuales que muchas veces te ves obligado a hacer para hacer el seguimiento y depuración de algún módulo.

En cualquier caso nunca había pensado en las ventajas añadidas como la que comentas sobre uniones verticales.

Pero creo que si optas por esa opción, también deberías estudiar la posibilidad de usar UUID's como identificadores de tablas. En las versiones más modernas de Firebird ya vienen funciones integradas que te facilitan enormemente su utilización y obtienes la ventaja añadida de que la unicidad de los ID ya no es solo entre registros de distintas tablas, sino también entre los registros de distintas bases de datos.

Eso es muy útil cuando tenemos bases de datos en distintas localizaciones (por ejemplo un grupo de tiendas que ponen un servidor Firebird local en cada tienda), y que a la vez quieren sincronizar (replicar) periodicamente esas bases de datos. Al utilizar UUID's no tienes que configurar nada en cada base de datos para asegurarte de que generan ID's que no entran en conflicto con el resto del sistema.

Saludos.

[guillotmarc]

Empezado por Casimiro Notevi

Me parece recordar que en FB1.5 eran de 64 bits, aunque no estoy seguro.
Entonces para lo que indicas puede ser más interesante usar los campos del tipo GUID, esos que son algo así como: 6ef41c55-03ff-4941-9382-290813ad46c2, creo haber leído algo sobre que son aconsejable para lo que comentas y vienen, creo, en FB2.0 en adelante.
Aunque todavía no los he visto, puede que me esté confundiendo.

Vaya, veo que ya has sacado antes el tema de las GUID / UUID

Si en lugar de quedarme solo con el comentario sobre los enteros de 64 bits, me leyera completos los mensajes, no pasaría estos embarazos.

[Casimiro Notevi]

Tú lo has explicado muy bien y además has confirmado su existencia, yo sólo había oído/leído algo al respecto, pero no estaba seguro.
Muy interesante tus comentarios y los de Al González, todos los días se aprende algo o, como mínimo, se sacan nuevas ideas

[arrayman]

Bueno creo que tengo material a investigar en cuanto encuentre un hueco :-))

me parece que se puede hacer un buen compendio con las ideas y experiencias expuestas, para mejorar el sistema que utilizo. me llama mucho la atencion lo de los uuid. ademas aprendere de paso conceptos como uniones verticales.
nuevamente gracias.

[[Al González]]

Empezado por guillotmarc

Pero creo que si optas por esa opción, también deberías estudiar la posibilidad de usar UUID's como identificadores de tablas. En las versiones más modernas de Firebird ya vienen funciones integradas que te facilitan enormemente su utilización y obtienes la ventaja añadida de que la unicidad de los ID ya no es solo entre registros de distintas tablas, sino también entre los registros de distintas bases de datos.

Eso es muy útil cuando tenemos bases de datos en distintas localizaciones (por ejemplo un grupo de tiendas que ponen un servidor Firebird local en cada tienda), y que a la vez quieren sincronizar (replicar) periodicamente esas bases de datos. Al utilizar UUID's no tienes que configurar nada en cada base de datos para asegurarte de que generan ID's que no entran en conflicto con el resto del sistema.

Esa también es una interesante observación, Marc. Algo había leído ya, pero no he comenzado a estudiar el tema porque todavía sigo con Firebird 1.5 (cuando termine mi actual y principal proyecto me daré el tiempo para revisar y actualizarme a alguna de las nuevas versiones).

Me parecería bastante conveniente que cada registro de todas las bases de datos del mundo tuvieran un identificador universalmente único, o al menos orientarnos hacia ese ideal empezando a utilizar UUIDs. La duda que me surge es cómo se comportan estos identificadores en cuestión de desempeño, considerando que su tamaño (128 bits) es cuatro veces el de un ID clásico.

Saludos.

Al González.

[guillotmarc]

Empezado por Al González

Me parecería bastante conveniente que cada registro de todas las bases de datos del mundo tuvieran un identificador universalmente único, o al menos orientarnos hacia ese ideal empezando a utilizar UUIDs. La duda que me surge es cómo se comportan estos identificadores en cuestión de desempeño, considerando que su tamaño (128 bits) es cuatro veces el de un ID clásico.

A mi personalmente me echa más para atrás el hecho de que cualquier consulta manual o cada vez que leas los datos para hacer cualquier comprobación, en vez de usar números simples tendrás que poner o buscar un UUID (largo, tedioso de teclear y difícil de recordar).

El tema del rendimiento, he leído en varias ocasiones que no tiene ningún impacto notable. Como siempre, es mucho más importante optimizar bien tu consulta (a nivel de índices, plan de ejecución, ...) que no el rendimiento bruto del motor sin optimizaciones.

Saludos.