On Mon, Dec 16, 2002 at 03:21:12AM -0800, Jonathan Leffler wrote:
>
> Yet another question -- given the specifications of type_info_all and
> type_info, how does type_info get hold of the SQL_DATA_TYPE,
> SQL_DATETIME_SUB and INTERVAL_PRECISION fields, given that they are
> not listed in the type_info_all structure?
Ah, [...rummages in ODBC 3.5 reference book...] Okay, I've just added these
extra items to the info to be returned by type_info_all:
SQL_DATA_TYPE => 16,
DATETIME_SUB => 17,
NUM_PREC_RADIX => 18,
INTERVAL_PRECISION=> 19,
I'd just left them out when I added the extra field descriptions
into the type_info docs. Note that DATETIME_SUB is misspelled with
an SQL_ prefix in the docs. That's wrong. Fixed now.
Driver authors please note!
> Also, the spiel for SQL_DATA_TYPE says:
>
> <quote>This column is the same as the DATA_TYPE column, except for
> interval or datetime types. For interval and datetime data types, the
> SQL_DATA_TYPE field will return SQL_INTERVAL or SQL_DATETIME, and the
> SQL_DATETIME_SUB field will return the subcode for the specific
> interval or datetime data type. If this field is NULL, then the
> driver does not support or report on interval or date types.</quote>
>
> Questions arising:
> 1. That last 'date' should be 'datetime' to be consistent.
Yeap. Fixed. Thanks.
> 2. What does the DATA_TYPE field contain when this field contains
> SQL_DATETIME or SQL_INTERVAL? Not that value - but which value?
The "consise" type integer, ie 112 for SQL_INTERVAL_HOUR_TO_SECOND.
So when SQL_DATA_TYPE = SQL_DATETIME or SQL_INTERVAL then
DATA_TYPE == DATETIME_SUB. (Yes, DATETIME_SUB does seem redundant
but that's what the ODBC spec calls for.)
> In the context of type_info_all, you say 'driver-specific columns of
> information ... start at column index 50 to leave room for expansion'.
> How do you write an initializer for the gap between the 14 (17?)
> defined attributes and the index where the driver-specific attributes
> can start? Or is that a subtle hint not to define driver-specific
> attributes? I'm looking at the code with lines like:
>
> [ 'INTEGER', SQL_INTEGER, undef, "", "", undef, ... ],
>
> With the first 14 columns defined, there has to be 36 empty columns
> left unefined, or zeroed, or something; is there a neat notation to do
> that? 36*undef or something useful?
..., (undef) x 36, ...
(The undef must be in parens to get the "x" operator to replicat the list.)
Tim.
