Sometimes a java.lang.IllegalAccessError message appears when SQLDeveloper restarts after installing the OrindaBuild plugin.

Even though this message appears the plugin will work.

Oracle are fixing this.

Procedures and Functions that use TIMESTAMPLTZ should call OracleConnection.setSessionTime() as part of executeProc. In addition to extra code this will involve keeping track of and possibly validating the time zone against Oracle's list of acceptable ones.

Depending on a number of factors but especially which driver you are using CHAR fields will be padded with up to 32000 spaces. Current versions of OrindaBuild deal with this by calling String.trim() on the returned data. What should happen is that OrindaBuild should determine the size of the longest field and pass it to setMaxFieldSize(). This would reduce the volume of data being retrieved.

OrindaBuild was unable to tell that "TIMESTAMP(6)" was a form of TIMESTAMP.

If you create a Public Synonym for a packaged procedure that has records (e.g. %ROWTYPE) for one or more parameters, pseudo-random character strings as "/f62ef35e" show up in front of the name in the GUI:

The character Strings exist in USER_SYNONYMS - it's hard to fix this as OrindaBuild has no way of knowing what the 'correct' name should be.

This problem can be avoided by using "Private Synonym" or "Other User's Object" in step 2.2.1 instead of "Public Synonym".

The pseudo-random string of characters appears to be the same for any given procedure even if you re-create it in a different database instance that uses a different Oracle version.

When running OrindaBuild 4.0.1744 under the new 1.5 JVM selecting the 'Metal' look and feel leads to buttons with truncated text.

Orinda Software has fixed most of this problem in 4.0.1846. We are waiting to see if the problem still exists in the definitive 1.5 JVM before completely fixing this bug.

If you are using Oracle 8i and have a procedure that takes %ROWTYPE, an Oracle TYPE or a PL/SQL package record as a parameter the generated code doesn't work if you are accessing it via a synonym but does work if you log in as the owning user or use the "Other User's Object" in step 2.2.1.

If in step 3.3 you select "spaces_between_words" for your Java Naming Convention the generated code will still run but the releaseResources method and others will follow the InitialCapitalLetters naming convention. This is because the "spaces_between_words" naming convention has been deprecated.

If you create a QueryStatement for:

SELECT /* What is this comment for ? */ USERNAME
FROM USER_USERS
WHERE USERNAME = ?;

it will fail because SqlUtils.countParameters() will return '2' when it should return '1'.

When using the method SqlUtils.getStatementType(String theStatement) the statement below comes back as SqlUtils.UNKNOWN when it should be SqlUtils.SELECT:

/* Comment At Start */ SELECT USERNAME
FROM USER_USERS
WHERE USERNAME = ?;

The same thing happens if leading spaces are present.

Unsupported network datatype or representation

This message occurs when the driver encounters a database object it doesn't know how to deal with. The most common cause is using an 8i driver to access a database containing a 9i datatype such as TIMESTAMP. You can also get it when the driver is far ahead of the database version. An example of this would be attempting to access a DATE column in an Oracle 8.1.5 database using the 9.2.0 driver.

Problem: If you are working with BC4J and use oracle.jbo.server.DBTransaction to connect to the database you will not be able to instantiate Orinda generated classes, as they expect a JDBC Connection object. There is no obvious way to get a Connection object from an oracle.jbo.server.DBTransaction.

Workaround: You can create a dummy statement and then retrieve its Connection object:

Connection conn = getDBTransaction()
    .createCallableStatement("select 1 from dual",1)
    .getConnection(); 

The connection can then be passed to your generated class. We found this workaround on Oracle's OTN website.

Resolution: Orinda plans on adding an option to create additional class construnctors that take a oracle.jbo.server.DBTransaction Object instead of a Connection Object. This is a non-trivial enhancement and is going to have to wait until the next significant build.

Problem:If you attempt to run OrindaBuild against "Oracle 10g Personal" a NullPointerException is generated shortly after login.

Analysis: In Oracle 10g Personal the entries in v$version all begin with "Personal Oracle". In prior versions of the Personal edition the v$version entries began with "OracleXi Personal". OrindaBuild is confused by this and fails to populate a String variable containing the database version leading to a NullPointerException.

This problem only affects the Personal edition.

Resolution: A new build which works with "Oracle 10g Personal" is in regression testing.

Problem:NullPointerException/Empty Modal Message when trying to create an OrindaBuild file in Eclipse.

Analysis:The code attempts to find the container entered by the user. If no container exists a resource Object is set to null and a NullPointerException is thown when the code tries to reference the Object. Since the code in question was generated by Eclipse's Plugin wizard we have also filed this as a bug in Eclipse.

Resolution: A new build which fixes this bug has been released.

Problem: If you are using:

• OrindaBuild 4.0
• Windows
• Java 1.3 or 1.4

OrindaBuild may crash if asked to generate code for a large number (hundreds) of tables. The application may vanish or produce error text like this:

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_03-b02 mixed mode)
#
# Error ID: 43113F32554E54494D45110E4350500308
#
# Problematic Thread: prio=7 tid=0x02ecf248 nid=0xc10 runnable
#

The error id 43113F32554E54494D45110E4350500308 is associated with Sun bug #4820592 .

Resolution: Prior to 4.0.1846 OrindaBuild was compiled using the 1.2 JVM. We now use the 1.4 JVM and have verified that the code runs on 1.2, 1.3, 1.4 and 1.5 without this bug reappearing.

Bug Reopened: This bug has continued to occur sporadically since 4.0.1846. It appears to be associated with Intel based machines and large numbers of Tables.

Resolution: From build 4.0.1959 onwards we use a set of JVM parameters which prevent this bug from occuring.

Resolution: For build 4.0.1970 we rewrote the code in question, as our previous fix didn't work for the JDeveloper 10g and Eclipse 3.0 extensions. Any customers who have seen this bug should uprade to 4.0.1970 or higher.

See Also: The Orinda Software Blog

In PL/SQL you can have two procedures with the same name and same number of parameters provided the data types of the parameters are different. OrindaBuild adds "- Overload n" to the name of overloaded procedures so you can tell them apart. The problem with overloads is that JDBC is easily confused by them and you tend to get messages such as "Too many declarations of this procedure exist" - i.e. JDBC doesn't know which version of the procedure to run. In the case of dbms_obfuscation_toolkit's DESGetKey function JDBC can't tell the difference between the version which takes a RAW and the version which takes a VARCHAR2. This is a JDBC PL/SQL thing and not something OrindaBuild can fix.

Workaround: We therefore proposed a workaround. We created a package called wrapped_des which only implements the 3 functions we had decided to use. PL/SQL is much better at resolving overload problems than JDBC so by calling a PL/SQL function which called the 'correct' encryption function we could resolve the issue. Even so, to get out PL/SQL to work we had to use named parameters ("param_name => param_value"). Normally Orinda prides itself on the fact that you don't have to create views, tables etc to use our stuff but this is a rare exception.

The workaround procedure code is:

CREATE OR REPLACE PACKAGE wrapped_des AS
--
FUNCTION DESGetKey(seed_string IN VARCHAR2) RETURN VARCHAR2;
--
FUNCTION DESEncrypt(input_string     IN  VARCHAR2,
                    key_string       IN  VARCHAR2)
RETURN VARCHAR2;
--
FUNCTION DESDecrypt(input_string     IN     VARCHAR2,
                    key_string       IN  VARCHAR2)
RETURN VARCHAR2;
--
END;
/



CREATE OR REPLACE PACKAGE BODY wrapped_des AS
--
FUNCTION DESGetKey(seed_string IN VARCHAR2) RETURN VARCHAR2
IS
--
BEGIN
--
-- We explicitly name the parameters to avoid 
-- the "too many declarations" message
--
  RETURN(dbms_obfuscation_toolkit.DESGetKey
                           (seed_string => seed_string));
--
END;
--
FUNCTION DESEncrypt(input_string     IN  VARCHAR2,
                    key_string       IN  VARCHAR2)
RETURN VARCHAR2 IS
--
BEGIN
--
  RETURN(dbms_obfuscation_toolkit.DESEncrypt
                            (input_string => input_string
                            ,key_string => key_string));
--
END;
--
--
--
FUNCTION DESDecrypt(input_string     IN  VARCHAR2,
                    key_string       IN  VARCHAR2)
RETURN VARCHAR2 IS 
--
BEGIN
--
  RETURN(dbms_obfuscation_toolkit.DESDecrypt
                             (input_string => input_string
                             ,key_string => key_string));
--
END;
--
--
END;
/

When accessing version 9.0.1 of Oracle a stand alone procedure will show up as being part of a package with the same name i.e.
FOO_PROC
will appear as
FOO_PROC.FOO_PROC

This is caused by a change in the way the data dictionary worked in 9.0.1.

If in step 2.1 you entered the name of another user in the "User" box and that user owns private synonyms you will be able to "see" those synonyms even though you do not have access rights for the objects they point at

The com.orindasoft.pub.QueryStatement class is missing the method setTempDir(java.io.File tempFileDir) and creating temporary files in inconvenient locations

Functions that are part of a PL/SQL package do not show up in the GUI.

Procedures and Functions that have PL/SQL BOOLEAN parameters are not supported.

In step 2.2.1 the RealName field on the right hand side of the sceen can not be resized.

com.orindasoft.pub Has a setTempFileSuffix(String tempFileSuffix) method but it doesn't work.

If a procedure has errors and doesn't compile OrindaBuild will generate unusable code. This has been fixed - the product will check USER_ERRORS and refuse to generate code if it finds any.

If you are using Oracle 8i and update a CLOB or BLOB so it gets smaller the actual LOB remains the same size. This has been fixed by adding code to trim the LOB if the new LOB is smaller than the old one.

If your saved PB2 file tells OrindaBuild to look for Objects beloing to all users (i.e. a value of '%' for User in step 2.1) OrindaBuild will take a long time to start as it has to parse all the PL/SQL in the database.

If you:

1. Log into an Oracle 9i database

2. Find a procedure with one or more parameters that uses a datatype that doesn't exist in 8i

3. Specify 8.1.5, 8.1.6, 8.1.7 as a target database

You should get a warning at the generation stage (Step 5) but don't.

If you try to use OrindaBuild on a procedure with a '$' sign in its name the resulting Java class file name will also have a dollar sign in its name. Java will then have difficulty compiling the class because of the naming convention used for inner classes. There are also issues with variable substitution on Unix platforms.

This bug arose because while in theory '$' is a legal character for a Java identifer in practice it is reserved for Inner classes. OrindaBuild 4.0.1918 now strips '$' from identifiers and generates usable Java.

This appears to be caused by new anti-piracy measures added in 4.0.1927. We now obfuscate more files than we did in previous releases and as a result the 'Add Library' functionality has broken.

Workaround: The relevent libraries are located underneath the OrindaBuild install directory and can be added manually using the Project/Project Properties/Libraries window.

Resolution:The button now adds either the demo library or the 8.1.5 - 10.1.0 libraries depending on which version of OrindaBuild is being installed. The button will not work if OrindaBuild is installed in a non-standard location - in that case the Workaround above should be used instead.

A java.lang.NullPointerException is thrown if you attempt to start the OrindaBuild wizard from the "Tools" menu without selecting a project first

This has been fixed - You now get a message advising you to select a Project first.

In oracle 9i retrieving a NULL value for any of the datatypes TIMESTAMP, TIMESTAMP WITH TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE would result in a matching but empty java object being returned. In 10g null is returned instead, which means that existing code may suddenly start to generate java.lang.NullPointerException Exceptions when the driver is upgraded.

Prior to Oracle 10.1.0 DATE columns were returned as java.sql.TimeStamp objects. In Oracle 10G they come back as java.sql.Date objects. Because ReadOnlyRowSet did not explicitly cast DATE to java.sql.TimeStamp and relied on the driver to do so generated code behaved differently between 9.2.0 and 10.1.0. From OrindaBuild 4.0.1818 ReadOnlyRowSet has been modified to explicitly cast DATE to java.sql.TimeStamp.

If in Oracle 10.1.0 (10g) you call releaseResources on a PL/SQL procedure that returns a cursor and then attempt to re-use the procedure you get a 'Cursor is closed' error message. Prior to 10.1.0 Oracle returned a zero-length cursor. OrindaBuild has been modified to cope with the situation.

OrindaBuild slows down noticably when asked to generate code for a large number of tables.

Resolution:We identified and fixed a poorly performing SQL statement. It now uses the right index and has been tested against over 1000 interrelated tables without any issues.

If you install the Demo version of OrindaBuild's JDeveloper extension and then upgrade to the full version nothing appears to happen.

Resolution: In order for the licence code to be accepted you need to press the Reset Licence Code button on the OrindaBuild Preferences screen screen. We have amended the documentation to make this clearer.

Problem: When you try to start OrindaBuild from within Eclipse you get a "Problem Opening Wizard" Modal Message

 

Analysis: This is known to occur when you attempt to use the Plugin with Eclipse 2.1.3. OrindaBuild is not supported on Eclipse versions prior to 3.0.0. If you get this with Eclipse 3.0 please contact our support team.

Problem: java.lang.NumberFormatException is thrown when using Java 1.5 and returning a cursor containing a CLOB, BLOB, LONG or BFILE

Analysis: Prir to Java 1.5 an attempt to convert a number > 2GB to an int would lead to a java.lang.NumberFormatException whose message was a String containing the number that was too big. In Java 1.5 this changes and the number is embedded in the middle of an error message such as:

For input string: "value"

NumberFormatException is thrown by the getPrecision method of Oracle's ResultSetMetaData class when the column is a BFILE, CLOB or BLOB. The constructor for com.orindasoft.pub.ReadOnlyRowSet catches it and extracts the number from the Exception text. This step was failing for Java 1.5 until we added code to strip out the new message text before trying to turn it into a number.

Resolution: A new build (4.0.2070) which fixes this bug has been deployed.