Jobs en Oracle, .NET y errores con el idioma

Hola,

Siguiendo con el post anterior me pasó algo muy curioso, tenía unos Procedimientos Almacenados (SP) con unos parámetros de fecha, y a pesar de que iban como una cadena texto fijo, a la hora de llegar a ejecutarse en Oracle me fallaban.

Ejemplo: paquete.nombreSP('M', '01/01/2003', '31/12/'TO_CHAR(sysdate,'RRRR'),NULL);

Si el programa se ejecutaba en un SO en español funcionaba sin problemas, el fallo se producía cuando se ejecutaba en un SO en ingles que entonces se producía la siguiente excepción en Oracle:

ORA-12012: error on auto execute of job 2513

ORA-01843: not a valid month

ORA-06512: at line 1

Para solucionarlo es necesario añadir un poco de código respecto al que se vió en el post anterior que lo que va a hacer es cambiar la cultura del thread que llama a Oracle y lo vamos a forzar a que siempre sea en español (de España) y de esta manera Oracle 'se lo traga' sin problemas.

En el constructor ponemos esto:

Thread.CurrentThread.CurrentCulture = new CultureInfo("es-ES");

Y cuando ponemos el código que 'ataque' a la base de datos añadimos:

cmdSet.Connection = conn;

cmdSet.CommandType = System.Data.CommandType.Text;

cmdSet.CommandText = "ALTER SESSION SET NLS_DATE_FORMAT='DD/MM/RR'";

Finalmente, antes de ejecutar la 'query' que llama al 'job' de Oracle será necesario poner la siguiente línea:

cmdSet.ExecuteNonQuery();

En resumen, lo que estamos haciendo es ejecutar una sentencia SQL en Oracle antes de lanzar nuestro 'job' para que la sesión asociada a nuestra conexión la cambie a Español con el formato de fecha día/mes/año.

Si os pasa luego no digáis que no os avise ;-)

Salu2

Jobs, Oracle y .NET

Hola,

A modo introductorio de un post posterior a este voy a contaros como lanzar un job en Oracle desde un código .NET gracias al SP que se nos proporciona DBMS_JOB.submit

En su forma más básica sería algo parecido a esto:

Oracle.DataAccess.Client.OracleConnection conn = new Oracle.DataAccess.Client.OracleConnection(connString);

Oracle.DataAccess.Client.OracleCommand cmd = new Oracle.DataAccess.Client.OracleCommand();

Oracle.DataAccess.Client.OracleParameter paramID = new Oracle.DataAccess.Client.OracleParameter();

Oracle.DataAccess.Client.OracleParameter paramOpID = new Oracle.DataAccess.Client.OracleParameter();

Oracle.DataAccess.Client.OracleParameter paramOpWhat = new Oracle.DataAccess.Client.OracleParameter();

cmd.Connection = conn;

cmd.CommandType = System.Data.CommandType.StoredProcedure;

cmd.CommandText = "DBMS_JOB.submit";

paramOpID.ParameterName = "id";

paramOpID.OracleDbType = Oracle.DataAccess.Client.OracleDbType.Decimal;

paramOpID.Direction = System.Data.ParameterDirection.Output;

cmd.Parameters.Add(paramOpID);

paramOpWhat.ParameterName = "What";

paramOpWhat.OracleDbType = Oracle.DataAccess.Client.OracleDbType.Varchar2;

paramOpWhat.Direction = System.Data.ParameterDirection.Input;

paramOpWhat.Value = @jobName;

cmd.Parameters.Add(paramOpWhat);

conn.Open();

cmd.ExecuteNonQuery();

return paramOpID.Value.ToString();

Este SP tiene muchos otros parámetros que recomiendo que veáis en la siguiente web: http://www.psoug.org/reference/dbms_job.html

Salu2

SSIS y ORACLE en plataformas de 64-bit

Hola a todos,

Hoy amiguitos os voy a contar una bonita historia sobre SSIS (SQL Server Integration Services) y Oracle en una plataforma de 64-bit a la hora de ejecutar unos jobs con el SQLAgent.

Resulta que haces un desarrollo en un entorno x86, crees que todo está perfecto y ¿sabes lo que pasa cuando lo llevas a producción en un entorno x64?... Exacto, que no funciona, que se producen errores y si no estás prevenido o encuentras la solución tu proyecto se puede ir rápidamente al traste.

Esto ocurre por lo siguiente:

En un entorno de 32-bits se instala BIDS(Business Intelligence Development Studio) de 32-bits, el cliente Oracle de 32-bits y DTEXEC (SQLAgent) de 32-bits. No hay problema.

Sin embargo, en entornos de 64-bits BIDS se instala de 32-bits (no hay versión de 64), Oracle de 64 y ya tenemos el primer problema. Primera solución: Instalar el cliente Oracle de 32 bit en la máquina de producción.

Pero esto provoca que cuando DTEXEC (de 64-bit) quiere ejecutar el ETL que llama al cliente Oracle (ahora de 32-bit) vuelve a fallas. HORROR!!!

La solución es no ejecutar con el SQLAgent SSIS directamente y utilizar CMDExec de 32-bits

Vaya lio, ¿no?

Venga, que con la información condensada es más fácil

- Instalar el cliente Oracle 10.2.0.1 versión de 32-bit

- Instalar el parche Oracle #4547817 (que actualiza a 10.2.0.2)

- Instalar el parche #5383042 (arregla el bug #3807408)

- Desarrollar con los paquetes con SSIS

- Ejectuar el ETL con CMDExec que usa la versión de 32-bit de DTEXEC (C:\Program Files(x86)\Microsoft SQL Server\90\DTS\binn). Próximamente en un post contaré como hacer esto y alguna cosa mas

Para terminar avisaros que los dos parches son de pago. Si, como lo lees, Oracle te hace pagar por arreglar un fallo en su aplicación, jajajaja. Y luego dicén de MS….

En fin, que a ver si con esto se solucionan vuestros problemas. Os dejo un link que me sirvió para ver la luz y poder hacer todo esto. Suerte!

http://portal.sqltrainer.com/2007/11/sql-server-integration-services-oracle.html

Salu2