Re: [mdb-dev] src/odbc/odbc.c

[<br...@br...>]

On Mon, 8 Mar 2004 09:04:34 -0800 (PST), Jeff Smith wrote:

> 
> Three things in src/odbc/odbc.c could use fixing.
> 
> 1.) In SQLGetTypeInfo, there are two unusual definitions:
> 
>   unsigned char *row_buffer[MDB_PGSIZE]
>   unsigned char *tmpstr[MDB_BIND_SIZE]
> 
> From the context, I highly doubt you meant to have these as arrays of
> pointers.  These would make a lot more sense:   :-)
>
>   unsigned char row_buffer[MDB_PGSIZE]
>   unsigned char tmpstr[MDB_BIND_SIZE]

Absolutely right, typo (they were pointers, and then.....sloppy me).

 > 2.) There is a table near the beginning of src/odbc/odbc.c,
> TypeInfo type_info[].  Several entries in the table contain NULL if
> four
> fields that should contain 0.  Specifically unsigned_attribute,
> sql_datetime_sub, num_prec_radix, and interval_precision.

This is a problem I hadn't decided how to handle.  NULL there is
wrong, but ... my thought is to do something like this:

SQLSMALLINT small_sql_false = SQL_FALSE;
SQLSMALLINT small_sql_true = SQL_TRUE;

then make the field in the structure a SQLSMALLINT * instead of
SQLSMALLINT and then store one of NULL, &small_sql_false or
&small_sql_true allowing SQLGetTypeInfo to return the correct value
(which is a NULL, SQL_FALSE,  or SQL_TRUE).  It's a little ugly, but
better than the alternatives.  

Note: I often use CVS to move between two machines, so things in CVS
will probably compile, but may not always be correct.

> 3.) In SQLColAttributes, there is this line:
>   *((char *)&rgbDesc[namelen])='\0';
> It generates a warning on my compiler.  All you should need is:
>   ((char *)rgbDesc)[namelen]='\0';
> 

I believe this came directly from the FreeTDS driver, will fix.

BTW, I'm still struggling with the order of columns in the null_mask. 
If you delete a row the row positions in the tdef page retain the old
values, but if you add a row on top of that they are reset to
sequential.  So, in a table with 1 column, 1 deleted column, another
column, and an added column the bitmask looks like:

0000 0111 for old rows

0000 1101 for new rows

Column 2 is deleted but there is no way as far I can see to determine
how many (fixed) columns have been delete between cols 1 and 3.  The
fixed offset tells you the positon of the columns, but you don't know
where they fall in the order.  Still looking....

Brian


Brian