FreeTDS Development Group

["Eric Deutsch" <edeutsch AT systemsbiology.org>]

Hi James, I just tried what I probably should have before posting: running 
the query in tsql.  It works just fine there.  Perhaps the problem is in 
dblib or ctlib, whichever one DBD::Sybase uses?  Or maybe DBD::Sybase is 
confused by it?  It does seem to report it as a varchar columntype instead of 
some special GUID columntype.

Thanks,
Eric


> -----Original Message-----
> From: Lowden, James K [mailto:LowdenJK AT bernstein.com]
> Sent: Tuesday, September 03, 2002 2:03 PM
> To: TDS Development Group
> Subject: [freetds] RE: Nonfunctional datatype: UNIQUEIDENTIFIER
> 
> > From: Eric Deutsch [mailto:edeutsch AT systemsbiology.org]
> > Sent: September 3, 2002 4:00 PM
> >
> > When I do a query against such a column (using DBD::Sybase), I get:
> >
> > [QUERY]: SELECT TOP 5 ConditionsID,s_GUID FROM
> > accesstemp.dbo.[Human PCR Conditions]
> > error_handler: Data-conversion resulted in overflow.
> > =-2104898907|šÂ@=
> > error_handler: Data-conversion resulted in overflow.
> > =-2102394566|šÂ@=
> > error_handler: Data-conversion resulted in overflow.
> > =-2098241821|šÂ@=
> > error_handler: Data-conversion resulted in overflow.
> > =-2097918306|šÂ@=
> > error_handler: Data-conversion resulted in overflow.
> > =-2094131412|šÂ@=
> >
> > The first column is correct, but the second appears to be
> > garbled junk.  In one test, I got the program to dump a 1 GB
> > core, but that doesn't always happen.
> 
> Eric,
> 
> It's broken, which is strange because I think we had it working.  Here's
> Microsoft:
> 
> 1> select 1, newid(), newid(), newid()
> 2>
> 3> go
>  ----------- ------------------------------------
>         ------------------------------------
>         ------------------------------------
>            1 B5E5CACC-9FEB-11D6-A60C-000629C98DEB
>         B5E5CACD-9FEB-11D6-A60C-000629C98DEB
>         B5E5CACE-9FEB-11D6-A60C-000629C98DEB
> 
> (1 row affected)
> 
> Note the nice progression in the first part of the string, CC, CD, CE.
> All
> else is steady.  Also the column width is reasonable.
> 
> With FreeTDS, I get more and more zeros with each query, and the column
> length is not reasonable.  There's no reason textsize should affect the
> size, BTW.  FreeTDS receives the UNIQUEIDENTIFIER as a structure of
> integers, not as ntext.  I don't happen to know how sqsh converts it.
> Here's sqsh+FreeTDS, linked with a snapshot from last week:
> 
> 1> select 1, newid(), newid(), newid()
> 2> go
>  -----------
> 
> ------------------------------------------------------------------------
> --------------------------------------------------------------------------
> --
> ----
> --------------------------------------------------------------------------
> --
> ----
> ------------------------
> 
> ------------------------------------------------------------------------
> --------------------------------------------------------------------------
> --
> ----
> --------------------------------------------------------------------------
> --
> ----
> ------------------------
> 
> ------------------------------------------------------------------------
> --------------------------------------------------------------------------
> --
> ----
> --------------------------------------------------------------------------
> --
> ----
> ------------------------
>            1
>         4C6D694A-776F-6564-6E00-000000000000
> 
> 
> 
>         4C2D5443-6269-6172-7279-000000000000
> 
> 
> 
>         36393034-0000-0030-0000-000000000000
> 
> 
> 
> 
> (1 row affected)
> 
> You can work around this with "select convert(varchar(36), newid())" for
> now.
> 
> --jkl
> 
> 
> The information contained in this transmission may contain privileged and
> confidential information and is intended only for the use of the person(s)
> named above.  If you are not the intended recipient, or an employee or
> agent
> responsible for delivering this message to the intended recipient, any
> review, dissemination, distribution or duplication of this communication
> is
> strictly prohibited. If you are not the intended recipient, please contact
> the sender immediately by reply e-mail and destroy all copies of the
> original message. Please note that for certain accounts we do not accept
> orders and/or instructions by e-mail, and for those accounts we will not
> be
> responsible for carrying out such orders and/or instructions. Kindly
> refrain
> from sending orders or instructions by e-mail unless you have confirmed
> that
> we accept such communications for your account. Please also note that to
> satisfy regulatory requirements we review the outgoing and incoming e-mail
> correspondence of staff members serving certain functions.
> 
> 
> 
> ---
> 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