Ayuda con triggers

Hola Alejandro,

On 31 okt, 23:25, Alejandro Mesa
wrote:
Mostrar la cita

Carlos,

Que te parece esta proposicion de tener algun mechanismo automatico que haga
este update. Yo vote tan pronto lo vi, hace ya algun tiempo.

Add automatically maintained columns (perhaps just update_date, update_user)https://connect.microsoft.com/SQL/f...eedback...

Me parece una buena proposición. Supongo que habrás votado que si.
Pero no es la solución a este probema en particular.

Yo creo que lo de las tablas deleted e inserted ha fallado en esto
'by design'. Para cada registro sobre el que se hace un update
debería tenerse acceso a su versión 'old' y su versión 'new' sin
tener que recurrir a estos trucos ni depender de los valores de
cualquier columna (automática o no).

Por el momento una clave identity con un control al principio del
trigger (if updated(pk) ...) que rechaze el pudate si se cambia esa
columna, o no dar derecho de update sobre esa columna creo que son
compromisos aceptables. Aceptables.. porque no veo mejores opciones.

Saludos,
Carlos

Carlos,

Creo seria la solucion para el problema planteado por el OP. Cuando queremos
tener columnas de control como cuando fue la ultima vez que se actualizo o
quien fue el ultimo usuario que actualizo la fila.

Para otro tipo de actualizaciones / operaciones, es como tu dices. Si la
clave primaria cambia, entonces no podemos identificar las versiones
correspondiente a la fila. En ese caso una clave subrrogada seria de gran
utilidad para identificar ambas versiones, vieja y nueva.

AMB


"Carlos M. Calvelo" wrote:

Mostrar la cita

Hola Alejandro,

On 31 okt, 23:25, Alejandro Mesa
wrote:
> Carlos,
>
> Que te parece esta proposicion de tener algun mechanismo automatico que haga
> este update. Yo vote tan pronto lo vi, hace ya algun tiempo.
>
> Add automatically maintained columns (perhaps just update_date, update_user)https://connect.microsoft.com/SQL/f...eedback...
>

Me parece una buena proposición. Supongo que habrás votado que si.
Pero no es la solución a este probema en particular.

Yo creo que lo de las tablas deleted e inserted ha fallado en esto
'by design'. Para cada registro sobre el que se hace un update
debería tenerse acceso a su versión 'old' y su versión 'new' sin
tener que recurrir a estos trucos ni depender de los valores de
cualquier columna (automática o no).

Por el momento una clave identity con un control al principio del
trigger (if updated(pk) ...) que rechaze el pudate si se cambia esa
columna, o no dar derecho de update sobre esa columna creo que son
compromisos aceptables. Aceptables.. porque no veo mejores opciones.

Saludos,
Carlos
.

gracias a todos por el tiempo en contestar, veo que lo de los triggers
es un poco más complejo de lo que creía, ahora, en mi caso, me funcionó
con la ayuda de la tablas virtuales "inserted"

Saludos y nuevamente gracias por su tiempo.


Alejandro Mesa escribió:
Mostrar la cita

Carlos,

Creo seria la solucion para el problema planteado por el OP. Cuando queremos
tener columnas de control como cuando fue la ultima vez que se actualizo o
quien fue el ultimo usuario que actualizo la fila.

Para otro tipo de actualizaciones / operaciones, es como tu dices. Si la
clave primaria cambia, entonces no podemos identificar las versiones
correspondiente a la fila. En ese caso una clave subrrogada seria de gran
utilidad para identificar ambas versiones, vieja y nueva.

AMB


"Carlos M. Calvelo" wrote:

Mostrar la cita

Hola Alejandro,

On 31 okt, 23:25, Alejandro Mesa
wrote:
Mostrar la cita

Carlos,

Que te parece esta proposicion de tener algun mechanismo automatico que haga
este update. Yo vote tan pronto lo vi, hace ya algun tiempo.

Add automatically maintained columns (perhaps just update_date, update_user)https://connect.microsoft.com/SQL/f...eedback...

Me parece una buena proposición. Supongo que habrás votado que si.
Pero no es la solución a este probema en particular.

Yo creo que lo de las tablas deleted e inserted ha fallado en esto
'by design'. Para cada registro sobre el que se hace un update
debería tenerse acceso a su versión 'old' y su versión 'new' sin
tener que recurrir a estos trucos ni depender de los valores de
cualquier columna (automática o no).

Por el momento una clave identity con un control al principio del
trigger (if updated(pk) ...) que rechaze el pudate si se cambia esa
columna, o no dar derecho de update sobre esa columna creo que son
compromisos aceptables. Aceptables.. porque no veo mejores opciones.

Saludos,
Carlos
.

Una consulta, si hago uso de las tablas "inserted" o "deleted" es
necesario que haga uso excluvisamente de la columna con clave primaria?
pregunto esto porque en un ejemplo que acabo de estar viendo hay un
ejemplo que para hacer la unión con las tablas virtuales lo hacen con un
campo que almacena un valor NewId(), aunque al final el valor de dicha
columna siempre va a ser único; pero, no es una columna de clave primaria..

Saludos,

kojikabutosv escribió:
Mostrar la cita

gracias a todos por el tiempo en contestar, veo que lo de los triggers
es un poco más complejo de lo que creía, ahora, en mi caso, me funcionó
con la ayuda de la tablas virtuales "inserted"

Saludos y nuevamente gracias por su tiempo.


Alejandro Mesa escribió:
Mostrar la cita

Carlos,

Creo seria la solucion para el problema planteado por el OP. Cuando
queremos tener columnas de control como cuando fue la ultima vez que
se actualizo o quien fue el ultimo usuario que actualizo la fila.

Para otro tipo de actualizaciones / operaciones, es como tu dices. Si
la clave primaria cambia, entonces no podemos identificar las
versiones correspondiente a la fila. En ese caso una clave subrrogada
seria de gran utilidad para identificar ambas versiones, vieja y nueva.

AMB


"Carlos M. Calvelo" wrote:

Mostrar la cita

Hola Alejandro,

On 31 okt, 23:25, Alejandro Mesa
wrote:
Mostrar la cita

Carlos,

Que te parece esta proposicion de tener algun mechanismo automatico
que haga
este update. Yo vote tan pronto lo vi, hace ya algun tiempo.

Add automatically maintained columns (perhaps just update_date,
update_user)https://connect.microsoft.com/SQL/f...eedback...

Me parece una buena proposición. Supongo que habrás votado que si.
Pero no es la solución a este probema en particular.

Yo creo que lo de las tablas deleted e inserted ha fallado en esto
'by design'. Para cada registro sobre el que se hace un update
debería tenerse acceso a su versión 'old' y su versión 'new' sin
tener que recurrir a estos trucos ni depender de los valores de
cualquier columna (automática o no).

Por el momento una clave identity con un control al principio del
trigger (if updated(pk) ...) que rechaze el pudate si se cambia esa
columna, o no dar derecho de update sobre esa columna creo que son
compromisos aceptables. Aceptables.. porque no veo mejores opciones.

Saludos,
Carlos
.

Hola,

On 3 nov, 22:10, kojikabutosv wrote:
Mostrar la cita

Una consulta, si hago uso de las tablas "inserted" o "deleted" es
necesario que haga uso excluvisamente de la columna con clave primaria?

No.

Obviamente esa columna tiene que tener un valor único para poder
identificar cada registro. Vamos que tiene que ser una clave, pero
no necesariamente 'primaria'.

Mostrar la cita

pregunto esto porque en un ejemplo que acabo de estar viendo hay un
ejemplo que para hacer la unión con las tablas virtuales lo hacen con un
campo que almacena un valor NewId(), aunque al final el valor de dicha
columna siempre va a ser único; pero, no es una columna de clave primaria..

Si está garantizado que esa columna siempre tiene un valor (no puede
ser null) y ese valor es único, entonces esa columa es clave aunque
no se haya definido explícitamente como tal.

La esencia del asunto es el como saber seguro que registros en la
tabla deleted corresponden con que registros en la tabla inserted.
Eso es de lo que se trata al hacer un join como:

deleted d join inserted i on d.col=i.col

Lógicamente estamos suponiendo que col es clave y además no se ha
actualizado. Ahora, 'suponer' eso o 'asegurar' por medio de
restricciones de que realmente siempre sea así... son cosas muy
distintas.

Saludos,
Carlos