In my experience that depends on the underlying driver. If you call getString() and it is really an Number, then you *might* be lucky and get a String representation, but not always (e.g. if the underlying type is Blob how is this converted to a string? Using the byte array constructor is too obvious... You might end up with a lot of memory suddenly in use, so it is more likely to just fail)
You could also call getObject() which you can then introspect with reflection (if necessary). Note that in Java 6 nearly all the get methods throw SQLFeatureNotSupportedException and before 1.6 the same could happen but was simply a SQLException, so this is potentially a bit of a mine field. Hope that helps. Cheers, Chris 2009/4/14 Greg Brown <[email protected]> > It has been a long time since I wrote JDBC code. I could be remembering it > wrong, but I *thought* you could use those methods to coerce column data to > different types. Maybe someone else can confirm. > > On Tuesday, April 14, 2009, at 03:13PM, "Noel Grandin" < > [email protected]> wrote: > >Really? > >Fascinating <grin> > >All those years of writing EJB apps, and it never even occurred to me > >that that was possible. I always just called the right thing based on > >the column type of the query :-) > > > >On Tue, Apr 14, 2009 at 20:55, Greg Brown <[email protected]> wrote: > >> That's true, but column data can be extracted in a variety of formats. > This will allow the caller to specify which type to use. It will also be > necessary when extracting date values for use in JSON serialization, > > > > >
