Al realizar una consulta que debía regresarme un sólo resultado, me regresaba 2 e incluso 4. Esto se debía a que existen registros ‘duplicados’ -la tabla no tiene una llave primaria, huh? no pregunten-

Bueno, entonces me interesaba obtener sólo el registro más actual, por suerte, la tabla si tiene un campo con la fecha que se creó el registro.

Para limitar el número de resultados varía de acuerdo a la base de deatos que estes utilizando, por ejemplo, en MySQL es con la palabra LIMIT, en SQL Server con TOP y en Oracle con ROWNUM

Así que, en Oracle, la consulta más simple que se me ocurrió fue la siguiente

SELECT *
FROM USERS
WHERE ID = :ID
AND ROWNUM <= 1
ORDER BY FECHA_ALTA DESC

Pero no me arrojó los resultados esperados, de hecho, siempre me regresaba el mismo registro aunque creará un registro más actual. Esto se debe al orden en que Oracle ejecuta los comandos de la sentencia -primero ejecuta la claúsula WHERE que regresa un sólo registro y luego lo ordena de acuerdo a ORDER BY (si, ordena un sólo registro)-

La solución es realizar una subconsulta de la siguiente manera

SELECT * FROM (
SELECT *
FROM USERS
WHERE ID = :ID
ORDER BY FECHA_ALTA DESC
) WHERE ROWNUM <= 1

Fuentes:
http://www.w3schools.com/sql/sql_top.asp
http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html


Después de actualizar a Windows 8.1 a 64 bits, un proyecto me arrojaba el siguiente error al ejecutarlo

BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

justo en una línea donde se crea un objeto de la librería de Oracle -OracleParameter-

El problema se debe a la configuración del proyecto, en target tenía “Any CPU”, así que como mi sistema operativo es de 64 bits marcaba el error al tratar de utilizar la librería cliente de oracle de 32 bits.

La solución fue cambiar la propiedad “target” del proyecto a “x86” mediante el menú Build->Configuration Manager y crear una nueva.

Cabe destacar que después de hacer esto me marcaba errores de que no encontraba ciertas dependencias debido a que crea un nuevo directorio de salida “bin/x86/Debug” y buscaba las dependencias (copia local) en la carpeta “bin/Debug”. Al volver a apuntar la carpeta de salida (Project Properties, Output) a “bin/Debug”, es decir sin el “x86”, ya no me marcó errores.

Fuentes:

Despues de instalar Oracle SOA suite y Oracle Service Bus, me faltaba terminar de configurar JDeveloper para tener un ambiente de desarrollo completo. En la guía de instalación de Oracle SOA Suite menciona que debes instalar la extensión Oracle SOA Composite Editor

The SOA Extension will then be an online update. After installing and starting JDeveloper, from the menu choose Help > Check for Updates. In the Update Wizard, select Search Update Centers and ensure the first and second options are checked. Then ensure that Oracle SOA Composite Editor is checked.

Pero al ir a las actualizaciones disponibles no me aparecía la extensión. El problema se debió a que seleccione el “rol” Java Edition al iniciar JDeveloper por primera vez. Cambie el rol al Default Role (Tools->Preferences…Roles) -el cual activa todas las tecnologías- y ya me apareció la extensión.

Recientemente tuve que desempolvar un proyecto de .NET (C#) y hacer unas modificaciones.
Había que utilizar las clases de System.Data.Oracle en vez de Oracle.DataAccess debido a que, la segunda, ocasionaba un timeout de conexión con la versión 11.2 de Oracle Database Server.

Una vez que sustituí las clases y corregí todos los errores de compilación ocasionados por el cambio, ejecute la aplicación para probar su funcionalidad. Para mi sorpresa me lanzó la siguiente excepción:

ORA-06550: línea 1, columna 7: PLS-00306: número o tipos de argumentos erróenos al llamar a ‘PR_GETEXPEDIENTESXFACUERDO’
ORA-06550: línea 1, columna 7: PL/SQL: Statement ignored

Verifiqué muchas veces que el número o tipo de los parámetros fuera el correcto, pero seguía sin funcionar. En un acto de desesperación sustituí la llamada al procedimiento por una consulta sql estándar, pero no tuve éxito. Ya sin más ideas noté que el nombre de los parámetros en el código era distinto a los nombres en el procedimiento almacenado. Intenté renombrarlos, ya sin nada que perder, y asombrosamente funcionó. Al parecer la clase OracleCommand de System.Data.Oracle toma en cuenta el nombre de los parámetros mientras que la de Oracle.DataAccess no.

Fuentes:
https://community.oracle.com/thread/2171363?start=0&tstart=0
http://support.microsoft.com/kb/322160
http://blogs.msdn.com/b/spike/archive/2009/06/16/oracle-stored-procedures-with-ref-cursor-from-net-code-and-bid-tracing.aspx

En Oracle, si necesitas utilizar el año actual (de la base de datos) para el valor de alguna columna de tipo Number, lo podríamos hacer de la siguiente manera

    INSERT INTO TEXP
            (FOLIO,
             NUMERO,
             ANYO
            )
         VALUES (SEQ_TEXP.NEXTVAL,
             (SELECT MAX (NUMERO) + 1
                FROM TEXP
               WHERE ANYO = TO_NUMBER(TO_CHAR (SYSDATE, 'YYYY'))
             ),
             TO_NUMBER(TO_CHAR (SYSDATE, 'YYYY'))
            );

En este caso la tabla TEXP tiene 3 columnas de tipo Number (FOLIO, NUMERO Y ANYO).
Para obtener el FOLIO utilizamos una secuencia, para obtener el NUMERO hacemos una subconsulta para saber cúal es el valor máximo para el año actual y sumamos 1, para el ANYO utilizamos el año actual.
Pues resulta que no es necesario utilizar la función TO_NUMBER, la base de datos hace la conversión automática de un valor de tipo CHAR (o VARCHAR) a NUMBER y visceversa. De hecho la conversión que hace la base de datos es más eficiente que utilizar la función TO_NUMBER (el doble, 20ms contra 10ms para esta consulta sencilla).

    INSERT INTO TEXP
            (FOLIO,
             NUMERO,
             ANYO
            )
         VALUES (SEQ_TEXP.NEXTVAL,
             (SELECT MAX (NUMERO) + 1
                FROM TEXP
               WHERE ANYO = TO_CHAR (SYSDATE, 'YYYY')
             ),
             TO_CHAR (SYSDATE, 'YYYY')
            );

Fuentes:
http://stackoverflow.com/questions/1119710/how-do-i-get-the-current-year-using-sql-on-oracle

Al crear un DataSet con una consulta con parámetros, BIRT me arrojaba el error

org.eclipse.birt.data.engine.core.DataException: Failed to prepare the query execution for the data set: t_host
Cannot get the type for parameter: 1.
org.eclipse.birt.report.data.oda.jdbc.JDBCException: Cannot get parameter type.
SQL error #1:Unsupported feature

Al parecer el problema sólo se presenta con la base de datos de Oracle y ha sido resuelto a partir de la versión 4.2.1 de BIRT. Así que, si tienes una versión anterior, basta con actualizar para resolver el problema (Help->Check for Updates).

Fuentes:
eclipse forums

Instalé JDeveloper 11g en Ubuntu 12.04 a 64 bits. El JDK que tengo por default es OpenJDK, pero al parecer JDeveloper está muy ligado al JDK de Sun Microsystems (Oracle). El instalador de JDeveloper trae un JDK (por eso ocupa tanto la descarga) a 32 bits, entonces este fue el primer problema.

Después de configurar JDeveloper para que se ejecutará con OpenJDK a 64 bits todo parecía funcionar muy bien, hasta que quise crear un servicio web :S

Para crear un servicio web simplemente das clic derecho sobre la clase que contiene los métodos que quieres publicar en tu servicio web y das clic en “Create Web Service” para ejecutar el asistente. Al hacer esto me lanzó la siguiente excepción

java.lang.NoClassDefFoundError: com/sun/tools/javac/util/DefaultFileManager

Lo que hice para resolverlo, fue descargar el JDK de Oracle y configurar JDeveloper para que lo utilice.