[ http://issues.apache.org/jira/browse/DERBY-570?page=comments#action_12365118 ]
Daniel John Debrunner commented on DERBY-570: --------------------------------------------- No java.lang.Byte is wrong. I was going to say look at VARCHAR FOR BIT DATA, but it doesn't have a compile type section. I would match VARCHAR FOR BIT DATA and CHAR FOR BIT data by not having a compile time type. I actually think we could remove the compile time java types for all the data types, I have no idea what it is meant to mean. Mappings between SQL types and Java types should be covered elsewhere. That's probably a separate cleanup though. > wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA > ------------------------------------------------------------ > > Key: DERBY-570 > URL: http://issues.apache.org/jira/browse/DERBY-570 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Rick Hillegas > Attachments: derby570-2.diff, derby570.diff, rrefsqlj30118.html > > The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT > DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, > implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR > BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT > DATA has the following jdbc type: LONGVARBINARY. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
