freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: [freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE
- From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE
- Date: Wed, 26 Mar 2008 10:02:21 +0100
>
> Federico Alves wrote:
> > I open a ticket with DBD-Sybase and the author Michel Peppler thinks
> > there is an issue
> > with freetds, not with DBD-Sybase.
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=34411 >
> >
> > On Mon Mar 24 20:19:06 2008, falves1 wrote:
> > > I compiled DBD-Sybase 1.08 using DBI 1.604, and the perl
> Makefile.PL
> > > works fine, but then when I do a make I get this
> > > Sybase.xsi:275: error: invalid lvalue in assignment
> > > Sybase.xsi: In function âXS_DBD__Sybase__db_DESTROYâ:
> > > Sybase.xsi:334: error: invalid lvalue in assignment
> > > make: *** [Sybase.o] Error 1
> >
> > This is a problem with FreeTDS.
> >
> > The issue is that FreeTDS defines CS_UINT_TYPE, but not
> CS_BIGINT_TYPE,
> > and Sybase never defines one without the other.
>
> I'm not convinced this is a "problem" with FreeTDS, and I'm
> not sure how
> to fix it.
>
> FreeTDS doesn't guarantee line-by-line compatibility with
> Sybase's header
> files. The project's header files describe the functions,
> structures, and
> datatypes implemented by the library. If CS_UINT_TYPE but not
> CS_BIGINT_TYPE is supported/used/implemented by the library, then only
> CS_UINT_TYPE *should* appear in the header file. Anything else would
> mislead the developer: the translation unit might compile but fail to
> link, or link and not work.
>
> Michael, AIUI DBD::Sybase assumes CS_BIGINT_TYPE upon testing for
> CS_UINT_TYPE. Wouldn't it be better to test for
> CS_BIGINT_TYPE directly?
>
>
> I'm always eager to make sure FreeTDS supports DBD::Sybase to
> the extent
> possible, allowing for deficiencies in the implementation. But adding
> something to the header file not implemented by the library could
> adversely affect other users.
>
I checked the code and it seems that CS_BIGINT_TYPE, CS_DATE_TYPE,
CS_TIME_TYPE and CS_UINT_TYPE are not so supported. I also don't know how
easy is implementing unsigned types and date/time. What happen for instance
if we send unsigned data to ms sql? Perhaps it would be better to undefine
these constants.
freddy77
-
Re: [freetds] FreeTDS Digest, Vol 62, Issue 20,
Federico Alves, 03/25/2008
-
[freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE,
James K. Lowden, 03/25/2008
- Re: [freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE, Michael Peppler, 03/26/2008
- Re: [freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE, ZIGLIO, Frediano, VF-IT, 03/26/2008
-
Re: [freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE,
Michael Peppler, 03/27/2008
- Re: [freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE, ZIGLIO, Frediano, VF-IT, 03/27/2008
-
[freetds] CS_UINT_TYPE, but not CS_BIGINT_TYPE,
James K. Lowden, 03/25/2008
Archive powered by MHonArc 2.6.24.