• Subject: Re: JTOpen 2.0 problem
  • From: "Richard Dettinger" <cujo@xxxxxxxxxx>
  • Date: Thu, 11 Jan 2001 11:27:07 -0600
  • Importance: Normal


Everything that Dave said is right on, but I would like to add a comment or
two and then see if anyone has
any additional opinions on the subject.

1) We really made this change to the default for a couple reasons including
specification conformance, conformance
with JDBC drivers for other platforms such as UDB, and the general safety
issue of making users take explicit
action if they want to have potentially dangerous behavior.

2) We have had the data truncation connection attribute in both JDBC
drivers for some time to allow the switching of
this behavior between compliant and non-compliant.  Because few people were
running with the compliant beharior,
we quickly found a couple bugs when we switched the default as Dave noted.

3) Besides changing the default, we did change a couple aspects of how data
truncation connection property works.
Here are the basics of the new rules:

A) First, for columns of type NUMERIC and DECIMAL the flag is ignored.  You
can't turn off data truncations for
columns of these types because we didn't feel it was a good idea to let
users stick 100 into a NUMERIC(2)
column and get the value 10 or 00 no matter what any propety was set to.

B) That being said, there is a concept of significant truncation and
insignificant truncation with NUMERIC and
DECIMAL numbers.  The difference is whether the truncation happens to the
right or left of the decimal postion.
Truncation to the right of the decimal point (the fractional portion of the
value) is insignificant and always happens
silently.  Truncation to the left of the decimal point (the whole number
portion of the value) is always significant
and always results in data truncation exceptions.  This behavior is
designed this way to exactly match how
interactive SQL and other database interfaces treat the NUMERIC and DECIMAL
data types.  If you want to
test examples, use the STRSQL CL command to start iSQL, create a table with
the column specification you
want and try some inserts with various sizes.

4) There is a known issue that we have yet to deal with.  The specification
states that data truncation on a value
to be written to the database should throw an exception.  If it is not on a
write to the database, it should be a
warning.  We have a rather all or nothing view of how to handle truncation
issues today.  What is really needed
is to create the DataTruncation object and throw it or issue addWarning for
it based on the SQL statement that
the parameter is for.  It is going to take a little time for us to work
that out but it is along these lines:

statement type:          action:
SELECT         always warning (the value isn't going into the database)
UPDATE         always exception (the value is to be put into the database)
INSERT(simple) always exception (the value is to be put into the database)
INSERT(subselect)   I think this would always be a warning as the parameter
would be on the select clause...
                    can anyone provide an example against this?
CALL           probably can't know what the parameter will do... throw an
exception

Whew... I'm tired now.  If anyone has opinions on this stuff, I'd love to
hear them.

Regards,

Richard D. Dettinger
AS/400 Java Data Access Team

"TRUE! nervous, very, very dreadfully nervous I had been and am; but why
WILL you say that I am mad?
The disease had sharpened my senses, not destroyed, not dulled them. "

- Edgar Allan Poe
"The Tell-Tale Heart"




Dave Wall/Rochester/IBM@IBMUS@midrange.com on 01/11/2001 10:09:57 AM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   JAVA400-L@midrange.com
cc:   Christopher Smith/Rochester/IBM@IBMUS
Subject:  Re: JTOpen 2.0 problem




Two things could be going on here.

First, the check-for-truncation default was changed from false to true in
JTOpen 2.0.  In v4r5 and earlier, this flag defaulted to false so you
wouldn't know your data was being truncated unless your program set the
flag to true.  We think it is better (and will match the native JDBC
driver) to default the other way.  In JTOpen 2.0 we tell you your data is
being truncated unless you tell us you don't want to know.  So, one
possibility is your data was always truncated.  In v4r5 and before, since
the default is no warning, we wrote the data anyway.  Now with the default
being true, we throw an exception when data is truncated.  To go back to
the old behavior, set the flag to false -- ";data truncation=false" on your
URL.  (Also feel free to let us know if you agree with the change).

Second, once we set the default to true we found a couple places where we
threw exceptions when we shouldn't have (data was not truncated).  We fixed
these places (SQLReal, SQLDouble and SQLFloat).  The fixes will be out in
the next open source drop.

David Wall
AS/400 Toolbox for Java


"Franco Biaggi" <fbiaggi@ticino.com>@midrange.com on 01/10/2001 01:21:34 AM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   "JAVA400-L@midrange.com" <JAVA400-L@midrange.com>
cc:
Subject:  JTOpen 2.0 problem



Hello,
following error with JTOpen 2.0 (The application work fine with the JTOpen
shipped with VAJ Enterprise).
(There is no data truncation...)

com.ibm.vap.common.VapPrepareFailureException: Prepare failure; nested
exception is:
        java.sql.DataTruncation: Data truncation
com.ibm.vap.common.VapPrepareFailureException: Prepare failure; nested
exception is:
        java.sql.DataTruncation: Data truncation
java.sql.DataTruncation: Data truncation at
com.ibm.as400.access.AS400JDBCPreparedStatement.testDataTruncationAS400JDBCPreparedStatement.java:1891)


        at
com.ibm.as400.access.AS400JDBCPreparedStatement.setValue(AS400JDBCPreparedStatement.java:1871)


        at
com.ibm.as400.access.AS400JDBCPreparedStatement.setObject(AS400JDBCPreparedStatement.java:1551)


        at
com.ibm.ivj.db.base.DatabaseStringField.setFieldObject(DatabaseStringField.java)


        at
com.ibm.ivj.db.base.DatabaseTypeField.setObject(DatabaseTypeField.java)
        at
com.ibm.ivj.db.base.DatabaseConnection.setInputValues(DatabaseConnection.java)


        at
com.ibm.ivj.db.base.DatabaseConnection.executeQuerySpecWithValues(DatabaseConnection.java)


        at
com.ibm.ivj.db.base.DatabaseQuerySpec.executeOnConnection(DatabaseQuerySpecjava)


        at
com.ibm.vap.RelationalPersistence.SqlQuery.executeNonSelectWith(SqlQuery.java)


        at
com.ibm.vap.RelationalPersistence.SqlQuery.execute(SqlQuery.java)
        at
com.ibm.vap.RelationalPersistence.SqlQuery.execute(SqlQuery.java)
        at
com.ibm.vap.RelationalPersistence.RelationalServiceObject.executeQuery(RelationalServiceObject.java)


        at
com.ibm.vap.RelationalPersistence.RelationalServiceObject.executeOneInsert(RelationalServiceObject.java)


        at
com.ibm.vap.RelationalPersistence.RelationalServiceObject.executeInsert(RelationalServiceObject.java)


        at com.ibm.vap.Persistence.ServiceObject.insert(ServiceObject.java)
        at com.ibm.vap.Persistence.ServiceObject.insert(ServiceObject.java)
        at
com.ibm.vap.Persistence.PersistentHomeCollection.executeInsert(PersistentHomeCollection.java)


        at
com.ibm.vap.Persistence.NewPersistentState.synchronize(NewPersistentState.java)


        at com.ibm.vap.Transactions.Version.synchronize(Version.java)
        at
com.ibm.vap.Persistence.Resource.synchronizeVersions(Resource.java)
        at com.ibm.vap.Persistence.Resource.primPrepare(Resource.java)
        at
com.ibm.vap.Persistence.ActiveResourceState.prepare(ActiveResourceState.java)


        at com.ibm.vap.Persistence.Resource.prepare(Resource.java)
        at
com.ibm.vap.Persistence.ResourceManager.prepareResources(ResourceManager.java)


        at
com.ibm.vap.Persistence.ResourceManager.synchronize(ResourceManager.java)
        at
com.ibm.vap.Transactions.Transaction.synchronizeToResources(Transaction.java)


        at
com.ibm.vap.Transactions.Transaction.primCommit(Transaction.java)
        at
com.ibm.vap.Transactions.ActiveTransactionState.primCommit(ActiveTransactionState.java)


        at
com.ibm.vap.Transactions.ActiveTransactionState.commit(ActiveTransactionState.java)


        at com.ibm.vap.Transactions.Transaction.commit(Transaction.java)


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Franco Biaggi">
<meta name="GENERATOR" content="Franco Biaggi">
</head>

<body>

<p>&nbsp; </p>

<table BORDER="1" COLS="1" WIDTH="452" BGCOLOR="#FFFF00">
  <tr>
    <td width="446"><font face="Comic Sans MS"><small><small><br>
    <font color="#3333FF"><a href="http://www.ticino.com/usr/fbiaggi/
">Franco Biaggi</a></font><small><br>
    <font color="#3333FF"><a href="http://www.sisa.ch">SISA Studio
Informatica SA</a></font><small><small><small> <br>
    </small></small></small><font color="#3333FF">R&amp;D
Services</font><small><small><small>
    <br>
    </small></small></small><font color="#3333FF">Via Carvina
1</font><small><small><small> <br>
    </small></small></small><font color="#3333FF">CH-6807
Taverne</font><small><small><small> <br>
    </small></small></small><font color="#3333FF">Tel. +41 91 935 75
35&nbsp; Fax. +41 91 935
    75 30</font></small></small></small><br>
    </small></small></small><font color="
#3333FF">ICQ:59714125(disabled)</font><small><small><small> <br>
</font></td>
  </tr>
</table>
</body>
</html>



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.