Lance J. Andersen wrote: >>Hmmmm, that's kind of an awkward place to be in. It seems you want to >>add this non-standard SQL type to match other databases, but by matching >>the other databases you break the JDBC spec. :-) >> >> > I do not see how this is going to break anything. The JDBC spec > indicates should, not "must". >
> So i guess i am not sure of your concern dan. This datatype has worked > fine for drivers which have supported Sybase and MS SQL server for years. Maybe break was too strong, how about 'has the potential to confuse application developers'. :-) Just looking at the various tables in appendix B, the natural choice for an application developer to use is byte, setByte, getByte. Given the mappings in B1 & B2, and the big X in the getByte-TINYINT cell of B-6. Thus they may find their application works fine, because they only test it with values in the range 0-128, but later hit bugs in the field when larger values are used. If the JDBC TINYINT type was really put there to match the TINYINT SQL datatype of SQL Server and Sybase, then maybe JDBC 4.0 should clarify this so that the type mapping in B1 and B2 is TINYINT <-> short and B6 has the big X in getShort-TINYINT cell? Dan.
