Thread: select from a table having more than 32 fields: Quick Workaround
Description: A select from a table having more than 32 fields fails during SQLDescribeCol on field # 33. Test: create a 52 fields table. Insert 1 record. select * from table name. The error comes out. I get the error on a table with 52 field using psqlodbc version 6.50.000, Borland C++Builder or Centura. What's going on? In my opinion the driver try to allocate space for fields in blocks of 32 items as defined in FLD_INCR (parse.c) . The realloc() works well but for some reasons the fi pointer seems to get lost during SQLDescribeCol on column 1. Quick workaround: increase FLD_INCR, from 32 to how you need. Byron will help better....
"Matteo Cavalleri" <theos@bp.lnf.it> writes:
> A select from a table having more than 32 fields fails during
> SQLDescribeCol on field # 33.
> In my opinion the driver try to allocate space for fields in blocks of
> 32 items as defined in FLD_INCR (parse.c) . The realloc() works
> well but for some reasons the fi pointer seems to get lost during
> SQLDescribeCol on column 1.
I think the bug is in lines 681-694 (of current CVS sources). Actually
there are a couple bugs there: first that the new fi value is not stored
back into stmt->fi (your complaint). Secondly, the calculation of
required space looks to me to have a bunch of errors, both fencepost
type (roundup of stmt->nfld to number of slots actually allocated is
wrong) and conceptual (roundup should be done on total number of slots
needed, not on parts of it). I have no way to test ODBC, though, so
I won't try to fix it.
regards, tom lane
Tom Lane wrote: > > "Matteo Cavalleri" <theos@bp.lnf.it> writes: > > A select from a table having more than 32 fields fails during > > SQLDescribeCol on field # 33. > > > In my opinion the driver try to allocate space for fields in blocks of > > 32 items as defined in FLD_INCR (parse.c) . The realloc() works > > well but for some reasons the fi pointer seems to get lost during > > SQLDescribeCol on column 1. > > I think the bug is in lines 681-694 (of current CVS sources). Actually > there are a couple bugs there: first that the new fi value is not stored > back into stmt->fi (your complaint). Secondly, the calculation of > required space looks to me to have a bunch of errors, both fencepost > type (roundup of stmt->nfld to number of slots actually allocated is > wrong) and conceptual (roundup should be done on total number of slots > needed, not on parts of it). I have no way to test ODBC, though, so > I won't try to fix it. > I've just committed a fix according to Tom's analysis. Thanks to Tom for his accurate analysis as usual. Matteo, if you want to check the change I would send you a binary. Regards, Hiroshi Inoue
> > I think the bug is in lines 681-694 (of current CVS sources). Actually > > there are a couple bugs there: first that the new fi value is not stored > > back into stmt->fi (your complaint). Secondly, the calculation of > > required space looks to me to have a bunch of errors, both fencepost > > type (roundup of stmt->nfld to number of slots actually allocated is > > wrong) and conceptual (roundup should be done on total number of slots > > needed, not on parts of it). I have no way to test ODBC, though, so > > I won't try to fix it. > > > > I've just committed a fix according to Tom's analysis. > Thanks to Tom for his accurate analysis as usual. > Matteo, if you want to check the change I would send > you a binary. Thanks, Hiroshi. That seemed like a big problem that no one could test for a fix. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
The stuff in parse.c is only used if you actually have the "parse statements" option enabled in the driver settings. Actually, the parse module wasn't really a great parser -- it was more of an expirement to overcome some limitations of the backend in dealing with odbc functions like SQLDescribeCol, especially when used with Borland products. More importantly, I'm not sure if the parse code has been kept up-to-date as the Postgres SQL language has improved and so forth. Matteo, Do you actually have that option enabled? Byron ----- Original Message ----- From: Bruce Momjian <pgman@candle.pha.pa.us> To: Hiroshi Inoue <Inoue@tpf.co.jp> Cc: Tom Lane <tgl@sss.pgh.pa.us>; Matteo Cavalleri <theos@bp.lnf.it>; <pgsql-odbc@postgresql.org> Sent: Wednesday, February 21, 2001 10:58 PM Subject: Re: [ODBC] select from a table having more than 32 fields: Quick Workaround > > > I think the bug is in lines 681-694 (of current CVS sources). Actually > > > there are a couple bugs there: first that the new fi value is not stored > > > back into stmt->fi (your complaint). Secondly, the calculation of > > > required space looks to me to have a bunch of errors, both fencepost > > > type (roundup of stmt->nfld to number of slots actually allocated is > > > wrong) and conceptual (roundup should be done on total number of slots > > > needed, not on parts of it). I have no way to test ODBC, though, so > > > I won't try to fix it. > > > > > > > I've just committed a fix according to Tom's analysis. > > Thanks to Tom for his accurate analysis as usual. > > Matteo, if you want to check the change I would send > > you a binary. > > Thanks, Hiroshi. That seemed like a big problem that no one could test > for a fix. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026