Procedimeinto con variables que no se asignan

[Tio]

hola

quiero ejecutar un procedimiento almacenado que muestro a continuacion y veo que me devuelve los camps siempre vacios... el caso es que la tabla tiene contenido, peor no se que hago mal....
ave rsi me pueden ayudar.

CREATE PROCEDURE `contabilidad`.`DiarioLeeRegistro` (IN idRegistro INT,
OUT fecha DATE,
OUT idCuenta INT,
OUT descripcion VARCHAR(45),
OUT importe decimal(10,2))
BEGIN

SELECT
fecha = Fecha,
idCuenta = IdCuenta,
descripcion = Descripcion,
importe = Importe
FROM diario
WHERE Id = idRegistro;
END

[gnzsoloyo]

Es que esa no es la forma de asignar datos de una consulta a variables. En ningún DBMS.

Código SQL:

SELECT Fecha, IdCuenta, Descripcion, Importe
FROM diario
WHERE Id = idRegistro
INTO fecha, idCuenta, descripcion, importe;
 

Por otro lado, no uses los mismos nombres de variables que los que tienen las columnas. MySQL puede confundirlos por que los evalúa jerárquicamente.
Usa nombres distintos

[Tio]

Muchas gracias..... es que no encontraba la forma correcta de hacerlo, puse ese código para que se entendiese lo que pretendía:

He modificado como me indicas y cuando ejecuto ésto me sigue devolviendo los campos vacios, pero el registro 5 está con contenido.

use contabilidad;
call DiarioLeeRegistro (5,@Fecha ,@IdCuenta ,@Descripcion , @Importe );
select @Fecha, @IdCuenta, @Descripcion, @Importe;

¿que estoy haciendo mal?...en teoría debería devolver la información del registro 5.

[Tio]

Solucionado, me faltó cambiar los nombres de las variables, creí que MySql no se liaría si diferenciaba mayúsculas de minúsculas.

[gnzsoloyo]

Probablemente es una confusión entre un lenguaje de programación y el SQL. el SQL en general no diferencia mayusculas/minusculas en las variables. Sí lo hace en tablas, columnas, bases y otros objetos de BBDD, en el caso de que el servidor esté corriendo bajo Linux, por ejemplo (es decir, depende del S.O.).
En algunos casos pueden darse diferenciaciones cuando el valor se toma de un campo te tipo CHAR, VARCHAR o TEXT, si el mismo está definido para eso.

En cualquier caso, como te recomendé, no debes usar nunca los mismos nombres para variables que para columnas, tablas o bases, porque el SQL asume que el objeto en la consulta es en primer lugar una columna, luego una tabla, una base y sólo si ninguno de los invocados contiene ese nombre lo interpretará como variable.
O sea, al final.

Por otro lado, ten mucho cuidado con el uso de variables de sesión (las que comienzan con "@", porque esas variables no se declaran, no tienen tipo y no mueren al terminar el SP. Pertenecen al ámbito de la conexión.
Esto significa entre otras cosas que matienen su valor entre ejecuciones del SP que las use (con lo que pueden llevar y traer basusa si no se las incializa antes), y además que pueden prestarse a confusión si tienen el mismo nombre que otra variable local declarada en el SP.
Esto último significa que "@v_id" e "v_id", para MySQL son variables diferentes.