Jack Klebanoff wrote: > I am not sure whether DatabaseMetaData.getProcedureColumns() is supposed > to return the size on disk or the RAM size of the column.
Or another option: is it supposed to return the size of bytes "transferred", as in the case of a server sending data to a client? I only reason ask is because that's the way the field is described in the ODBC specification--I don't know if it's supposed to be the same for JDBC or not? Nor do I know what it would mean to "transfer" bytes in embedded mode...?
If this value _is_ supposed to be the number of bytes "transferred", does that number always match the size on disk? My guess is probably not, since it appears, for example, that the "writeExternal" method in SQLDate stores the date as an integer--but I doubt that's what would be transferred from server to client...
Suresh Thalamati wrote: > I don't think char(10) always uses 20 bytes. It could just use 10 bytes > or more depending on the type of character being written...
Right, sorry, I was just giving an example. My assumption here is that the value to be returned by the metadata call is the _maximum_ number of bytes possible--so in the case of a char(10) column, since it could, as you said, "use 10 bytes or more", we'd have to return some number that is greater than 10--i.e. to return "10" like we currently do is wrong.
My question is whether or not a declaration of maximum BYTE length for the Derby builtin types exists somewhere in the codeline, and if so, is it okay to use that for the metadata calls? And on that premise, I was looking at "getApproximateLengthInBytes" to see if that method has the info required (hence my initial email on this subject).
If no methods/declarations exist in Derby that can provide this info, then new methods/declarations are going to have to be added in order for metadata to return the correct value.
Army
