Fecha de modificacion automatica
Luisa Goicochea
Segun pruebas veo que puedo definir un campo DateTime() y ponerle como valor
default la funcion GetDate() para que me incluya alli automaticamente la
fecha-hora de alta de un registro insertado.
Pero, estoy interesada en ver si hay alguna manera de cuando se manda a
actualizar el registro guardar en otro campo automaticamente la fecha-hora
de modificacion ?
La idea es que se haga automaticamente desde el servidor (getdate()) y no
mandarsela llena desde la aplicacion.
Se puede eso?
Rubén Garrigós
Puedes conseguir esto fácilmente con un trigger INSTEAD OF UPDATE que te
actualice dicha columna de forma automática sin tenerla que especificar en el
update.
Rubén Garrigós
Solid Quality Mentors
Luisa Goicochea
Bien, lo voy a chequear. Una pregunta: no afecta el rendimiento
significativamente ese metodo verdad ?
Gracias por la ayuda
"Rubén Garrigós" <RubnG...@discussions.microsoft.com> escribió en el
mensaje news:D4DBEFD8-2091-47F3...@microsoft.com...
Rubén Garrigós
El impacto en el rendimiento depende de muchos factores como si las
operaciones de update se realizan registro a registro o orientadas a
conjuntos, si la columna datetime está o no indexada, la frecuencia de
actualizaciones, el número de registros afectados, etc.
En principio con un trigger instead of lo que vas a conseguir a efectos
prácticos es tener un procedimiento almacenado (el trigger) que se ejecute
cuando actualizas filas. Si dicho trigger es eficiente, el rendimiento no se
resentirá mucho respecto al del update sin trigger. Si internamente hicieras
algo como añadir un cursor para actualizar la fecha de todos los registros
actualizados, entonces el rendimiento sería mucho peor.
Por tanto mi recomendación es que el cuerpo del trigger sea lo más sencillo
posible (básicamente una reescritura del update de forma que añadas la
columna de la fecha con valor getDate() en la clausula SET del update)
Alejandro Mesa
Si usas un procedimiento alamacenado para hacer la actualizacion, entonces
no tienes por que usar un trigger. 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, de lo contrario deberas seguir con
la idea de usar un trigger.
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
...
AMB
Carlos M. Calvelo
On 8 sep, 15:47, Alejandro Mesa
<AlejandroM...@discussions.microsoft.com> 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
Alejandro Mesa
> 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
Alfredo Novoa
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
Carlos M. Calvelo
On 8 sep, 18:25, Alejandro Mesa
<AlejandroM...@discussions.microsoft.com> 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
Carlos M. Calvelo
Hala! Ya la has montado! :)
Saludos,
Carlos
Pedro
>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
Gustavo Larriera (MVP)
--
Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Carlos M. Calvelo
On 9 sep, 16:36, "Pedro" <pedritot...@hotmail.es> wrote:
> >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?
Si, así es. Tanto los triggers como los procedimientos almacenados
son procedimientos. Y tan 'almacenados' son unos como los otros.
Son todos procedimientos a pesar de las diferencias (parametros,
resultados, tablas deleted/inserted, modo de activarse, ...).
>
> >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
Por cierto, como se supone que 'fecha_ins_upd' es actualizada
por el procedimiento almacenado o el trigger, entonces
aquí yo tendría que haber comparado
exec dbo.usp_upd_t1 4, 'Prueba'
con
update dbo.t1 set c2='Prueba' where c1=4
(sin mayor importancia, solo por puntualizar)
>
> >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.
>
Ok. Eso está muy bien. Tablas (conjuntos de registros, relaciones)
son la estructura lógica de datos fundamental y me parece normal que
en el lenguaje se puedan tener variables de esos tipos, pasar sus
valores a funciones y obtenerlos como resultados.
Pero piensa que en una consulta se puede expresar mucho más que eso.
Estaríamos comparando un lenguage con una forma de llamar
procedimientos.
Pero también como aclaración, si hablamos de la interfaz, entonces
una base de datos es un conjunto de tablas (vistas incluidas).
Con ese conjunto de tablas y un lenguaje relacional (en este caso
lo que pretende ser SQL) se pueden derivar nuevas tablas (consultas)
y actualizar las existentes (insert/update/delete). Eso es todo lo
que se debe ver desde fuera (lenguaje + conjunto de tablas).
De los procedimientos almacenados (los que forman parte de la
interfaz) yo suelo decir que son aplicaciones que van con la base
de datos. Nada de malo en ello pero, aunque físicamente muy
conveniente, no es lógicamente ese el lugar que le corresponde.
Ni deben tratar de reemplazar una interfaz mucho mas potente.
El tema ya ha sido discutido en este foro. Y no ha faltado el
toque emocional. :)
Saludos,
Carlos
Alfredo Novoa
El Tue, 9 Sep 2008 10:48:02 -0700, Gustavo Larriera (MVP) escribió:
> No, un trigger no es un procedimiento almacenado automático.
Supongo que habrá querido decir que es un procedimiento almacenado que se
dispara automáticamente.
Saludos
Alfredo
Maxi Accotto
funciones, pero tienen distintas aplicaciones , usos y funcionan totalmente
distintos.
Por ejemplo a un trigger no le podes poner parametros de entrada niu salida,
por ejemplo un trigger genera automaticamente tablas inserted y deleted, y
mucho mas!
Por mas que en ambos escribas a la larga codigo TSQL, no son sinonimos.
Una aclacion, pasar array a los SP se puede desde la version 2000, mirar
este link
http://www.sommarskog.se/arrays-in-sql.html
--
Saludos
-----------------------------------------------------------------------
Maxi Accotto
Microsoft MVP en SQLServer
SQltotalconsulting
-------------------------------------------------------------------
"Pedro" <pedri...@hotmail.es> escribió en el mensaje de
noticias:u8pM6loE...@TK2MSFTNGP06.phx.gbl...
Pedro
> Una aclacion, pasar array a los SP se puede desde la version 2000, mirar
> este link
>
> http://www.sommarskog.se/arrays-in-sql.html
>
>
No hablaba de array sino de parametros tipo tabla. Eso solo se hace desde la
version 2008.