Un problema bastante común cuando realizamos un proyecto que tiene lectura y/o escritura desde una dts a un oracle, es que cuando se crea un job de ejecución se pierde el password de acceso a oracle. Una solución a esto es editar las conexiones del paquete dentro del job y ponerle a mano el password. El problema es que cada vez que cambiamos la dts se tiene que hacer lo mismo. La solución definitiva ha esto es crear una variable de tipo string en el paquete que contiene la cadena de conexión completa. Dicha cadena sería: "Data Source=;User ID=;Provider=OraOLEDB.Oracle.1;Persist Security Info=True;Password=;" Una vez hecho esto, hay que entrar en la propiedades de la conexión en el "Connection Manager" (parte inferior de la dts)y añadir una expresión clicando con el ratón en la elipse. Añadir una expresión de tipo "ConnectionString" y arrastar en el diálogo la varible que hemos rellenado antes. Ya está. Saludos!

Hola *ALL.

Tengo un problema que está empezando a afectar mi sistema nervioso porque no consigo saber la razón.
Tengo una procedure en Oracle (10.2) que llama a 3 procedures más.
Cuando termina de ejecutar la primera y se dispone a ejecutar la segunda, aparece el siguiente mensaje:

Connecting to the database XXXXXX.DWH.
ORA-04068: se ha anulado el estado existente de los paquetes
ORA-04065: stored procedure "DWH.P_IMS_MENSUAL_PRESENTACION" no se ha ejecutado porque se ha modificado o borrado
ORA-06508: PL/SQL: no se ha encontrado la unidad de programa llamada : "DWH.P_IMS_MENSUAL_PRESENTACION"
ORA-06512: en "DWH.P_LANZA_COMERCIAL", línea 25
ORA-06512: en línea 2
Process exited.
Disconnecting from the database XXXXXX.DWH.

Si comento la primera procedure, la segunda (la que falla) se ejecuta perfectamente.
No hace falta decir que las procedures "estan perfectas" y no tienen ni un solo fallo.
Alguna sugerencia ??

Muchas gracias !!
JosiMac

Hola a todos.

Es sabido por todo el mundo de las capacidades de particionamiento que posee Oracle desde sus mas antiguos releases. En Sql Server 2000 existia una especie de "chapuza" para poder hacerlo mediante restricciones "CHECK" en los campos y utilizando vistas mediante UNIONS.

El panorama en SQL Server 2005 a mejorado un poco respecto a eso.
No puedo dar fe absoluta sobre las ventajas de utilizar dicho particionamiento (lo usé en una tabla de hechos con pocos millones de registros) pero al menos es una tecnología más reciente que las "vistas".