Tablas deleted y Inserted.

¿y cómo tratarás las actualizaciones registradas anteriormente del cliente 20?

Es decir, si antes de ese update sobre el campo clave tenías registrado el
cambio del nombre del cliente 20, ¿sería correcto?

Ahora que lo pienso, en realidad si la actualización afectara sólo a un
registro, no tienes mayor problema porque sabes que pertenece a un único
cliente (podrías recoger el campo clave de la tabla deleted para saber el
valor antiguo).

Yendo un poco más allá, podrías comprobar que si el campo que se está
modificando es la clave primaria de la tabla, no permitir que haya más de un
registro afectado para que te funcione el método que te comento. En el resto
de los casos te da igual porque el valor de la clave primaria será el mismo
en las tablas deleted e inserted.


Un saludo
-
www.navento.com
Servicios de Localización GPS


"Alex" wrote:

Amigos,
Si los entiendo realmente, ya se trataria de otro registro sin embargo en la
practica es una actualización, es algo asi como esto:

Update Tabla
Set campollave = '20'
where campollave = '10'

En este caso que triger se activa ??? no es el de actualización o es el de
inserción o eliminación?
Por eso es que quiero la relación entre ambas tablas por que se trata de
una actualización en la práctica.



"Carlos Sacristan" wrote:

> Estoy de acuerdo con Ramón: si lo que se modifica es la clave primaria de la
> tabla, estás modificando la "identidad" (por decirlo de alguna forma) de ese
> registro. Estás tratando, en definitiva, con otro totalmente diferente.
>
> Desde mi punto de vista, es como si se hiciera un delete y luego un insert.
> No sería una actualización.
>
> Un saludo
> -
> www.navento.com
> Servicios de Localización GPS
>
>
> "Alex" wrote:
>
> > Amigos,
> > Una consulta hay algún campo en comun por los que se pueden relacionar las
> > tablas deleted y inserted, este debido a que debo realizar un triger para
> > guardar los campos que se van camiando de los clientes que tenemos en la
> > empresa, hasta ahora todo ok por que ambas tablas las relacionaba por el
> > campo id_cliente de ambas tablas, pero que pasa si se modifica el campo
> > id_cliente, entonces no habria forma de relacionarlos por que ambas tablas
> > tendrian diferentes id_clientes, por favor espero su ayuda, muchas gracias
> > amigos¡¡¡.
> > Saludos.

"Alex" escribió en el mensaje
news:

Amigos,
Si los entiendo realmente, ya se trataria de otro registro sin embargo en
la
practica es una actualización, es algo asi como esto:

Update Tabla
Set campollave = '20'
where campollave = '10'

En este caso que triger se activa ??? no es el de actualización o es el de
inserción o eliminación?
Por eso es que quiero la relación entre ambas tablas por que se trata
de
una actualización en la práctica.

Hola, Alex:

Lo más sensato es lo que te recomendó Alfredo Novoa: agrega a la tabla una
columna autonumérica y úsala como clave.

Por otra parte, si estás absolutamente seguro de que la operación de
actualización sólo afectará a un registro, entonces estás seguro de que
DELETED e INSERTED contienen exactamente una fila cada una, y no necesitas
depender de ninguna relación y puedes combinarlas como mejor te parezca.

Aunque, como decimos en mi pueblo, lo único seguro que hay es la muerte.

Salud!

Hola Alfredo:

"Alfredo Novoa" escribió en el mensaje de
noticias:18ds59mqhf56r$.il4cnu43of9n$

Hola Alex,

El Mon, 15 Dec 2008 12:22:00 -0800, Alex escribió:

Una consulta hay algún campo en comun por los que se pueden relacionar
las
tablas deleted y inserted, este debido a que debo realizar un triger para
guardar los campos que se van camiando de los clientes que tenemos en la
empresa, hasta ahora todo ok por que ambas tablas las relacionaba por el
campo id_cliente de ambas tablas, pero que pasa si se modifica el campo
id_cliente, entonces no habria forma de relacionarlos por que ambas
tablas
tendrian diferentes id_clientes, por favor espero su ayuda, muchas
gracias

Lo que se me ocurre es que crees un campo identity que no se use para nada
más, y así ya tienes una forma de identificar las filas.

¿Recuerdas aquél post en el que yo hablaba de no modificar nunca la clave
primaria y tú no veías el por qué?

Pues ésta es una de esas situaciones que a mi se me ha dado más de una vez
(por ejemplo, un cambio de NIF de un registro de personal) y que me
empujaron en su momento a usar ids jugando con otros campos pero inmutables,
o ids numéricos.

Un saludo

Hola Alex,

On 16 dec, 15:36, Alex wrote:

Amigos,
Si los entiendo realmente, ya se trataria de otro registro sin embargo en la
practica es una actualización, es algo asi como esto:

No tiene por que tratarse de otro registro (ni otra entidad!).
Si consideramos la situación mas genérica posible, sobre una tabla
pueden haberse definido varias claves y que una de ellas cambie no
quiere decir que ya solo por eso se trate de otra entidad ya que
las otras claves siguen siendo las mismas. Cuando solo tenemos una
clave ya no es ta obvio, pero el problema es el mismo.
Vamos, que no estoy de acuerdo con los que dicen que se trata
'lógicamente' de otro registro. Eso... depende.

Aparte de eso, puede ser que considerarlo como un delete y un insert
no sea una opción. Pensemos que otras tablas pueden hacer referencia
a esa tabla. Borramos todos esos registros en esas tablas y los
volvemos a introducir? No creo!

Update Tabla
Set campollave = '20'
where campollave = '10'

En este caso que triger se activa ??? no es el de actualización o es el de
inserción o eliminación?

Se activa el update.

Por eso es que quiero la relación entre ambas tablas por que se trata de
una actualización en la práctica.

Haz lo que de aconsejan Alfredo y Leonardo. Añades otra clave
(identity?), y no le des permisos de actualización sobre esa
clave a nadie (sino estaríamos otra vez con el mismo problema
con esta clave). Con esa clave puedes identificar que registros en
la tabla deleted van con que registros en la tabla inserted.

Como a esta tabla se puede hacer referencia desde otras tablas,
tienes que considerar a que clave debes hacer referencia.
Si quieres que esta clave nueva no sea visible desde las
aplicaciones no puedes utilizarla para eso (la necesitarías para
hacer joins). Por qué? Quizás lo mas importante es que si la clave
llega a las aplicaciones, con el paso del tiempo los usuarios
acabarán por atribuirle algún significado y podríamos acabar teniendo
el mismo problema con esa clave. Si ese es el caso no des tampoco
permisos de select. Pero quizás ese riesgo sea aceptable y entonces
puedes utilizarla también para ese fin.

Si decides utilizar otra clave para las referencias, y esa clave
tiene que ser lógicamente actualizable entonces tendrás que tener
en cuenta los on update cascade al definir esas referencias.
O hacerlo en triggers, para lo que a su vez, la clave nueva que
has definido (no actualizable) te ayudará a identificar que registros
en la tabla deleted van con que registros en la tabla inserted.

Como anécdota, mira este ejemplo (mensaje no 9, del 7 dec. 02:04)
que he puesto en la siguiente discusión:
http://groups.google.am/group/micro...1ebe643e7#

Como ves allí también hago referencia a ese problema con los
triggers. Pero bueno... eso como anécdota, ya que allí pongo un
ejemplo de lo que tendríamos que poder hacer en SQL Server, pero
no podemos :-(
Y precisamente por eso aquel problema está relacionado con este que
tu propones; el problema de ese ejemplo en SQL Server también
podría ser solucionado con una nueva clave, no actualizable.

Solo trato de darte algunas ideas generales que creo que tienes
que considerar, ya que no todos los casos son iguales y dependerá
de tu situación.

Saludos,
Carlos

PD: Y es que SQL Server roza la perfección! :-(

Hola Juan Diego,

El Tue, 16 Dec 2008 22:09:34 +0100, Juan Diego Bueno escribió:

Lo que se me ocurre es que crees un campo identity que no se use para nada
más, y así ya tienes una forma de identificar las filas.

¿Recuerdas aquél post en el que yo hablaba de no modificar nunca la clave
primaria y tú no veías el por qué?

Sigo sin verlo. Estamos justamente hablando de como podemos hacer para
modificar la clave primaria :-)

Pues ésta es una de esas situaciones que a mi se me ha dado más de una vez
(por ejemplo, un cambio de NIF de un registro de personal) y que me
empujaron en su momento a usar ids jugando con otros campos pero inmutables,
o ids numéricos.

A mi también me ha pasado alguna vez y es otra vez por culpa de los
defectos de SQL Server. Por ejemplo con Firebird esto no pasa.

Pero cuando pasa le añades a la tabla un campo identity que solo sirve para
usar en los triggers y luego te creas una vista que no contenga la clave
artificial y listo.

El problema solo ocurre cuando tienes claves externas con actualizaciones
en cascada que hacen referencia a una tabla que tienes que actualizar con
triggers.



Saludos