|
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> </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&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 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 mailing list archive is Copyright 1997-2024 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.