| Subject | Re: [Firebird-Java] Re: JBuilder DataSet Components and Firebird |
|---|---|
| Author | Blas Rodriguez Somoza |
| Post date | 2002-12-11T18:39:38Z |
Hello
At 11/12/2002 13:47 +0000, you wrote:
If the targetDataType is not the one of the field in the database, without conversions, we must throw an exception because we can't send an integer in the place of a String to FB, and this is what is supposed to do this method. This method is outside the scope of setObject conversions because the target type here is fixed.
About the scale, if the target must be a Decimal or Numeric as the specification says, the scale depend on the definition of the field and not of the scale of the number this is true for most of the databases in the market. Only if we allow to use targetType BigDecimal to output to a String field, we must worry about, because the scale of the number can be selected.
Otherwise, I think this method must be deprecated as it is the getBigDecimal(int index, int scale), but it seems the JDBC committee forget it. Also this method is wrong because if you set the scale you must set the rounding mode, and this method does not include it, so the rounding mode depend on the database/driver and you really don't know what you will get when you get the value from the field.
I think we don't break anything (that is not previously broken in the specification) if we modify the method to use setObject(int, object), and it seems more important to allow the use of JBuilder components without problems.
I will include a note in the JDBCCompliance document, if we decide to make the dummy implementation.
Best Regards
Blas Rodriguez Somoza
At 11/12/2002 13:47 +0000, you wrote:
>> I have seen that the method setObject(int parameterIndex, Object x,This method is the type of thinks that make an specification difficult to explain, I think even the implementation we have is not completely correct, although it can't be detected in a test.
>> int targetSqlType) has a similar workarround. Is there a chance
>> that you commit the driver with this new workarround to cvs?
>
>Only if we can ensure that this code does not break JDBC
>specification. If this fix would break specification, one of the
>possible solutions would be a connection parameter specifying
>JBuilder compatibility mode. Ugly, but...
>
>David, Blas, any comments on this issue?
If the targetDataType is not the one of the field in the database, without conversions, we must throw an exception because we can't send an integer in the place of a String to FB, and this is what is supposed to do this method. This method is outside the scope of setObject conversions because the target type here is fixed.
About the scale, if the target must be a Decimal or Numeric as the specification says, the scale depend on the definition of the field and not of the scale of the number this is true for most of the databases in the market. Only if we allow to use targetType BigDecimal to output to a String field, we must worry about, because the scale of the number can be selected.
Otherwise, I think this method must be deprecated as it is the getBigDecimal(int index, int scale), but it seems the JDBC committee forget it. Also this method is wrong because if you set the scale you must set the rounding mode, and this method does not include it, so the rounding mode depend on the database/driver and you really don't know what you will get when you get the value from the field.
I think we don't break anything (that is not previously broken in the specification) if we modify the method to use setObject(int, object), and it seems more important to allow the use of JBuilder components without problems.
I will include a note in the JDBCCompliance document, if we decide to make the dummy implementation.
Best Regards
Blas Rodriguez Somoza