albloguera

Y quien no iba  estar de acuerdo con tal afirmación. Otra máxima, mas importante aun si cabe, “el entorno de desarrrollo  debe ser lo más parecido, si no idéntico, al entorno de producción”- y quien no iba a estar de acuerdo con esta uútima?. El problema es que no siempre se puede disponer un entorno de desarrollo idéntico al que se dispone en producción, por muy diversos motivos, razones que no vamos a analizar en este post. Ultimamente estoy divirtiendome, y mucho con Oracle, por lo que será la version del Provider de Oracle para .Net el protagonista del artículo. Provider, ¿y esto que es?, definamoslo (para  el objetivo del artículo) como una tubería por la que se envian  y reciben datos entre una aplicación y la base de datos.

Bien, ahora veamos un entorno que simule nuestro ejemplo:

Siguiendo este esquema podriamos plantearnos la siguiente situación. Estamos realizando una modificacion sobre una aplicacion de escritorio que inserta datos a una base de datos Oracle. Por ejemplo, imaginemos que tenemos una tabla EMPLEADO con tres campos, de los cuales nos interesa el campo EDAD, que será de tipo NUMBER, campo que permite valores NULOS.

Ahora desde nuestra aplicación .net vamos a realizar insercciones en esta tabla tras ir leyendo los datos de fichero de texto. y llamar a un procedimiento que ejecute una orden de insercion, que sera la llamada a un procedimiento almacenado, y al que le pasaremos 3 parametros de entrada:

procedure(dni IN VARCHAR2, nombre IN VARCHAR2, edad IN NUMBER)

INSERT INTO EMPLEADO(’76787223J’,'David’,'20′);

INSERT INTO EMPLEADO(’56432388M’,'  ‘,’ 23 ‘);

INSERT INTO EMPLEADO(’12597533O’,'Armando’,'  ‘);

Pues bien el resultado obtenido al ejecutar el procedimiento con la datos de ejemplo, va a ser diferente en función del provider con el que se ejecute la aplicación. Las dos primeras lineas se insertarán siempre (la columna “nombre” no es obligatoria). En el segundo comando si nos fijamos el número esta precedido y seguido por un caracter de espacio, pero esto no falla, ya que el provider es capaz de convertir de forma implicita la cadena de texto a su valor numerico. El problema lo encontramos en el tercer comando. Mientras que la version 9 del provider de Oracle para .Net, este convierte el valor a NULL y si en la definicion de la columna no impedimos este valor, no se produce error al guno, pero la version 8 por el contrario no es capaz de transformar este valor a un número válido, y nos devolverá un error del tipo ORA- 01722 INVALID NUMBER.

El problema:

El problema no era detectar e impedir el error en codigo, ya que este era facilmente supsanable, sino averiguar porque se producia solo en el entorno de producción,  cuando realizadas ciertas prueba las version del servidor Oracle, no era la causa del error.  Para resolver el problema se tuvo que montar una máquina virtual con un servidor Oracle 8.

Lo primero fue ejecutar directamente las inserciones sobre el servidor de base de datos,, realizando la llama al procecimiento, porque aunque y tal y como esperabamos eso deberia de fallar, no debiamos descartar nada. Sabiamos que eso reportaría un error porque  Oracle no covierte una cadena de espacios en un NULL cuando espera un tipo númerico. Si ejecutamos el siguiente comando, obtenemos un error.

—>  Select tonumber(’ ‘) from dual;      — Esto esta orden si se podía ejecutar sobre el servidor de produccion

El siguiente paso fué preparar la aplicacion para ejecutarlo contra un entorno de bases de datos reducido pero con la objetos necesarios que se necesitaban para ejecutar la aplicación e intentar reproducir el error (tablas y procedimientos). Ejecutamos la aplicación en un primer momento desde una maquina de desarrollo. Todo funcionó correctamente. Es decir, el valor edad=’  ‘, lo transformaba en NULL.

La siguiente prueba fué correr la aplicación en la maquina virtual con el servidor Oracle (y  provider 8).  Aqui es donde se produjo el error.

Teniendo en cuenta estos resultados, estaba claro. Si ejecutabamos la aplicacion en una maquina remota  contra un servidor Oracle 8 la aplicacion funcionaba perfectamente. Si ejecutabamos la aplicacion en  la misma maquina del servidor con Oracle,  se producia el error. Evidentemente la única diferencia era la capa que separaba la aplicacion .Net y el servidor Oracle. Solo podía ser eso, era el Provider. Teniamos una versión distinta en las maquinas de desarrollo y en el servidor Oracle. !!Que gran sorpresa, eso no lo sabiamos !!

Conclusión:

Evidentemente, y visto lo visto, es un error dejar en manos de un Proveedor de datos la validacion y formateo de los datos, y debería de ser obligacion de la aplicacion el hecho de  proveer unos datos normalizados al motor de base de datos.

Evidentemente, y visto lo visto, el entorno de desarrolo debe ser los mas parecido al entorno de produccion, para detectar con mayor rapidez este tipo de errores. Pero he de decir, que en este caso y aunque las versiones de oracle eran distintas entre ambos entornos, no eran la causa del problema.

Uffffff, menudo peñazo que he soltado para decir lo importante que es la version de un Provider,  eso lo sabiamos todos, pero hacia tiempo que no escribía y me apetecía, y esta semana Holmes y Watson  han dedicado algo de tiempo al caso  aqui resumido. En cualquier caso,, el proximo post volverá a tratar de nuestro amigo Silverlight, porque, por si alguien no lo sabe, ya tenemos la realease de Silvelight 2 en la calle.