Skip to Content.
Sympa Menu

freetds - Re: prerelease delayed by documentation

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: prerelease delayed by documentation
  • Date: Fri, 6 Sep 2002 07:07:30 -0400 (EDT)



Eric, can you send me the source to your perl program so I can play around
with it a bit. I'll email you the email address to use off list.

Brian

On Thu, 5 Sep 2002, Eric Deutsch wrote:

>
> > From: Brian Bruns [mailto: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?
>
> Yes, this is using DBD::ODBC. I have attached the output of my program
> (brian1.txt) as well as the tdsdump.log. I think you ought to be able
> to follow through what it's doing and how it's failing. Let me know if
> you have questions about it.
>
> > 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.
>
> Yes, total number of chars remain contant, i.e. it is padding the string
> to a fixed length. That length appears to be the "destlen" value as
> reported in the tdsdump.log. Note that in the attached brian1.txt file,
> the \x00's are not there because I just did a screen grab. I attached
> another file (brian2.txt) which is a similar query (without the
> textfield which causes the core dump) that includes all the \x00's.
>
> Let me know if there's anything else I can provide!
>
> Thanks,
> Eric
>
>
>
> > 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"
> > >
> > >
> >
> KioqIG9kYmMuYy1vcmlnCVdlZCBBdWcgMjggMDE6MDc6MzYgMjAwMgotLS0gb2RiYy5jCVdl
> ZC
> > BT
> > >
> >
> ZXAgIDQgMTM6MDI6MTUgMjAwMgoqKioqKioqKioqKioqKioKKioqIDkwNSw5MTAgKioqKgot
> LS
> > 0g
> > >
> >
> OTA1LDkxMSAtLS0tCiAgICAgICAgICB7CiAgICAgICAgICBjYXNlIFNRTF9DSEFSOgogICAg
> IC
> > Ag
> > >
> >
> ICAgY2FzZSBTUUxfVkFSQ0hBUjoKKyAgICAgICAgIGNhc2UgU1FMX0xPTkdWQVJDSEFSOgog
> IC
> > Ag
> > >
> >
> ICAgICAgICAgICpwZkRlc2MgPSBjb2xpbmZvLT5jb2x1bW5fc2l6ZTsKICAgICAgICAgICAg
> IC
> > Bi
> > >
> >
> cmVhazsKICAgICAgICAgIGNhc2UgU1FMX0lOVEVHRVI6CioqKioqKioqKioqKioqKgoqKiog
> OT
> > E2
> > >
> >
> LDkyNCAqKioqCi0tLSA5MTcsOTQxIC0tLS0KICAgICAgICAgIGNhc2UgU1FMX1RJTllJTlQ6
> Ci
> > Ag
> > >
> >
> ICAgICAgICAgICAgKnBmRGVzYyA9IDQ7CiAgICAgICAgICAgICAgYnJlYWs7CisgCisgICAg
> IC
> > Ag
> > >
> >
> ICBjYXNlIFNRTF9GTE9BVDoKKyAgICAgICAgIGNhc2UgU1FMX1JFQUw6CisgICAgICAgICBj
> YX
> > Nl
> > >
> >
> IFNRTF9ET1VCTEU6CisgICAgICAgICBjYXNlIFNRTF9OVU1FUklDOgorICAgICAgICAgY2Fz
> ZS
> > BT
> > >
> >
> UUxfREVDSU1BTDoKKyAgICAgICAgIGNhc2UgU1FMX0JJR0lOVDoKKyAgICAgICAgIGNhc2Ug
> U1
> > FM
> > >
> >
> X0dVSUQ6CisgICAgICAgICAgICAgKnBmRGVzYyA9IDE2OyAvKiB3aGF0IG1ha2VzIHNlbnNl
> IG
> > hl
> > >
> >
> cmU/ICovCisgICAgICAgICAgICAgYnJlYWs7CisgCiAgICAgICAgICBjYXNlIFNRTF9EQVRF
> Og
> > or
> > >
> >
> ICAgICAgICAgY2FzZSBTUUxfVElNRToKKyAgICAgICAgIGNhc2UgU1FMX1RJTUVTVEFNUDoK
> IC
> > Ag
> > >
> >
> ICAgICAgICAgICAqcGZEZXNjID0gMTk7CiAgICAgICAgICAgICAgYnJlYWs7CisgCWRlZmF1
> bH
> > Q6
> > >
> >
> CisgCQl0ZHNkdW1wX2xvZyhURFNfREJHX0lORk8yLCAib2RiYzpTUUxDb2xBdHRyaWJ1dGVz
> Oi
> > BT
> > >
> >
> UUxfQ09MVU1OX0RJU1BMQVlfU0laRSBub3QgY2F0ZXJlZCBmb3I6ICVkXG4iLG9kYmNfZ2V0
> X2
> > Ns
> > >
> >
> aWVudF90eXBlKGNvbGluZm8tPmNvbHVtbl90eXBlLCBjb2xpbmZvLT5jb2x1bW5fc2l6ZSkp
> Ow
> > or
> > >
> >
> IAkJYnJlYWs7CiAgICAgICAgICB9CiAgICAgICAgICBicmVhazsKICAJZGVmYXVsdDoKCgoK
> Cg
> > o=
> > >
> > > ------_=_NextPart_001_01C25453.34651AFA--
> >
> > ---
> > 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
>





Archive powered by MHonArc 2.6.24.

Top of Page