FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Eric, 

can you give me more info on the TEXT the 81 here is what the application
requests as a max buffer length in the call to SQLGetData.  It may be
picking this up somewhere else, is this DBD::ODBC?

Secondly, on the int, if you use an int with 2 or 3 digits do the number
of nulls tacked to the end decrease (meaning the total chars remains a
constant 8 regardless of digits in the number)?  Hope that made sense.

Freddy, looking at your unittest, is there any reason we left logging on?
and should we be using temp tables like in the other libs?

Brian

> I have two more challenges.  I wans't able to get a hack to work for the
> TEXT datatype.  I still get in the tdsdump.log file:
> 
> 2002-09-04 13:02:44 processing row.  column is 7 varint size =3D 4
> 2002-09-04 13:02:44 processing row.  column size is 532=20
> 2002-09-04 13:02:44 clearing column 7 NULL bit
> ...
> convert_tds2sql: src is 35 dest =3D 1
> convert_tds2sql: outputting character data destlen =3D 81
> 
> It's trying to force a 532 character long TEXT field into a destlen of
> 81.  I couldn't figure out why.
> 
> One final item that I noticed upon careful inspection: when the data
> come back to me in Perl, instead of, e.g., for an int "1", I'm getting
> "1\x00\x00\x00\x00\x00\x00\x00\x00", i.e. the full length is returned
> padded with zeros.
> 
> Thanks,
> Eric
> 
> 
> > -----Original Message-----
> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: Wednesday, September 04, 2002 12:33 PM
> > To: TDS Development Group
> > Subject: [freetds] Re: prerelease delayed by documentation
> >=20
> >=20
> > > Hi, I upgraded to the latest DBI and DBD::ODBC and that had no
> effect on
> > > the ODBC problems I was having.  I did a little more investigating,
> and
> > > here's a better problem report.
> > >
> > > Here's the output of my test program:
> > >
> > > [QUERY]: SELECT test_id,intfield,charfield,floatfield FROM
> > > testdb.dbo.dbaccesstests
> > > 0 (test_id): 4 --> int
> > > 1 (intfield): 4 --> int
> > > 2 (charfield): 12 --> 12
> > > 3 (floatfield): 8 --> 8
> > > =3D3D1|20|butter?|3=3D3D
> > > =3D3D2|25|milk|2=3D3D
> > > =3D3D3|30|swamp gas|1=3D3D
> > > =3D3D4|35|pillow|-=3D3D
> > > =3D3D5|50|chicken|1=3D3D
> > > Segmentation fault (core dumped)
> > >
> > > The last column of type FLOAT only returns the first digit.
> > >
> > > As I look through the tdsdump.log file (attached), I notice the
> final
> > > gasp is:
> > >
> > > odbc:SQLGetConnectOption: Statement option 102 not implemented
> > >
> > > Perhaps that's one problem that is easily fixed.
> > >
> > > Another obvious problem is that for the last column, the column size
> is
> > > 8.  But then in convert_tds2sql(), it says:
> > >
> > > convert_tds2sql: outputting character data destlen =3D3D 1
> > >
> > > destlen shouldn't 1 here, I don't think.  For a float it should be
> much
> > > bigger.  This would seem to explain why only the first character
> shows
> > > up.  Why would it assume a destlen of 1?
> >=20
> > i would assume that this is originally coming from SQLColAttributes()
> > probably option SQL_COLUMN_DISPLAY_SIZE, which....(looking)....seems
> to be
> > missing floats, reals, and several other types.
> >=20
> > Might be an easy one.  Add:
> >=20
> >                case SQL_FLOAT:
> >                case SQL_REAL:
> >                case SQL_DOUBLE:
> >                    *pfDesc =3D 16; /* what makes sense here? */
> >                     break;
> >=20
> > after:
> >=20
> >    case SQL_COLUMN_DISPLAY_SIZE:
> >         switch
> > (odbc_get_client_type(colinfo->column_type,colinfo->column_size))
> >         {
> >=20
> > in odbc.c and see what gives.  Don't know why this should segfault
> though.
> >  I agree with Freddy, time for some unittests in ODBC so we aren't
> > constantly regressing.
> >=20
> >=20
> > ---
> > You are currently subscribed to freetds as:
> > [edeutsch AT exchange.systemsbiology.org]
> > To unsubscribe, forward this message to leave-freetds-
> > 149102K AT franklin.oit.unc.edu
> 
> ------_=_NextPart_001_01C25453.34651AFA
> Content-Type: application/octet-stream;
>       name="odbc.patch"
> Content-Transfer-Encoding: base64
> Content-Description: odbc.patch
> Content-Disposition: attachment;
>       filename="odbc.patch"
> 
> KioqIG9kYmMuYy1vcmlnCVdlZCBBdWcgMjggMDE6MDc6MzYgMjAwMgotLS0gb2RiYy5jCVdlZCBT
> ZXAgIDQgMTM6MDI6MTUgMjAwMgoqKioqKioqKioqKioqKioKKioqIDkwNSw5MTAgKioqKgotLS0g
> OTA1LDkxMSAtLS0tCiAgICAgICAgICB7CiAgICAgICAgICBjYXNlIFNRTF9DSEFSOgogICAgICAg
> ICAgY2FzZSBTUUxfVkFSQ0hBUjoKKyAgICAgICAgIGNhc2UgU1FMX0xPTkdWQVJDSEFSOgogICAg
> ICAgICAgICAgICpwZkRlc2MgPSBjb2xpbmZvLT5jb2x1bW5fc2l6ZTsKICAgICAgICAgICAgICBi
> cmVhazsKICAgICAgICAgIGNhc2UgU1FMX0lOVEVHRVI6CioqKioqKioqKioqKioqKgoqKiogOTE2
> LDkyNCAqKioqCi0tLSA5MTcsOTQxIC0tLS0KICAgICAgICAgIGNhc2UgU1FMX1RJTllJTlQ6CiAg
> ICAgICAgICAgICAgKnBmRGVzYyA9IDQ7CiAgICAgICAgICAgICAgYnJlYWs7CisgCisgICAgICAg
> ICBjYXNlIFNRTF9GTE9BVDoKKyAgICAgICAgIGNhc2UgU1FMX1JFQUw6CisgICAgICAgICBjYXNl
> IFNRTF9ET1VCTEU6CisgICAgICAgICBjYXNlIFNRTF9OVU1FUklDOgorICAgICAgICAgY2FzZSBT
> UUxfREVDSU1BTDoKKyAgICAgICAgIGNhc2UgU1FMX0JJR0lOVDoKKyAgICAgICAgIGNhc2UgU1FM
> X0dVSUQ6CisgICAgICAgICAgICAgKnBmRGVzYyA9IDE2OyAvKiB3aGF0IG1ha2VzIHNlbnNlIGhl
> cmU/ICovCisgICAgICAgICAgICAgYnJlYWs7CisgCiAgICAgICAgICBjYXNlIFNRTF9EQVRFOgor
> ICAgICAgICAgY2FzZSBTUUxfVElNRToKKyAgICAgICAgIGNhc2UgU1FMX1RJTUVTVEFNUDoKICAg
> ICAgICAgICAgICAqcGZEZXNjID0gMTk7CiAgICAgICAgICAgICAgYnJlYWs7CisgCWRlZmF1bHQ6
> CisgCQl0ZHNkdW1wX2xvZyhURFNfREJHX0lORk8yLCAib2RiYzpTUUxDb2xBdHRyaWJ1dGVzOiBT
> UUxfQ09MVU1OX0RJU1BMQVlfU0laRSBub3QgY2F0ZXJlZCBmb3I6ICVkXG4iLG9kYmNfZ2V0X2Ns
> aWVudF90eXBlKGNvbGluZm8tPmNvbHVtbl90eXBlLCBjb2xpbmZvLT5jb2x1bW5fc2l6ZSkpOwor
> IAkJYnJlYWs7CiAgICAgICAgICB9CiAgICAgICAgICBicmVhazsKICAJZGVmYXVsdDoKCgoKCgo=
> 
> ------_=_NextPart_001_01C25453.34651AFA--