Hi Mamta,

 Thanks for your comments.

Currently the *setInto* method is not overridden in SQLTimestamp.java, hence it uses the one defined in DataType.java which is as shown below,

public void setInto(PreparedStatement ps, int position) throws SQLException, StandardException {

       ps.setObject(position, getObject());
   }

Here there is a call to getObject() which is overridden in SQLTimestamp.java which calls getTimestamp((Calendar)null); which returns null.
Since the setObject cannot take an utyped null ( according to JDBC 3.0 spec ) it throws an Exception.
So calling setInto in this case is equivalent to calling


ps.setTimestamp(position, getTimestamp((Calendar) null));

So whenever setInto is called on a Timestamp it is as if I am calling the above 
code.

~ Shreyas


Mamta Satoor wrote:

On Tue, 22 Mar 2005 13:33:25 +0530, Shreyas Kaushik
<[EMAIL PROTECTED]> wrote:


Find the patch for this attached. I will send the test patch in a
seperate mail.

~ Shreyas


Index: java/engine/org/apache/derby/iapi/types/SQLTimestamp.java =================================================================== --- java/engine/org/apache/derby/iapi/types/SQLTimestamp.java (revision 158017) +++ java/engine/org/apache/derby/iapi/types/SQLTimestamp.java (working copy) @@ -45,12 +45,7 @@ import org.apache.derby.iapi.types.SQLDouble; import org.apache.derby.iapi.types.SQLTime;

-import java.sql.Date;
-import java.sql.Time;
-import java.sql.Timestamp;
-import java.sql.Types;
-import java.sql.ResultSet;
-import java.sql.SQLException;
+import java.sql.*;

import java.util.Calendar;
import java.util.GregorianCalendar;
@@ -989,5 +984,10 @@
              currentCal.setTime(value);
              return SQLTime.computeEncodedTime(currentCal);
      }
+
+    public void setInto(PreparedStatement ps, int position) throws 
SQLException, StandardException {
+
+               ps.setTimestamp(position, getTimestamp((Calendar) null));
+       }
}






Hi Shreyas,

Haven't looked into details of current implementation of setInto
methods by other datatypes, but I did notice that most other datatypes
have coded setInto method as follows
//this method is from SQLDecimal.java
public final void setInto(PreparedStatement ps, int position) throws
SQLException {
        if (isNull()) {
                ps.setNull(position, java.sql.Types.DECIMAL);
                return;
        }
        ps.setBigDecimal(position, getBigDecimal());
}

Seems like they first check for isNULL and call different methods
depending on whether the method is dealing with null or not. Wondered
why your patch does not check for null before calling ps.setTimestamp
method?

Mamta





Reply via email to