Este código crea un JOB en Oracle que se ejecuta cada 1 hora
BEGIN DBMS_JOB.isubmit ( job => 99, what => 'procedimiento(''soy un parametro'');', next_date => SYSDATE, interval => 'SYSDATE + 1/24 /* 1 Hour */'); COMMIT; END;
Este código crea un JOB en Oracle que se ejecuta cada 1 hora
BEGIN DBMS_JOB.isubmit ( job => 99, what => 'procedimiento(''soy un parametro'');', next_date => SYSDATE, interval => 'SYSDATE + 1/24 /* 1 Hour */'); COMMIT; END;
Existe un error reportado a MySQL (https://bugs.mysql.com/bug.php?id=16494) que sucede en el momento que se establece una columna a NULL. En muchos de los casos sucede que envía el error que la columna no existe.
Dependiendo del tipo de dato se debe tener una forma de resolver el problema. Aun cuando no es lo mismo establecer NULL a una columna String que establecer » (vacío), pero debes considerarlo como solución cuando te aparezca el problema.
Un problema que me sucedio radicó en que requería hacer desde una vista ya existente un INSERT INTO hacia una tabla destino, esta vista tenía una columna que hacía de identificador, pero al ver la consulta me di cuenta que utilizaba un UNION, era más o menos así:
insert into tabla (id, col1) select rownum id, xyz from t1 union select rounum id, zyx from t2
El problema no era la consulta ya que esta arrojaba resultado, la problematica se encontraba que el id generado no era unico, ya que en ambos casos el rownum partía de 1, lo que provocaba un error en el insert into.
La solución fue, crear un trigger que incrementara una secuencia y el valor lo depositara en ID,
create or replace trigger TRG_tabla before insert on tabla for each row begin if inserting then if :NEW.ID is null then select SQ_tabla.nextval into :NEW.ID from dual; end if end if end;
eliminar del insret into la columna ID, y luego ejecutar el insert into, con esto se solución el error de clave duplicada.
insert into tabla (col1) select xyz from t1 union select zyx from t2
En oracle existe igual la posibilidad de hacer CAST de los tipos de datos en una consulta, por ejemplo:
select cast(12.2 as NUMBER(10,5)) FROM DUAL; select cast('usuario' as VARCHAR2(100)) FROM DUAL;
Esto es util para cuando en algun resultado de una vista se esta esperando un tipo de datos especifico. Por ejemplo, si hacemos un select sobre una columna varchar2(100) la vista no será creada con una columna varchar2(100), sino que será creada con el maximo largo existente dentro de la columna que no necesariamente es 100, por lo mismo, para evitar posibles errores de conversión de tipos entre vistas o database link, es bueno uitlizar este tipo de solución.
Cuando uno elimina desde la interfaz de GFoge un usuario, el usuario realmente no es borrado, sino que queda en un status eliminado (status=2), en general no borro usuarios debido a que estos pertenecen a la historia de los proyectos, pero en algunos casos existen usuarios que se han inscrito de forma spam, por lo que realmente estan en estado pendiente. Cuando existen en ese estado puede ser porque realmente estan incritos coherentemente o es spam. En mi caso los elimino manualmente, y a todos los eliminados les ejecuto en orden el siguiente script ( asumiendo que #id_usuario es el id del usuario)
delete from public.audit_trail where user_id=#id_usuario; delete from public.mailmen where user_id=#id_usuario; delete from public.user_session where user_id=#id_usuario; delete from public.user_preference where user_id=#id_usuario; delete from public.user where user_id=#id_usuario; commit;
En el caso que estuviesemos absolutamente seguros de que todos los eliminados son sólo spam, entonces puede servir el SQL
delete from public.user where status = 2 and unix_name <> 'none';
Para la exportacion de un esquema en PostgreSQL asumiendo que posees el login y password sería
pg_dump -U login -s database > database_schema_create.sql
en donde: