Re: Possible Type Conversion Defect

Thank you for your feedback, as you mention this is going to impact existing
code and we are nervous to see how specific areas are affecting customers.
We believe that this is the right story going forward but we may have to
bend it a little for specific customer scenarios. We have already received
some pushback on getObject for uniqueIdentifiers (currently returns a byte
array which is how the server stores it but is not particularily usefull)
and supporting getLong on a Numeric(Decimal) type. If you have any other
suggestions be sure to post them here or file them as bug in the msdn
product feedback site :
http://lab.msdn.microsoft.com/productfeedback/default.aspx

There is still time to integrate customer feedback into this data coercion
story, but it is running out fast.

--
Angel Saenz-Badillos [MS] DataWorks
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging: http://weblogs.asp.net/angelsb/




"Eric Molitor" <EricMolitor@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3D094877-F2AC-4E91-9FDB-324FBB29BCD5@xxxxxxxxxxxxxxxx
> Right, I dug into this and was able to solve the problems both with
> conversions and by fixing some bad practices in our SQL...
>
> In several places after executing an insert we would simply...
>
> select @@IDENTITY as identityValue
>
> and then retrieve the value from the result set in java. Obviously we
> should
> have been using SCOPE_IDENTITY() for one but also we should have been
> using
> an out put parameter...
>
> So the proc becomes
>
> CREATE PROCEDURE spTestProc
> (
> @username varchar(8),
> @firstname varchar(255),
> @lastname varchar(255),
> @UserID int OUTPUT
> ) as
>
> INSERT INTO User (username, firstname, lastname)
> VALUES (@username, @firstname, @lastname)
>
> SELECT @UserID = SCOPE_IDENTITY()
>
> and in the code we just fetch the value as an output parameter...
>
> So once all of this shakes out I do think it will be a positive change,
> however I'm sure lots of people will have some SQL and Java to cleanup.
>
> Cheers,
> Eric
>
>
>
> "Angel Saenz-Badillos[MS]" wrote:
>
>> We wanted to be very explicit with our data coercion story and as far as
>> we
>> have been able we are not going to allow getting a type from the server
>> that
>> would require a downcast to the client and possible loss of data. This
>> strategy has the advantage of high predictability with limited chance of
>> data loss, but it is very restrictive.
>>
>> Quite frankly I was expecting to see a lot more people commenting on
>> these.
>> In your case 108 is of type NUMERIC, a 38bit precission decimal and you
>> are
>> trying to shove it into an INTEGER. Type 38 is an INTEGER which does not
>> fit
>> on a SMALLINT.
>>
>> We only have two choices here that don't involve data loss (something we
>> are
>> definitelly not going to allow),
>> 1) We can NEVER allow a conversion from a type if _the type you are
>> trying
>> to convert_ does not fit into the type that you are trying to coerce it
>> into. This is the behavior that we have opted for in the 2005 JDBC
>> driver.
>>
>> 2) We can allow a conversion from a type that does not fit into the
>> coreced
>> type _only_ when the current value that you are asking for can be coerced
>> into the type that you are asking for. This is the behavior of the 2000
>> JDBC
>> driver.
>>
>> Let's say that you have a NUMERIC column that has a value of 5, when you
>> call getInt on this we will throw an exception if following (1) but the
>> coercion will work on a driver that supports (2) since 5 does fit into an
>> INTEGER type. When you have a driver that provides the (1) functionality
>> you
>> will realize the first time you run your code that a NUMERIC column will
>> not
>> always fit into an int and change your code accordingly. When working
>> with a
>> driver of the (2) type you will test and deploy your application with
>> getInt. When the value of the NUMERIC column goes over what an INTEGER
>> can
>> handle you will get a runtime exception and you will have to go service
>> your
>> deployed application.
>>
>> We realize that it can be inconvenient to have this kind of issues
>> surfaced
>> early, but we feel it is better to let you know up front about possible
>> data
>> coercion issues, if you really wanted to get an integer from the server
>> you
>> would have defined your table accordingly, or you could have requested an
>> integer in your query with the CONVERT function.
>>
>> I think that this is going to be a common question, I am going to convert
>> this post into a blog and post it into the
>> http://blogs.msdn.com/dataaccess/
>> with a complete data coercion table to help make this design clearer, of
>> course comments/suggestions are welcome.
>> --
>> Angel Saenz-Badillos [MS] DataWorks
>> This posting is provided "AS IS", with no warranties, and confers no
>> rights.Please do not send email directly to this alias.
>> This alias is for newsgroup purposes only.
>> I am now blogging: http://weblogs.asp.net/angelsb/
>>
>>
>>
>>
>> "Eric Molitor" <EricMolitor@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:237EAB6D-63BA-4DB2-AB0C-7EB8D98B3E2D@xxxxxxxxxxxxxxxx
>> > Seem to be getting these consistantly in certain portions of our
>> > application.
>> > Works fine with the older JDBC driver (2000) but under the 2005 driver
>> > we
>> > see....
>> >
>> > com.microsoft.sqlserver.jdbc.SQLServerException: Unsupported conversion
>> > from
>> > 108 to INTEGER
>> > at
>> > com.microsoft.sqlserver.jdbc.SQLServerStatement.getRowsetField(Unknown
>> > Source)
>> > at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getInt(Unknown
>> > Source)
>> > at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getInt(Unknown
>> > Source)
>> >
>> > and
>> >
>> > com.microsoft.sqlserver.jdbc.SQLServerException: Unsupported conversion
>> > from
>> > 38 to SMALLINT
>> > at
>> > com.microsoft.sqlserver.jdbc.SQLServerStatement.getRowsetField(Unknown
>> > Source)
>> > at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getShort(Unknown
>> > Source)
>> > at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getShort(Unknown
>> > Source)
>> >
>> > I'm looking at the SQL and the code but I'd think 38 is a valid
>> > SMALLINT
>> > and
>> > that 108 is a valid INTEGER.
>> >
>> >
>>
>>
>>


.

Relevant Pages

  • Re: Possible Type Conversion Defect
    ... We wanted to be very explicit with our data coercion story and as far as we ... Type 38 is an INTEGER which does not fit ... This is the behavior that we have opted for in the 2005 JDBC driver. ... > com.microsoft.sqlserver.jdbc.SQLServerException: Unsupported conversion ...
    (microsoft.public.sqlserver.jdbcdriver)
  • Re: bindings 4 a rookie...
    ... the Driver X's because of the narrow fit of the Malamutes didn't fit ... the Burton P1 Carbon bindings and switched boots as well to the Burton Ions. ...
    (rec.skiing.snowboard)
  • Re: Driver Signing without Windows Logo
    ... In short these kinds of devices DON'T fit into the WHQL scheme. ... > My company has a USB medical device and we have developed a USB driver. ...
    (microsoft.public.development.device.drivers)
  • Re: Saving slides to pdf
    ... either truncated the image to fit, or scale it to fit in the allowable image ... You need to look for a printer or a driver at least, ... you may only get true borderless printing on three ... but no luck. ...
    (microsoft.public.mac.office.powerpoint)