Depurar Procedimiento
Espero no molestarte, otra vez en problemas, me ayudas a depurar este procedimiento que me esta volviendo loco, por favor, la tabla es esta:
CREATE TABLE visual (
Id_v INT NOT NULL PRIMARY KEY,
fecha DATE,
equipo char (25) NOT NULL,
placa char (50),
recubrimiento char (50),
estado_recubrimiento char (100),
accesorios char (100),
anclajes_bases char (100),
puesta_tierra char (100),
corrosion_ext char (100),
escalera_acceso char (100),
uniones_soldadas char (100),
foto BLOB,
diagrama BLOB,
observaciones char (100),
CONSTRAINT ClaveExtvisualnombre_equ FOREIGN KEY (equipo) REFERENCES equipos ON DELETE CASCADE);
CREATE SEQUENCE seq_visual
start WITH 1
increment BY 1
nomaxvalue;
CREATE OR REPLACE TRIGGER trig_visual
BEFORE INSERT ON visual
FOR EACH ROW
BEGIN
SELECT seq_visual.NEXTVAL INTO :new.Id_v FROM dual;
END;
/
el procedimiento es este:
CREATE OR REPLACE PROCEDURE INSERTA_visual (v_Id_v INT,
v_fecha DATE,
v_equipo CHAR,
v_placa CHAR,
v_recubrimiento CHAR,
v_estado_recubrimiento CHAR,
v_accesorios CHAR,
v_anclajes_bases CHAR,
v_puesta_tierra CHAR,
V_corrosion_ext CHAR,
v_escalera_acceso CHAR,
v_uniones_soldadas CHAR,
v_foto VARCHAR2,
v_diagrama VARCHAR2,
v_observaciones CHAR)
IS
--
l_bfile BFILE;
l_blob BLOB;
l_bfile2 BFILE;
l_blob2 BLOB;
--
BEGIN
--
INSERT INTO VISUAL
(Id_v, fecha, equipo,placa,recubrimiento,estado_recubrimiento, accesorios,anclajes_bases, puesta_tierra,corrosion_ext,escalera_acceso,uniones_soldadas,foto,diagrama,observaciones)
VALUES
(v_Id_v, to_date(v_fecha), v_equipo, v_placa, v_recubrimiento, v_estado_recubrimiento, v_accesorios, v_anclajes_bases, v_puesta_tierra,v_corrosion_ext, v_escalera_acceso,v_uniones_soldadas,EMPTY_BLOB(),EMPTY_BLOB(),v_observaciones);
RETURN foto, diagrama INTO l_blob, l_blob2;
--
l_bfile := BFILENAME ('VISUAL', v_foto);
--
DBMS_LOB.fileopen(l_bfile, Dbms_Lob.File_Readonly);
DBMS_LOB.Loadfromfile(l_blob,l_bfile,DBMS_LOB.getlength(l_bfile));
DBMS_LOB.fileclose(l_bfile);
--
l_bfile2 := BFILENAME ('DIAGRAMA', v_diagrama);
--
DBMS_LOB.fileopen(l_bfile2, Dbms_Lob.File_Readonly);
DBMS_LOB.Loadfromfile(l_blob2,l_bfile2,DBMS_LOB.getlength(l_bfile2));
DBMS_LOB.fileclose(l_bfile2);
--
COMMIT;
--
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE( SQLERRM ); -- Muestra un mensaje de error si se produce
--
ROLLBACK;
---
RAISE;
--
END INSERTA_visual;
/
E inserto la información así:
exec inserta_visual ('','19/02/2008','AB107','No presenta','Altos Solidos','Degradación y entizamiento','Entizamiento, desprendimiento del recubrimiento','Silla metalica en buen estado, pernos de anclaje con corrosión generalizada por acumulación de agua','Buen estado','Buen estado','','sin indicaciones','ASEP107_GENERAL.jpg','ASEP107_DIAGRAMA.jpg','');
No se que esta mal lo he revisado varias veces pero no encuentro la falla, como vez la tabla tiene un disparador para en el primer campo que funciona como un autonumérico, por eso en la inserción esta bacio. Pero no se porque no corre.
CREATE TABLE visual (
Id_v INT NOT NULL PRIMARY KEY,
fecha DATE,
equipo char (25) NOT NULL,
placa char (50),
recubrimiento char (50),
estado_recubrimiento char (100),
accesorios char (100),
anclajes_bases char (100),
puesta_tierra char (100),
corrosion_ext char (100),
escalera_acceso char (100),
uniones_soldadas char (100),
foto BLOB,
diagrama BLOB,
observaciones char (100),
CONSTRAINT ClaveExtvisualnombre_equ FOREIGN KEY (equipo) REFERENCES equipos ON DELETE CASCADE);
CREATE SEQUENCE seq_visual
start WITH 1
increment BY 1
nomaxvalue;
CREATE OR REPLACE TRIGGER trig_visual
BEFORE INSERT ON visual
FOR EACH ROW
BEGIN
SELECT seq_visual.NEXTVAL INTO :new.Id_v FROM dual;
END;
/
el procedimiento es este:
CREATE OR REPLACE PROCEDURE INSERTA_visual (v_Id_v INT,
v_fecha DATE,
v_equipo CHAR,
v_placa CHAR,
v_recubrimiento CHAR,
v_estado_recubrimiento CHAR,
v_accesorios CHAR,
v_anclajes_bases CHAR,
v_puesta_tierra CHAR,
V_corrosion_ext CHAR,
v_escalera_acceso CHAR,
v_uniones_soldadas CHAR,
v_foto VARCHAR2,
v_diagrama VARCHAR2,
v_observaciones CHAR)
IS
--
l_bfile BFILE;
l_blob BLOB;
l_bfile2 BFILE;
l_blob2 BLOB;
--
BEGIN
--
INSERT INTO VISUAL
(Id_v, fecha, equipo,placa,recubrimiento,estado_recubrimiento, accesorios,anclajes_bases, puesta_tierra,corrosion_ext,escalera_acceso,uniones_soldadas,foto,diagrama,observaciones)
VALUES
(v_Id_v, to_date(v_fecha), v_equipo, v_placa, v_recubrimiento, v_estado_recubrimiento, v_accesorios, v_anclajes_bases, v_puesta_tierra,v_corrosion_ext, v_escalera_acceso,v_uniones_soldadas,EMPTY_BLOB(),EMPTY_BLOB(),v_observaciones);
RETURN foto, diagrama INTO l_blob, l_blob2;
--
l_bfile := BFILENAME ('VISUAL', v_foto);
--
DBMS_LOB.fileopen(l_bfile, Dbms_Lob.File_Readonly);
DBMS_LOB.Loadfromfile(l_blob,l_bfile,DBMS_LOB.getlength(l_bfile));
DBMS_LOB.fileclose(l_bfile);
--
l_bfile2 := BFILENAME ('DIAGRAMA', v_diagrama);
--
DBMS_LOB.fileopen(l_bfile2, Dbms_Lob.File_Readonly);
DBMS_LOB.Loadfromfile(l_blob2,l_bfile2,DBMS_LOB.getlength(l_bfile2));
DBMS_LOB.fileclose(l_bfile2);
--
COMMIT;
--
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE( SQLERRM ); -- Muestra un mensaje de error si se produce
--
ROLLBACK;
---
RAISE;
--
END INSERTA_visual;
/
E inserto la información así:
exec inserta_visual ('','19/02/2008','AB107','No presenta','Altos Solidos','Degradación y entizamiento','Entizamiento, desprendimiento del recubrimiento','Silla metalica en buen estado, pernos de anclaje con corrosión generalizada por acumulación de agua','Buen estado','Buen estado','','sin indicaciones','ASEP107_GENERAL.jpg','ASEP107_DIAGRAMA.jpg','');
No se que esta mal lo he revisado varias veces pero no encuentro la falla, como vez la tabla tiene un disparador para en el primer campo que funciona como un autonumérico, por eso en la inserción esta bacio. Pero no se porque no corre.
1 Respuesta
Respuesta de neosys
1
Al inicio me pareció vivir un 'déjà vu' al leerlo. Como pensando ... "Esto ya lo he contestado antes ... Y revisandop era así.
NO recordaba que podrías tener algún problema, y que te fallase ...
Te daré unos consejos y algo que veo mal desde el inicio ...
Primero : Siempre hay que detectar los problemas creando un mecanismo de traza o que te devuelva un error.
Eso te hará guiar hasta donde se encuentra el problema, y en muchos casos el camino que va tomando ...
Creo recordar que en su momento, a parte de corregirte el procedimiento que eme enviaste, t ehice algunas recomendaciones ... Síguelas, es un consejo por experiencia -sólo por eso, no porque sepa más o menos yo, al contrario-.
Por lo tanto, utilizaremos un programa de 'debugger' -podías usar el TOAD, que te permite hacer muchas cosas, es de pago, y mucha gente lo usa, permite hacer muchísimas cosas más, que tan sólo 'debugger-ar'-.
Pero mejor a la 'vieja usanza' o 'vieja escuela'.
UTILIZA EL : dbms_output.put_line( <Texto_con o sin varibeles );
Eso si. Una vez puesto, ejecutalo en un sitio donde puedas activar el SERVEROUTPUT ON.
Siguiendo con la 'vieja escuela' usaremso el 'sqlplus' ... Entonces harás :
En el procedimemto que has creado tienes, tal y como te dije, la línea dentro del control de 'EXCEPTION' de :
DBMS_OUTPUT.PUT_LINE( SQLERRM );
Que está muy bien ... pero que cuando lo ejecutas, seguro que no ves ningún mensaje!
Entonces desde el 'sqlplus' coloca como linea inicial (una vez conectado) :
SET SERVEROUTPUT ON SIZE 1000000
LUEGO ejecuta el procedimiento como lo haces :
Exec ...
Verás como al finalizar te está dando un mensaje de error! Y ahí tienes una pista de que algo está funconando mal.
Si deseas saber en que punto, se procuce ... Puedes ir metiendo trazas en el procedimiento de (por ejemplo) :
dbms_output.put_line('Ahora inserto');
o
dbms_output.put_line( 'la varible v_var tiene el valor de :'||v_var);
Etc.
Segundo : NUNCA te fíes de los formatos por defecto de variables tipo DATE o NUMBER.
Piensa que segun l ainstalación o el Administrador puedes tener que el formato cambia (o el Set de Caracteres elegido para el Idioma de la instalación que les interesa).
Por tanto, nada de pasar 'string' o cadena de caracteres como 'DD/MM/YYYY', o Números como 3,5 ... porque te puedes llevar la desagradable sorpresa de que la máscara por defecto para los tipo DATE sea 'DD-MON-YYYY' o 'YYYYMMDD' y para los números que en lugar de la ',' -coma- como indicador de decimales sea un '. ' Punto (que es lo más normal).
Así que si trabajas con estos tipos de datos, mejor pasarlos a DATE o a NUMBER para no encontrarte sorpresas ...
Aquí por ejemplo, cuando ejecutas el procedimiento indicas :
exec inserta_visual( '', '19/02/2008', ... etc);
Veamos el procedimiento ...
El segundo parámetro es :
v_fecha DATE
Y le estás pasando un VARCHAR2!
Pero lo más seguro es que aquí no te dé un error, ya que por defecto en tu BB. DD. Hey esa máscara para las fechas ... Oracle hará una operación de 'casting' y la acoplará sin ningún problema. Pero en otras instalaciones ... puede que tengas problemas ...
Pero seguimos con lo que tienes :
Si seguimos leyendo el PROCEDIMIENTO ... cuando INSERTAS :
Ohhhhhhhh! Tengo esa misma variable 'v_fecha' que es de tipo DATE y al indertar, estoy aplicándole una operación de conversión a FECHA!
values ('', to_date(v_fecha), ......
¿Ves el error? Y este error lo detecta PLSQL y sale el error ...
Si hubieras activado el 'SET SERVEROUTPUT ON ...' hubieses visto al ejecutar :
ERROR XXXX : Tipo de dato incorrecto o de conversión
O un error parecido.
Me he alargado un poco porque así, te he podido explicar como 'trazear o debugge-ar' un procedimiento, o código PLSQL.
Y me ha servido también para explicarte la IMPORTANCIA de que no uses definiciones por defecto de máscara en algunos datos ... TRABAJA CON EL DATO YA EN SU ESTADO o TRANSFÓRMALO CON LA MÁSCARA que tú quieras darle!
En este caso como ya has hecho el CASTING y Acepta esta MACARA de FECHA, lo único que tendrías que hacer es :
- Quitar el 'to_date(v_fecha)' y poner solo 'v_fecha' ya que ya la tienes de tipo DATE!
Lo correcto es (a mi modo de ver ...) :
O en la llamada ya pones : exec Inserta_visual( '', to_date( '18/02/2008', 'DD/MM/YYYY'), ..., etc);
O defines el parámetro 'v_fecha' como VARCHAR2 y siempre que tengas que hacer una operación con él de tipo date aplicar la función ...
Insert ...
Values ( '', to_date('18/02/2008', 'DD/MM/YYYY', .... etc);
Espero que entiendas toda la larga explicación que te he dado. Pero si sigues los pasos, tu 'soft' será migrable a cualquier tipo de instalación (independientemente del LANGUAGE definido o la máscara por defecto).
Y respecto a DEPURAR el CÓDIGO, sólo decirte que hay un estudio que dice que PROGRAMAR es tan sólo un 30% del 70% de tiempo que tienes que dedicar a analizar los errores y depurarlos! (Algunos más pesimistas como yo cambiaría esos porcentajes por 10% vs 90%).
Elimina la instrucción de to_date en el insert. Mira el resto de variables y activa lo de las trazas!
Aunque luego reflexiones y apliques otra filosofía a la hora de desarrollar.
(Mira todas las variables ... y tipos ... eh!).
Ya me dirás algo.
Un Saludo
Ramón
NOTA : Si te sigue fallando ... activa el debugger (SET SERVEROUTPUT ON) y mándame el tipo de error (numero y texto) que te sale al ejecutarlo.
NO recordaba que podrías tener algún problema, y que te fallase ...
Te daré unos consejos y algo que veo mal desde el inicio ...
Primero : Siempre hay que detectar los problemas creando un mecanismo de traza o que te devuelva un error.
Eso te hará guiar hasta donde se encuentra el problema, y en muchos casos el camino que va tomando ...
Creo recordar que en su momento, a parte de corregirte el procedimiento que eme enviaste, t ehice algunas recomendaciones ... Síguelas, es un consejo por experiencia -sólo por eso, no porque sepa más o menos yo, al contrario-.
Por lo tanto, utilizaremos un programa de 'debugger' -podías usar el TOAD, que te permite hacer muchas cosas, es de pago, y mucha gente lo usa, permite hacer muchísimas cosas más, que tan sólo 'debugger-ar'-.
Pero mejor a la 'vieja usanza' o 'vieja escuela'.
UTILIZA EL : dbms_output.put_line( <Texto_con o sin varibeles );
Eso si. Una vez puesto, ejecutalo en un sitio donde puedas activar el SERVEROUTPUT ON.
Siguiendo con la 'vieja escuela' usaremso el 'sqlplus' ... Entonces harás :
En el procedimemto que has creado tienes, tal y como te dije, la línea dentro del control de 'EXCEPTION' de :
DBMS_OUTPUT.PUT_LINE( SQLERRM );
Que está muy bien ... pero que cuando lo ejecutas, seguro que no ves ningún mensaje!
Entonces desde el 'sqlplus' coloca como linea inicial (una vez conectado) :
SET SERVEROUTPUT ON SIZE 1000000
LUEGO ejecuta el procedimiento como lo haces :
Exec ...
Verás como al finalizar te está dando un mensaje de error! Y ahí tienes una pista de que algo está funconando mal.
Si deseas saber en que punto, se procuce ... Puedes ir metiendo trazas en el procedimiento de (por ejemplo) :
dbms_output.put_line('Ahora inserto');
o
dbms_output.put_line( 'la varible v_var tiene el valor de :'||v_var);
Etc.
Segundo : NUNCA te fíes de los formatos por defecto de variables tipo DATE o NUMBER.
Piensa que segun l ainstalación o el Administrador puedes tener que el formato cambia (o el Set de Caracteres elegido para el Idioma de la instalación que les interesa).
Por tanto, nada de pasar 'string' o cadena de caracteres como 'DD/MM/YYYY', o Números como 3,5 ... porque te puedes llevar la desagradable sorpresa de que la máscara por defecto para los tipo DATE sea 'DD-MON-YYYY' o 'YYYYMMDD' y para los números que en lugar de la ',' -coma- como indicador de decimales sea un '. ' Punto (que es lo más normal).
Así que si trabajas con estos tipos de datos, mejor pasarlos a DATE o a NUMBER para no encontrarte sorpresas ...
Aquí por ejemplo, cuando ejecutas el procedimiento indicas :
exec inserta_visual( '', '19/02/2008', ... etc);
Veamos el procedimiento ...
El segundo parámetro es :
v_fecha DATE
Y le estás pasando un VARCHAR2!
Pero lo más seguro es que aquí no te dé un error, ya que por defecto en tu BB. DD. Hey esa máscara para las fechas ... Oracle hará una operación de 'casting' y la acoplará sin ningún problema. Pero en otras instalaciones ... puede que tengas problemas ...
Pero seguimos con lo que tienes :
Si seguimos leyendo el PROCEDIMIENTO ... cuando INSERTAS :
Ohhhhhhhh! Tengo esa misma variable 'v_fecha' que es de tipo DATE y al indertar, estoy aplicándole una operación de conversión a FECHA!
values ('', to_date(v_fecha), ......
¿Ves el error? Y este error lo detecta PLSQL y sale el error ...
Si hubieras activado el 'SET SERVEROUTPUT ON ...' hubieses visto al ejecutar :
ERROR XXXX : Tipo de dato incorrecto o de conversión
O un error parecido.
Me he alargado un poco porque así, te he podido explicar como 'trazear o debugge-ar' un procedimiento, o código PLSQL.
Y me ha servido también para explicarte la IMPORTANCIA de que no uses definiciones por defecto de máscara en algunos datos ... TRABAJA CON EL DATO YA EN SU ESTADO o TRANSFÓRMALO CON LA MÁSCARA que tú quieras darle!
En este caso como ya has hecho el CASTING y Acepta esta MACARA de FECHA, lo único que tendrías que hacer es :
- Quitar el 'to_date(v_fecha)' y poner solo 'v_fecha' ya que ya la tienes de tipo DATE!
Lo correcto es (a mi modo de ver ...) :
O en la llamada ya pones : exec Inserta_visual( '', to_date( '18/02/2008', 'DD/MM/YYYY'), ..., etc);
O defines el parámetro 'v_fecha' como VARCHAR2 y siempre que tengas que hacer una operación con él de tipo date aplicar la función ...
Insert ...
Values ( '', to_date('18/02/2008', 'DD/MM/YYYY', .... etc);
Espero que entiendas toda la larga explicación que te he dado. Pero si sigues los pasos, tu 'soft' será migrable a cualquier tipo de instalación (independientemente del LANGUAGE definido o la máscara por defecto).
Y respecto a DEPURAR el CÓDIGO, sólo decirte que hay un estudio que dice que PROGRAMAR es tan sólo un 30% del 70% de tiempo que tienes que dedicar a analizar los errores y depurarlos! (Algunos más pesimistas como yo cambiaría esos porcentajes por 10% vs 90%).
Elimina la instrucción de to_date en el insert. Mira el resto de variables y activa lo de las trazas!
Aunque luego reflexiones y apliques otra filosofía a la hora de desarrollar.
(Mira todas las variables ... y tipos ... eh!).
Ya me dirás algo.
Un Saludo
Ramón
NOTA : Si te sigue fallando ... activa el debugger (SET SERVEROUTPUT ON) y mándame el tipo de error (numero y texto) que te sale al ejecutarlo.
