Generar un valor por default distinto para cada insert

[fcios]

Hola, desde ya gracias de antemano, estoy con firebird 1.5 y delphi 7

Estoy probando de generar un valor por default distinto para cada insert y no recibo nada, he probado en la BD Trigger Before Insert donde ya genero el ID
pero el tema es que al darle + al Navigator no me aparece ningun valor por default en el DBEdit (ni tampoco el ID aunque si se guarda correctamente).

Lo que necesito deberia trabajar similar a como se define el valor por default en la tabla con por ejemplo CAMPO1 FLOAT DEFAULT 5, que esto si funciona, al darle + al Navigator me coloca 5

Yo necesito generar un valor por ejemplo Select max(campo1) from tabla y mandarselo como default al campo1 que estoy insertando.

Esto lo debo hacer en la base de datos, no me vale hacerlo en el Before Insert de la Tabla de Delphi

Muchas Gracias

[ronalg]

Usa un porcedimiento almacenado en ONNEWRECORD, veras las ventajas.

Lo que pasa es que los valores por default se colocan en el servidor cuando haces el post, no antes no después y para peor no los ves hasta que abres de nuevo la tabla.

Ojo es un problema de transacciones, ahora no me acuerdo como se arregla, pero es mejor usar la solución que te di primero.

[Neftali [Germán.Estévez]]

Empezado por fcios

Generar un valor por default distinto para cada insert

La verdad es que es una definición "curiosa" para un valor por defecto.
Si tienes concurrencia, no se si puedes tener problemas con los triggers; Otra opción es un Stored Procedure (que protegido debidamente con transacciones) te puede ofrecer un valor único.

[nemesio]

Yo uso un tigger y me da un valor unico para cada registro.

Saludos

[jachguate]

Empezado por Neftali

Si tienes concurrencia, no se si puedes tener problemas con los triggers; Otra opción es un Stored Procedure (que protegido debidamente con transacciones) te puede ofrecer un valor único.

La solución "natural" para la generación de valores únicos cuando hay concurrencia es el uso de generadores. En el evento OnNewRecord del dataset asociado, o bien en el evento BeforePost cuando el estado del dataset es dsInsert es donde suelo poner la generación del valor único.

Obviamente, este valor debe generarse desde delphi, en un trigger de la base de datos no resulta tan útil si la interacción se lleva a cabo solo desde el programa de delphi, pues este será incapaz de reconocer la fila que ha insertado.

Si habrá interacción desde otras fuentes, digamos isql, entonces como auxiliar pondría un trigger before insert que asigne un valor al nuevo registro solamente si el campo en cuestión viene nulo.

Hasta luego.

[Neftali [Germán.Estévez]]

Empezado por jachguate

La solución "natural" para la generación de valores únicos cuando hay concurrencia es el uso de generadores.

Cierto, la solución pueden ser los generadores, aunque no siempre un generador devolverá el mismo número que un Max (Select max(campo1) from tabla es los que se proponía inicialmente).
El problema de los generadores es que si generas un número y luego deshaces el Insert o borras el registro, ese valor se pierde y al generar el siguiente tendrás un "hueco" en la numeración; Al proponer en el mensaje original un Max, pensé que quedaba desechada esa opción.

Si eso no es importante, está claro, debes usar generadores, que para eso están.

[jachguate]

Empezado por Neftali

aunque no siempre un generador devolverá el mismo número que un Max (Select max(campo1) from tabla es los que se proponía inicialmente).

¡Claro! De hecho, sería una coincidencia que un generador devuelva el mismo valor que un select max() + 1), pero precisamente es por eso es mas fiable, pues si dos usuarios insertar un registro al mismo tiempo, obtendrán valores diferentes para su llave, mientras que con un select max, ambos obtendrán el mismo valor.

Empezado por Neftali

El problema de los generadores es que si generas un número y luego deshaces el Insert o borras el registro, ese valor se pierde y al generar el siguiente tendrás un "hueco" en la numeración

Sin importar cómo hayas obtenido el valor de la llave primaria, si borras un registro, seguramente tendrás un hueco en la numeración...

Creo que es importante tener en cuenta, al modelar un sistema, que es una mala idea usar los números de documento fiscales o contables como llave primaria. Creo que se gana mucha independencia si usas una llave totalmente artificial y luego asignas los números de documento según corresponda. Desde este punto de vista, tener un hueco en el correlativo no tiene ninguna importancia.

Hasta luego.

[Neftali [Germán.Estévez]]

Empezado por jachguate

Sin importar cómo hayas obtenido el valor de la llave primaria, si borras un registro, seguramente tendrás un hueco en la numeración...

No si lo calculas a partir de Max (asegurándote de no provocar duplicados ni bloqueos); Siempre hablando del último -que es un caso especial-.

Empezado por jachguate

Creo que es importante tener en cuenta, al modelar un sistema, que es una mala idea usar los números de documento fiscales o contables como llave primaria. Creo que se gana mucha independencia si usas una llave totalmente artificial y luego asignas los números de documento según corresponda. Desde este punto de vista, tener un hueco en el correlativo no tiene ninguna importancia.

Estoy de acuerdo contigo, pero lo que acabas de hacer es desplazar el problema. La clave primaria la calculas con un generador. OK; ¿Pero cómo calculas entonces el número de documento fiscal o contable? Es el mismo problema, pero pasado a otro campo.

[jachguate]

Empezado por Neftali

No si lo calculas a partir de Max (asegurándote de no provocar duplicados ni bloqueos); Siempre hablando del último -que es un caso especial-.

Yo me refería al borrado de un registro en cualquier parte de la tabla...

Empezado por Neftali

Estoy de acuerdo contigo, pero lo que acabas de hacer es desplazar el problema. La clave primaria la calculas con un generador. OK; ¿Pero cómo calculas entonces el número de documento fiscal o contable? Es el mismo problema, pero pasado a otro campo.

No necesariamente es el mismo problema. Hay ocasiones en que el número de documento puede calcularse en el evento before insert, cuidando que las transacciones sean muy cortas para mejorar la concurrencia. Si se requiere de alta concurrencia sin problemas de bloqueos, regularmente yo me valgo de una tabla auxiliar en la que llevo en valor del correlativo, inserto el registro y hasta después de esto pongo un bloqueo sobre la tabla del correlativo, asigno el número de documento y hago commit. El bloqueo (que podría ser un update en falso) regularmente está dentro de un ciclo que reintentará un número configurable de veces y con un tiempo de espera también configurable entre reintentos, dandole chance al usuario de cancelar en cualquier momento, de manera que la asignación se realice al final de la transacción y soporte mas o menos los típicos problemas de concurrencia...

Si al final de cuentas no puede asignarse el número, el usuario siempre tiene el chance de dejar grabado el registro y volver luego para asignarle un número, con lo que tampoco perderá trabajo...

En fin, no hay un método perfecto, pero si hay mecanismos mas o menos sofisticados para atacar este asunto...

Saludos.

[fcios]

Bueno probe de hacerlo en un procedimiento almacenado en ONNEWRECORD dentro de Delphi y anda ok, Gracias a todos por las ideas aportadas
Fabian