Fecha de modificacion automatica

Carlos M. Calvelo,

Y si usa un trigger... entonces no tiene por que usar un
procedimiento almacenado.

Con un trigger no tiene que tener en cuenta nada de todo eso.
Las actualicaciones se hacen con una interfaz convencional
y esa columna puede actualizarse 'por si sola'.

Los triggers, por defecto, no se disparan en operaciones en lote, como bulk
insert o cuando usas herramientas como SSIS o DTS. Claro esta que puedes
activarlo, pero piensa en las consecuencias de tener un trigger que se
dispara para una cantiadad grande de filas. En esos casos seria preferible
pasar el valor a la sentencia que actualiza y no depender de un trigger.

En cuanto a usar un procedimiento almacenado, se lo dejo a su eleccion.

Mejor que siga con esa idea, sí.

No se por que tratas de imponer, en vez de proponer.

Y que ventajas tiene hacer

1) exec dbo.usp_upd_t1 4, 'Prueba'

sobre hacer

2) update dbo.t1 set c2='Prueba', fecha_ins_upd=getdate() where c1=4

Creo que ya hemos tocado ese punto otras veces, bien pudieras buscar esa
respuesta o exponer nuevamente tu punto de vista.


AMB


"Carlos M. Calvelo" wrote:

Hola Alejandro,

On 8 sep, 15:47, Alejandro Mesa
wrote:
> Luisa,
>
> Si usas un procedimiento alamacenado para hacer la actualizacion, entonces
> no tienes por que usar un trigger.

Y si usa un trigger... entonces no tiene por que usar un
procedimiento almacenado.

> Claro esta, todas las actualizaciones
> deben hacerse mediante el uso de este procedimiento y/o tener en cuenta que
> esta columna no se actualiza por si sola,

Con un trigger no tiene que tener en cuenta nada de todo eso.
Las actualicaciones se hacen con una interfaz convencional
y esa columna puede actualizarse 'por si sola'.

> de lo contrario deberas seguir con
> la idea de usar un trigger.

Mejor que siga con esa idea, sí.

>
> create procedure dbo.usp_Upd_t1
> @c1 int,
> c2 varchar(50)
> as
> set nocount on
>
> update dbo.t1
> set c2 = @c2, [fecha_ins_upd] = getdate()
> where c1 = @c1
>
> return @@error
> go
>
> exec dbo.usp_upd_t1 4, 'Prueba'
> go
>
> select * from dbo.t1 where c1 = 4
> go
>

Y que ventajas tiene hacer

1) exec dbo.usp_upd_t1 4, 'Prueba'

sobre hacer

2) update dbo.t1 set c2='Prueba', fecha_ins_upd=getdate() where c1=4

?

Con 1) no se puede especificar qué columnas se quieren actualizar.
Ni se puede actualizar un conjunto de registros a la vez. Algo
bastante básico con SQL.
Solo es una forma muchísimo mas restringida de lo que ya
teníamos y no añade ninguna posibilidad nueva.

Saludos,
Carlos

Hola Alejandro,

El Mon, 8 Sep 2008 09:25:01 -0700, Alejandro Mesa escribió:

Los triggers, por defecto, no se disparan en operaciones en lote, como bulk
insert o cuando usas herramientas como SSIS o DTS.

¿Y?

Claro esta que puedes
activarlo, pero piensa en las consecuencias de tener un trigger que se
dispara para una cantiadad grande de filas. En esos casos seria preferible
pasar el valor a la sentencia que actualiza y no depender de un trigger.

En esos casos por los que nadie ha preguntado sería mejor crear un script
para arreglar los estropicios de las operaciones en lote que se saltan los
triggers.

No se por que tratas de imponer, en vez de proponer.

No digas tonterías, hombre.


Saludos
Alfredo

Hola Alejandro,

On 8 sep, 18:25, Alejandro Mesa
wrote:

Carlos M. Calvelo,

> Y si usa un trigger... entonces no tiene por que usar un
> procedimiento almacenado.
> Con un trigger no tiene que tener en cuenta nada de todo eso.
> Las actualicaciones se hacen con una interfaz convencional
> y esa columna puede actualizarse 'por si sola'.

Los triggers, por defecto, no se disparan en operaciones en lote, como bulk
insert o cuando usas herramientas como SSIS o DTS. Claro esta que puedes
activarlo, pero piensa en las consecuencias de tener un trigger que se
dispara para una cantiadad grande de filas. En esos casos seria preferible
pasar el valor a la sentencia que actualiza y no depender de un trigger.

El procedimiento almacenado que tu propones en ciertas
situaciones (aplicaciones) es ŽdisparadoŽ y en otras no.

¿¿Y ahora??

En cuanto a usar un procedimiento almacenado, se lo dejo a su eleccion.

> Mejor que siga con esa idea, sí.

No se por que tratas de imponer, en vez de proponer.

No entiendo a qué viene esta reacción.

> Y que ventajas tiene hacer

> 1) exec dbo.usp_upd_t1 4, 'Prueba'

> sobre hacer

> 2) update dbo.t1 set c2='Prueba', fecha_ins_upd=getdate() where c1=4

Creo que ya hemos tocado ese punto otras veces, bien pudieras buscar esa
respuesta o exponer nuevamente tu punto de vista.

Ah! Entonces ya tendría que estar clarísimo.

Saludos,
Carlos

Hola Alfredo,

On 8 sep, 19:07, Alfredo Novoa wrote:

El Mon, 8 Sep 2008 09:25:01 -0700, Alejandro Mesa escribió:

> No se por que tratas de imponer, en vez de proponer.

No digas tonterías, hombre.

Hala! Ya la has montado! :)

Saludos,
Carlos

Y si usa un trigger... entonces no tiene por que usar un
procedimiento almacenado.

Solo como aclaracion, un trigger tambien es un procedimiento almacenado solo
que automático. No?

Y que ventajas tiene hacer
1) exec dbo.usp_upd_t1 4, 'Prueba'
sobre hacer
2) update dbo.t1 set c2='Prueba', fecha_ins_upd=getdate() where c1=4

actualizar.
Ni se puede actualizar un conjunto de registros a la vez. Algo
bastante básico con SQL.

Tambien como aclaración, creo que en la version 2008 ya se pueden mandar
conjuntos de registros a un procedimiento almacenado cualquiera con los
parametros tipo tabla.

saludos