Foros del Web » Programación para mayores de 30 ;) » Bases de Datos General »

Problema con Procedimiento Almacenado en SQL Server 7

Estas en el tema de Problema con Procedimiento Almacenado en SQL Server 7 en el foro de Bases de Datos General en Foros del Web. Hola a tod@s!! Tengo una base de datos para gestionar una explotación de ganado vacuno y hago un procedimiento en el que se actualiza la ...
  #1 (permalink)  
Antiguo 03/06/2004, 07:03
 
Fecha de Ingreso: mayo-2004
Ubicación: Valladolid (Spain)
Mensajes: 81
Antigüedad: 20 años, 6 meses
Puntos: 0
Problema con Procedimiento Almacenado en SQL Server 7

Hola a tod@s!!
Tengo una base de datos para gestionar una explotación de ganado vacuno y hago un procedimiento en el que se actualiza la tabla vacas, poniendo a uno (verdadero) un campo lógico que comprueba si la vaca está preñada. Esto lo hace para todas aquellas vacas cuya fecha de inseminación sea mayor o igual a tres meses. Utilizo un cursor para ello. El procedimiento es sencillo, y no da ningún error (ese es el problema), ya que cuando lo ejecuto me dice el número de filas que han sido afectadas y lo hace bien, pero el problema es que cuando voy a revisarlo a la tabla resulta que no las ha modificado. No logro entender por qué. Os muestro el código:

CREATE PROCEDURE PControlaIns
AS
DECLARE @Cod CHAR(14), @FechIns DATETIME
DECLARE CControlaIns CURSOR FOR SELECT CodVac, FechaInsVac FROM Vacas WHERE DateDiff(m,FechaInsVac,GETDATE())>=3 AND FechaInsVac IS NOT NULL
/*Mediante esta consulta obtengo directamente los registros que hay que modificar, con lo que no tengo que hacer
ninguna comprobación más, basta con recorrer los registros del cursor y actualizar el campo correspondiente en
el registro.*/
BEGIN
OPEN CControlaIns
FETCH CControlaIns INTO @Cod, @FechIns
WHILE @@FETCH_STATUS = 0
BEGIN
UPDATE Vacas SET PreñadaVac='1' WHERE CodVac=@Cod
FETCH NEXT FROM CControlaIns
END
CLOSE CControlaIns
DEALLOCATE CControlaIns
END

--Llamada al procedimiento:
EXEC PControlaIns

por más vueltas que lo doy no logro entender por qué no actualiza.
Si alguien sabe algo le agradecería mucho que me diera su opinión.
(Estoy empezando con esto de los triggers y proc. almacenados y no lo tengo muy claro.)

Saludos
  #2 (permalink)  
Antiguo 03/06/2004, 07:51
 
Fecha de Ingreso: abril-2003
Ubicación: Madrid
Mensajes: 707
Antigüedad: 21 años, 7 meses
Puntos: 0
No utilizo los cursores, acostumbro a hacerlo todo con SELECTS directas, pero creo que necesitas declarar el cursor como actualizable

DECLARE nombreCursor CURSOR
[LOCAL | GLOBAL]
[FORWARD_ONLY | SCROLL]
[STATIC | KEYSET | DYNAMIC | FAST_FORWARD]
[READ_ONLY | SCROLL_LOCKS | OPTIMISTIC]
[TYPE_WARNING]
FOR instrucciónSELECT
[FOR UPDATE [OF nombreColumna [,...n]]]

Esa es la sintaxis completa, supongo que después de tu select, deberías poner FOR UPDATE, puede que también necesites especificar la columna, pero no es seguro

Un saludo
  #3 (permalink)  
Antiguo 03/06/2004, 08:12
 
Fecha de Ingreso: mayo-2004
Ubicación: Valladolid (Spain)
Mensajes: 81
Antigüedad: 20 años, 6 meses
Puntos: 0
Muchas gracias Teri. Es verdad, olvidé ponerle el FOR UPDATE porque sino pones nada por defecto coge el FOR READ ONLY.
Pero ahora tengo otro problema, y es que hay varios registross que modificar, pero sólo modifica el último. Ahora sí que ya no entiendo nada.
Puede alguien decirme por qué se comporta tan raro el cursor??? yo creo que la sintaxis está bien puesta.
Pufffff, ahora sí que no entiendo nada

Un saludo
  #4 (permalink)  
Antiguo 03/06/2004, 08:23
 
Fecha de Ingreso: mayo-2004
Ubicación: Valladolid (Spain)
Mensajes: 81
Antigüedad: 20 años, 6 meses
Puntos: 0
Ya lo he solucionado, poniendo:
FETCH NEXT FROM CControlaIns INTO @Cod, @FechIns
ahora muestra todos, aunque no lo entiendo, por qué debo poner el INTO?? se supone que es opcional, pero si no lo pongo, no funciona bien.

Bueno, el caso es que funciona. Al fin!!!
  #5 (permalink)  
Antiguo 03/06/2004, 10:30
 
Fecha de Ingreso: abril-2003
Ubicación: Madrid
Mensajes: 707
Antigüedad: 21 años, 7 meses
Puntos: 0
Pues el motivo de que solo te actualizara uno, es el como estabas haciendo el UPDATE, 'UPDATE Vacas SET PreñadaVac='1' WHERE CodVac=@Cod', si no actualizas @Cod con el nuevo valor proveniente de tu cursor solo actualizarás el valor del primero, para eso es el INTO, es como si en código hicieras una asignación a la variable desde un recordset.

De todas formas, si quieres un consejo, cambia el cursor por una sola instrucción UPDATE, es más rápido de ejecutar, y aunque ahora tengas pocos registros y no notas diferencia, a la larga lo notarás, los cursores son siempre más lentos.

La SQL quedaría algo así:

UPDATE Vacas SET PreñadaVac='1' WHERE DateDiff(m,FechaInsVac,GETDATE())>=3 AND FechaInsVac IS NOT NULL

lo único es que queda menos claro que cuando lo haces con un cursor, aunque eso depende de quien lea el Procedimiento Almacenado

Un saludo
  #6 (permalink)  
Antiguo 03/06/2004, 11:15
 
Fecha de Ingreso: mayo-2004
Ubicación: Valladolid (Spain)
Mensajes: 81
Antigüedad: 20 años, 6 meses
Puntos: 0
Sí, es verdad, Teri, tienes toda la razón del mundo, sino pongo el INTO no actualiza.
Anda, no había caído de que en este caso no es imprescindible el cursor. Claro, como no se hace ninguna validación más (if,...) basta con ejecutar la SELECT. Creo que lo haré así además es más eficiente.

Gracias, de corazón.
Un saludo
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 14:14.