FreeTDS Development Group

["Federico Alves" <sales AT minixel.com>]

If I don´t include a dummy statement like "select 'Result'=1", the driver or
the application thinks that the stored procedure failed and sends the
request again. There is a bug pending since 2008-02-14 in the SourceForge
page that I think is related: "MS SQL Stored Procedure has no return value".


-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of
freetds-request AT lists.ibiblio.org
Sent: Wednesday, February 20, 2008 12:19 AM
To: freetds AT lists.ibiblio.org
Subject: FreeTDS Digest, Vol 61, Issue 9

Send FreeTDS mailing list submissions to
        freetds AT lists.ibiblio.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ibiblio.org/mailman/listinfo/freetds
or, via email, send a message with subject or body 'help' to
        freetds-request AT lists.ibiblio.org

You can reach the person managing the list at
        freetds-owner AT lists.ibiblio.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of FreeTDS digest..."


Today's Topics:

   1. Re: 0.82 status (Craig A. Berry)
   2. freetds-0.64 problems on fc6 (freetds_help AT nym.hush.com)
   3. Re: freetds-0.64 problems on fc6 (ZIGLIO, Frediano, VF-IT)
   4. Re: freetds-0.64 problems on fc6 (freetds_help AT nym.hush.com)
   5. Double execution (Federico Alves)
   6. Re: 64 Bit Machine Available (Federico Alves)


----------------------------------------------------------------------

Message: 1
Date: Sun, 17 Feb 2008 18:59:39 -0600
From: "Craig A. Berry" <craigberry AT mac.com>
Subject: Re: [freetds] 0.82 status
To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
Message-ID: <p06240800c3de87a3ac56@[172.16.52.1]>
Content-Type: text/plain; charset="us-ascii"

At 3:35 PM -0600 2/9/08, Craig A. Berry wrote:
> With both 0.82rc1 and with the development snapshot dated 20080209, I get
a clean build using
>
>$ cc/version
>HP C V7.3-009 on OpenVMS Alpha V8.3
>
>Running tests will have to wait until I can get the SQL 2005 Express
Edition on my home network to actually listen on the network, which at the
current rate may be never.

Either I overcame my resistance to getting SQL 2005 configured or it
overcame it's resistance to me, but I've now got it working and have
run the FreeTDS test suite with all tests passing,  the only caveat
being that I still need to add support to build some of the newer tests.

I also discovered that the system-supplied iconv() is broken in a
couple of nasty ways, so the attached patch turns it off by default
so we use the FreeTDS home-grown implementation.

-- 
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vms_iconv.patch
Type: application/octet-stream
Size: 715 bytes
Desc: not available
Url :
https://lists.ibiblio.org/sympa/arc/freetds/attachments/20080217/a69bb313/att
achment-0001.obj 

------------------------------

Message: 2
Date: Mon, 18 Feb 2008 17:03:45 -0600
From: <freetds_help AT nym.hush.com>
Subject: [freetds] freetds-0.64 problems on fc6
To: <freetds AT lists.ibiblio.org>
Message-ID: <20080218230345.B5F9315803D AT mailserver6.hushmail.com>
Content-Type: text/plain; charset="UTF-8"

Hello FreeTDS mailing list,

In the hopes of finding a reason to this problem and hopefully a 
solution I'm turning to this list. Any/all communications back are 
greatly appreciated.

FreeTDS Version 0.64
2.6.18-1.2798.fc6 on i686 athlon

Utilizing the FreeTDS client to communicate with a customer's site 
and while doing so over the past 24hrs the libraries and 
executables for FreeTDS become...defunct for lack of a better 
descriptor. It must be mentioned that we've been successfully 
utilizing the freetds client for over a month's time with zero 
problems until yesterday.

The best way to describe the problem is with the following "ls" 
output from /usr/local/lib:
> ?---------  ? ?    ?          ?            ? libct.la
> ?---------  ? ?    ?          ?            ? libct.so.4.0.0
> ?---------  ? ?    ?          ?            ? libsybdb.a
> ?---------  ? ?    ?          ?            ? libsybdb.so.5.0.0
> ?---------  ? ?    ?          ?            ? libtdssrv.so.2
> ?---------  ? ?    ?          ?            ? libtdssrv.so.2.0.0 

and /usr/local/bin:
> ?---------  ? ?    ?         ?            ? bsqldb
> ?---------  ? ?    ?         ?            ? datacopy
> ?---------  ? ?    ?         ?            ? defncopy
> ?---------  ? ?    ?         ?            ? freebcp 

Has anyone seen this problem before or encountered such an outcome?

Thanks again...



------------------------------

Message: 3
Date: Tue, 19 Feb 2008 11:02:32 +0100
From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
Subject: Re: [freetds] freetds-0.64 problems on fc6
To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
Message-ID:
        <72EBB5FADDA71343B78E1F09FF471F6E4526D7 AT OBOMEXO02.omnitel.it>
Content-Type: text/plain;       charset=US-ASCII

> 
> Hello FreeTDS mailing list,
> 
> In the hopes of finding a reason to this problem and hopefully a 
> solution I'm turning to this list. Any/all communications back are 
> greatly appreciated.
> 
> FreeTDS Version 0.64
> 2.6.18-1.2798.fc6 on i686 athlon
> 
> Utilizing the FreeTDS client to communicate with a customer's site 
> and while doing so over the past 24hrs the libraries and 
> executables for FreeTDS become...defunct for lack of a better 
> descriptor. It must be mentioned that we've been successfully 
> utilizing the freetds client for over a month's time with zero 
> problems until yesterday.
> 
> The best way to describe the problem is with the following "ls" 
> output from /usr/local/lib:
> > ?---------  ? ?    ?          ?            ? libct.la
> > ?---------  ? ?    ?          ?            ? libct.so.4.0.0
> > ?---------  ? ?    ?          ?            ? libsybdb.a
> > ?---------  ? ?    ?          ?            ? libsybdb.so.5.0.0
> > ?---------  ? ?    ?          ?            ? libtdssrv.so.2
> > ?---------  ? ?    ?          ?            ? libtdssrv.so.2.0.0 
> 
> and /usr/local/bin:
> > ?---------  ? ?    ?         ?            ? bsqldb
> > ?---------  ? ?    ?         ?            ? datacopy
> > ?---------  ? ?    ?         ?            ? defncopy
> > ?---------  ? ?    ?         ?            ? freebcp 
> 
> Has anyone seen this problem before or encountered such an outcome?
> 
> Thanks again...
> 

?? quite strange. Why ls can't read filesystem informations?? filesystem
corruption? Too strict security (SELinux or others)?? System resources
exhausted? Rebooting system fix the problem? Closing applications using
FreeTDS?

freddy77


------------------------------

Message: 4
Date: Tue, 19 Feb 2008 08:11:52 -0600
From: <freetds_help AT nym.hush.com>
Subject: Re: [freetds] freetds-0.64 problems on fc6
To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
Message-ID: <20080219141152.6DE121A003A AT mailserver8.hushmail.com>
Content-Type: text/plain; charset="UTF-8"



On Tue, 19 Feb 2008 04:02:32 -0600 "ZIGLIO, Frediano, VF-IT" 
<Frediano.Ziglio AT vodafone.com> wrote:
>> 
>> Hello FreeTDS mailing list,
>> 
>> In the hopes of finding a reason to this problem and hopefully a 
>
>> solution I'm turning to this list. Any/all communications back 
>are 
>> greatly appreciated.
>> 
>> FreeTDS Version 0.64
>> 2.6.18-1.2798.fc6 on i686 athlon
>> 
>> Utilizing the FreeTDS client to communicate with a customer's 
>site 
>> and while doing so over the past 24hrs the libraries and 
>> executables for FreeTDS become...defunct for lack of a better 
>> descriptor. It must be mentioned that we've been successfully 
>> utilizing the freetds client for over a month's time with zero 
>> problems until yesterday.
>> 
>> The best way to describe the problem is with the following "ls" 
>> output from /usr/local/lib:
>> > ?---------  ? ?    ?          ?            ? libct.la
>> > ?---------  ? ?    ?          ?            ? libct.so.4.0.0
>> > ?---------  ? ?    ?          ?            ? libsybdb.a
>> > ?---------  ? ?    ?          ?            ? libsybdb.so.5.0.0
>> > ?---------  ? ?    ?          ?            ? libtdssrv.so.2
>> > ?---------  ? ?    ?          ?            ? 
>libtdssrv.so.2.0.0 
>> 
>> and /usr/local/bin:
>> > ?---------  ? ?    ?         ?            ? bsqldb
>> > ?---------  ? ?    ?         ?            ? datacopy
>> > ?---------  ? ?    ?         ?            ? defncopy
>> > ?---------  ? ?    ?         ?            ? freebcp 
>> 
>> Has anyone seen this problem before or encountered such an 
>outcome?
>> 
>> Thanks again...
>> 
>
>?? quite strange. Why ls can't read filesystem informations?? 
>filesystem
>corruption? Too strict security (SELinux or others)?? System 
>resources
>exhausted? Rebooting system fix the problem? Closing applications 
>using
>FreeTDS?
>
>freddy77

that's part of my question, why would freetds cause the 
files/libraries to disappear and ls not be able to read them once 
it encountered an error?

Filesystem corruption, maybe. The system was rebooted and fscked 
(all errors repaired and clean) two weeks ago and all drive reports 
say the system is clean. Since the reboot & fsck, freetds has 
worked without a problem until now.

SELinux is disabled

System resources on a separate partition (/var) hit 100% due to 
faulty programming from one of the engineers. After resource 
problem was resolved the freetds problem (on a different partition, 
"/") was found.

This is on a production level system so I'm attempting to track 
down the problem first rather than give into rebooting.

All applications that utilize this package are stopped as they 
won't run without the freetds files that are currently unaccessible.

Thanks for the reply freddy77...



------------------------------

Message: 5
Date: Tue, 19 Feb 2008 23:50:33 -0500
From: "Federico Alves" <sales AT minixel.com>
Subject: [freetds] Double execution
To: <freetds AT lists.ibiblio.org>
Message-ID: <011301c8737c$20bff890$623fe9b0$@com>
Content-Type: text/plain;       charset="us-ascii"

I have a big problem: freetds is executing a stored procedure twice, for one
call. I know it is freetds because I also have installed the easysoft driver
and when I use Asterisk with it, it does not happen. I have a version number
0.83.dev.20080110. Is there a newer version available??





------------------------------

Message: 6
Date: Tue, 19 Feb 2008 23:58:08 -0500
From: "Federico Alves" <sales AT minixel.com>
Subject: Re: [freetds] 64 Bit Machine Available
To: "'ZIGLIO, Frediano, VF-IT'" <Frediano.Ziglio AT vodafone.com>
Cc: freetds AT lists.ibiblio.org
Message-ID: <011401c8737d$3064d580$912e8080$@com>
Content-Type: text/plain;       charset="iso-8859-1"

I am trying to compile version 0.83.dev.20080219 and I get this:

T write.lo -MD -MP -MF .deps/write.Tpo -c write.c -o write.o >/dev/null 2>&1
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I../../include  -I../../include -D_FREETDS_LIBRARY_SOURCE -DUNIXODBC
-DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG
-DSIZEOF_LONG_INT=4  -D_REENTRANT -D_THREAD_SAFE -DDEBUG=1 -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wno-long-long -pthread -fPIC
-Wdeclaration-after-statement -MT convert.lo -MD -MP -MF ".deps/convert.Tpo"
-c -o convert.lo convert.c; \
then mv -f ".deps/convert.Tpo" ".deps/convert.Plo"; else rm -f
".deps/convert.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
-D_FREETDS_LIBRARY_SOURCE -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H
-DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -D_REENTRANT
-D_THREAD_SAFE -DDEBUG=1 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wno-long-long -pthread -fPIC -Wdeclaration-after-statement -MT convert.lo
-MD -MP -MF .deps/convert.Tpo -c convert.c  -fPIC -DPIC -o .libs/convert.o
convert.c: In function `tds_willconvert':
convert.c:2904: error: duplicate case value
convert.c:2899: error: previously used here
make[4]: *** [convert.lo] Error 1
make[4]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src/tds'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src/tds'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src/tds'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/freetds-0.83.dev.20080219/src'
make: *** [all-recursive] Error 1

-----Original Message-----
From: ZIGLIO, Frediano, VF-IT [mailto:Frediano.Ziglio AT vodafone.com] 
Sent: Tuesday, January 29, 2008 10:41 AM
To: Federico Alves
Subject: RE: [freetds] 64 Bit Machine Available

Hi Federico,
  thanks for your support. I'll remind your offer when needed. I think that
problem is quite big and will require a lot of time... just to sum up
- Microsoft documentation is wrong, insufficient and not updated. I wrote
some feedback but I know it will take longer
- Linux have two 64-bit ODBC ABI compatibility even using the same DM
(unixODBC)

Here we tested for some ABI for 64-bit and we currently want to provide a
driver which is compatible with any installed DM but till all vendors will
decide an unified 64-bit ODBC API all ODBC developers will have to take very
care developing ODBC applications.

Regards
  Frediano Ziglio

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org 
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Federico Alves
> Sent: luned? 21 gennaio 2008 15.57
> To: freetds AT lists.ibiblio.org
> Subject: [freetds] 64 Bit Machine Available
> 
> Dear Freddy
> I also have a 64 Bit Windows machine available for testing, 
> with SQL 2005
> installed. Please contact me via email if you need the 
> admininstrator login.
> Federico
> 
> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org
> [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of
> freetds-request AT lists.ibiblio.org
> Sent: Monday, January 21, 2008 3:37 AM
> To: freetds AT lists.ibiblio.org
> Subject: FreeTDS Digest, Vol 60, Issue 31
> 
> Send FreeTDS mailing list submissions to
>       freetds AT lists.ibiblio.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.ibiblio.org/mailman/listinfo/freetds
> or, via email, send a message with subject or body 'help' to
>       freetds-request AT lists.ibiblio.org
> 
> You can reach the person managing the list at
>       freetds-owner AT lists.ibiblio.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FreeTDS digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: FreeTDS Digest, Vol 60, Issue 30 (Federico Alves)
>    2. freetds-0.64 install/configure on Solaris10 all 64-bit env
>       using Sun Compiler - ELF64 error (Alek Fiakhretdinov)
>    3. Re: Ongoing work for released version of FreeTDS        
> version0,
>       64, 0, 6182 (Dann Corbit)
>    4. Optimizing memory allocation when using dynamic SQL
>       (Sebastien FLAESCH)
>    5. Re: FreeTDS Digest, Vol 60, Issue 30 (ZIGLIO, Frediano, VF-IT)
>    6. Re: ODBC on 64 bit linux fix. (ZIGLIO, Frediano, VF-IT)
>    7. Re: ODBC on 64 bit linux fix. (Sebastien FLAESCH)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 18 Jan 2008 16:35:45 -0500
> From: "Federico Alves" <sales AT minixel.com>
> Subject: Re: [freetds] FreeTDS Digest, Vol 60, Issue 30
> To: <freetds AT lists.ibiblio.org>
> Message-ID: <037301c85a1a$161b8150$425283f0$@com>
> Content-Type: text/plain;     charset="us-ascii"
> 
> If somebody needs a 64 Bit machine for testing, Freddy can 
> use the one that
> he knows. He has the IP address and the password. It is a RED 
> HAT 5 with
> license.
> Federico
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 18 Jan 2008 18:26:11 -0500
> From: Alek Fiakhretdinov <alek.fiakhretdinov AT db.com>
> Subject: [freetds] freetds-0.64 install/configure on Solaris10 all
>       64-bit env using Sun Compiler - ELF64 error
> To: freetds AT lists.ibiblio.org
> Message-ID:
>       
> <OFA1C752DA.A206D6CA-ON852573D4.00792B77-852573D4.0080B7D9 AT db.com>
> Content-Type: text/plain; charset="US-ASCII"
> 
> Dear freetds community,
> 
> I am trying to install and configure the latest freetds-0.64  
> kit together 
> with DBD::Sybase driver on Solaris-10 all 64-bit environment.
> Perl itself has been rebuilt with 'use64bitint=define, 
> use64bitall=define' 
> options and successfully works with a few database modules (Sybperl, 
> DBD::Oracle) - all installed using the same CFLAGS as were 
> used during 
> Perl installation.
> 
> I am using SUN compiler and associated build tools (not gcc).
> 
> The problem is that I can't have a loader to use a correct 
> set of 64-bit 
> libraries during the 'make' step of the FreeTDS installation 
> even though 
> per my understanding I am providing all necessary info.
> 
> Will Greatly (!!!) appreciate any help as I was struggling 
> with this for a 
> few days with no luck.
> 
> Here are the details:
> 
> 1.      Perl
> 
> $ perl -V
> Summary of my perl5 (revision 5 version 10 subversion 0) 
> configuration:
>   Platform:
>     osname=solaris, osvers=2.10, archname=sun4-solaris-64
>     uname='sunos nygmwsp011.us.db.com 5.10 generic_118833-33 
> sun4u sparc 
> sunw,sun-blade-100 '
>     config_args='-Dprefix=/usr/perl5/5.10.0 -Duse64bitall 
> -Duse64bitint 
> -de'
>     hint=recommended, useposix=true, d_sigaction=define
>     useithreads=undef, usemultiplicity=undef
>     useperlio=define, d_sfio=undef, uselargefiles=define, 
> usesocks=undef
>     use64bitint=define, use64bitall=define, uselongdouble=undef
>     usemymalloc=n, bincompat5005=undef
>   Compiler:
>     cc='cc', ccflags ='-xarch=generic64 -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV',
>     optimize='-O',
>     cppflags='-xarch=generic64'
>     ccversion='Sun WorkShop 6 update 1 C 5.2 2000/09/11', 
> gccversion='', 
> gccosandvers=''
>     intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
>     d_longlong=define, longlongsize=8, d_longdbl=define, 
> longdblsize=16
>     ivtype='long', ivsize=8, nvtype='double', nvsize=8, 
> Off_t='off_t', 
> lseeksize=8
>     alignbytes=8, prototype=define
>   Linker and Libraries:
>     ld='cc', ldflags =' -xarch=generic64 
> -L/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> -L/usr/lib/sparcv9 
> -L/usr/ccs/lib/sparcv9 '
>     libpth=/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> /usr/lib/sparcv9 /usr/ccs/lib/sparcv9 /usr/lib /usr/ccs/lib
>     libs=-lsocket -lnsl -ldl -lm -lc
>     perllibs=-lsocket -lnsl -ldl -lm -lc
>     libc=/usr/lib/sparcv9/libc.so, so=so, useshrplib=false, 
> libperl=libperl.a
>     gnulibc_version=''
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
>     cccdlflags='-KPIC', lddlflags=' -G -xarch=generic64 
> -L/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> -L/usr/lib/sparcv9 
> -L/usr/ccs/lib/sparcv9'
> 
> 
> Characteristics of this binary (from libperl):
>   Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
>                         PERL_USE_SAFE_PUTENV USE_64_BIT_ALL 
> USE_64_BIT_INT
>                         USE_LARGE_FILES USE_PERLIO
>   Built under solaris
>   Compiled at Jan 11 2008 15:59:18
>   @INC:
>     /usr/perl5/5.10.0/lib/5.10.0/sun4-solaris-64
>     /usr/perl5/5.10.0/lib/5.10.0
>     /usr/perl5/5.10.0/lib/site_perl/5.10.0/sun4-solaris-64
>     /usr/perl5/5.10.0/lib/site_perl/5.10.0
> 
> 
> 2.      Solaris env in my session:
> 
> PATH=/usr/xpg4/bin:/usr/ccs/bin:/db/pub/infra/SUNWspro/6.1p9/S
> UNWspro/bin:/u
> sr/bin:.
> CFLAGS=-xarch=generic64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -DPERL_USE_SAFE_PUTENV
> LDFLAGS= -xarch=generic64 
> -L/db/pub/infra/SUNWspro/6.1p9/SUNWspro/WS6U1/lib/v9 
> -L/usr/lib/sparcv9 
> -L/usr/ccs/lib/sparcv9
> LD_LIBRARY_PATH=/usr/ccs/lib/sparcv9:/usr/lib/sparcv9:/db/pub/
> infra/SUNWspro
> /6.1p9/SUNWspro/WS6U1/lib/v9
> 
> 3.      configure 
> 
> ./configure --disable-odbc --disable-libiconv --enable-sybase-compat 
> --prefix=/usr/local/freetds --with-tdsver=7.0
> 
> Configure comes up with a libtool which for some reason 
> generates a C++ - 
> like commands so I have to edit the libtool to change the 
> following line:
> 
> wl="-Wl,"
> 
> to
> 
> wl=""
> 
> In this case 'make' comes up with the follwoing log:
> 
> Which has the following warnings:
> 
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "query.c", line 1464: warning: assignment type mismatch:
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> ld: warning: file ./.libs/libtds_objects.a(mem.o): wrong ELF class: 
> ELFCLASS64
> ld: warning: file 
> ../replacements/.libs/libreplacements.a(iconv.o): wrong 
> ELF class: ELFCLASS64
> ld: warning: Symbol referencing errors
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "ct.c", line 767: warning: statement not reached
> "ct.c", line 3925: warning: statement not reached
> "ct.c", line 4186: warning: argument #1 is incompatible with 
> prototype:
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "blk.c", line 520: warning: statement not reached
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "dblib.c", line 3499: warning: statement not reached
> "dblib.c", line 4124: warning: initializer does not fit or is out of 
> range: 32768
> "dblib.c", line 4770: warning: statement not reached
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "bcp.c", line 1493: warning: statement not reached
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "../../include/tds.h", line 1244: warning: dubious tag 
> declaration: struct 
> in_addr
> "unittest.c", line 84: warning: assignment type mismatch:
> 
> 5.      Question: what's wrong in my ENV and how can I have 
> the configure 
> tool to generate the right libtool, etc. ?
> 
> 
> Regards,
> =Alek
> 
> 
> ---
> 
> This e-mail may contain confidential and/or privileged 
> information. If you 
> are not the intended recipient (or have received this e-mail 
> in error) 
> please notify the sender immediately and destroy this e-mail. Any 
> unauthorized copying, disclosure or distribution of the 
> material in this 
> e-mail is strictly forbidden.
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 18 Jan 2008 18:30:19 -0800
> From: "Dann Corbit" <DCorbit AT connx.com>
> Subject: Re: [freetds] Ongoing work for released version of FreeTDS
>       version0,       64, 0, 6182
> To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> Message-ID:
>       
> <D425483C2C5C9F49B5B7A41F8944154701000BCC AT postal.corporate.connx.com>
> Content-Type: text/plain;     charset="us-ascii"
> 
> [snip]
> I said:
> > > There are no guarantees on the addresses alignments that clients
> want to
> > > bind to.
> > >
> > > Consider:
> > > The client creates a memory buffer with the following properties:
> > > For every field there is a leading character which will 
> be 1 if the
> > > field is null and zero if the field is not null.  Every field will
> also
> > > be stored in the memory buffer using its exact width.  
> Now, suppose
> that
> > > the first field in the result set is a single character.  Then the
> next
> > > field will start at offset 3.  For many CPUs, this will 
> cause a bus
> > > error if the succeeding data is simply assigned to a pointer that
> wants
> > > alignment to a type and the type does not support character
> alignment.
> > >
> > > The reason that we made the changes above is that we 
> *were* getting
> bus
> > > errors in running some of our regression tests on some platforms.
> > >
> > 
> > Mmmm... from msdn (linked from SQLBindCol reference)
> > 
> > http://msdn2.microsoft.com/en-us/library/ms709306(VS.85).aspx
> > 
> > So data should be aligned by program. It's also true that we don't
> live
> > in a perfect world so if you tested that others drivers works in all
> > cases it's worth to write such a workaround. Personally I currently
> > don't have a test environment like this.
> 
> You're quite right.  The specification clearly says that the 
> data should
> be properly aligned.  I guess we just altered our source to 
> placate the
> customers, and added the problem generator to our regression tests.
> 
> I think we will probably just maintain our own version of this file.
> Even though the FreeTDS clearly does the right thing, I think 
> it will be
> cheaper for us than fielding technical support calls.  So I do repent
> and retract in dust and ashes.
> ;-)
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sat, 19 Jan 2008 12:13:08 +0100
> From: Sebastien FLAESCH <sf AT 4js.com>
> Subject: [freetds] Optimizing memory allocation when using dynamic SQL
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Message-ID: <4791DB44.7010600 AT 4js.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Dear all,
> 
> Frediano Ziglio wrote:
> > http://msdn2.microsoft.com/en-us/library/ms709306(VS.85).aspx
> 
> Interesting, I knew about alignment issues, but from an 
> optimization point
> of
> view I have always asked myself if doing several malloc() of 
> little pieces
> of
> memory is really an issue...
> 
> We used to have our own mem allocation wrapper to optimize 
> this in our VM
> but
> we have removed it in latest version to just use malloc() as is...
> allocating
> any size of memory...
> 
> I really wonder if C runtime library providers (on any 
> platform) did not yet
> optimize malloc() to allocate large blocks of memory (I mean, if you
> allocate
> 4 bytes, does it really just allocate 4 bytes or does it pick 
> 4b in a memory
> pool
> or whatever and just increment an internal offset)?
> 
> This is a real issue for use, as we have different sort of database
> interfaces
> and need to allocate buffers for dynamic SQL result sets...
> 
> Note also that such kind of memory optimizations is IMHO not 
> significant if
> you compare with database communication... am I wrong?
> 
> Any comment/advice is welcome!
> 
> Thanks a lot.
> 
> ;-)
> Seb
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 21 Jan 2008 09:20:55 +0100
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
> Subject: Re: [freetds] FreeTDS Digest, Vol 60, Issue 30
> To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> Message-ID:
>       <72EBB5FADDA71343B78E1F09FF471F6E452659 AT OBOMEXO02.omnitel.it>
> Content-Type: text/plain;     charset=US-ASCII
> 
> > 
> > If somebody needs a 64 Bit machine for testing, Freddy can 
> > use the one that
> > he knows. He has the IP address and the password. It is a RED 
> > HAT 5 with
> > license.
> > Federico
> > 
> 
> Thanks Federico, in this case I needed a windows 64 machine 
> to test some
> MS implementations.
> 
> freddy77
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 21 Jan 2008 09:25:53 +0100
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
> Subject: Re: [freetds] ODBC on 64 bit linux fix.
> To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
> Message-ID:
>       <72EBB5FADDA71343B78E1F09FF471F6E45265A AT OBOMEXO02.omnitel.it>
> Content-Type: text/plain;     charset=US-ASCII
> 
> > 
> > We have Windows 64b (with VC++ 8 of course) and Linux 64b 
> > machines here...
> > 
> > Send us a test program and we'll check if you want.
> > 
> > Seb
> > 
> 
> I wrote a small test at
> http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/un
> ittests/te
> st64.c?view=log. This source is a unittest for freetds so it require
> common.c and common.h to compile and PWD file to configure.
> 
> It works under win32 and linux x86_64 (I used unixODBC and 
> ubuntu 7.10).
> 
> Yesterday I managed to get win64 cross compile (thanks to mingw-w64
> project!). Can I send you compiled freetds for win64 to test?
> 
> freddy77
> 
> > ZIGLIO, Frediano, VF-IT wrote:
> > >> On Jan 18, 10:22am, sf AT 4js.com (Sebastien FLAESCH) wrote:
> > >> -- Subject: Re: [freetds] ODBC on 64 bit linux fix.
> > >>
> > >> | Thank you Steve,
> > >> | 
> > >> | Here is what we have tested:
> > >> | 
> > >> | CFLAGS="-D BUILD_REAL_64_BIT_MODE" ./configure 
> > >> --prefix=/opt3/dbs/tds/0.83 --with-odbc-nodm=/opt3/dbs/uxo/3.0
> > >> | 
> > >> | But when compiling, we get:
> > >> | 
> > >> | odbc.c:794: conflicting types for `SQLParamOptions'
> > >> | /dbs/64bits/uxo/3.0/include/sqlext.h:1893: previous 
> > >> declaration of `SQLParamOptions'
> > >> | 
> > >> | Am I missing something or is this what Christos tried to fix?
> > >> | 
> > >> | The headers comme from UnixODBC 2.2.12 ...
> > >> | 
> > >> | Cheers,
> > >> | Seb
> > >>
> > >> Yes, this is what I fixed.
> > >>
> > >> christos
> > > 
> > > See 
> http://support.microsoft.com/?scid=kb%3Ben-us%3B298678&x=14&y=7
> > > 
> > > Also from our configure.ac
> > > 
> > >                 # check is SQLParamOptions accept SQLULEN
> > >                 AC_TRY_COMPILE([#if defined(_WIN32) || 
> > defined(WIN32) ||
> > > defined(__MINGW32__)
> > > #include <windows.h>
> > > #endif
> > > #include <sql.h>
> > > #include <sqlext.h>
> > > 
> > > SQLRETURN SQL_API SQLParamOptions(SQLHSTMT       hstmt,
> > >         SQLULEN crow, SQLULEN *pirow) {
> > >         return SQL_SUCCESS;
> > > }], [return 0],
> > >                 AC_DEFINE(TDS_SQLPARAMOPTIONS_SQLLEN, 1, 
> > [Define to 1 if
> > > SQLParamOptions accept SQLULEN as arguments]))
> > >         )
> > > 
> > > but in odbc.c
> > > 
> > > SQLRETURN ODBC_API
> > > SQLParamOptions(SQLHSTMT hstmt, SQLULEN crow, SQLULEN FAR * pirow)
> > > {
> > >         SQLRETURN res;
> > > 
> > > This is a problem in MS specifications... pirow should 
> correspond to
> > > SQL_ATTR_PARAMS_PROCESSED_PTR which is not 64-bit according 
> > which above
> > > link. Also SQL_ATTR_PARAMS_PROCESSED_PTR (see SQLSetStmtAttr
> > > documentation) maps to IPD SQL_DESC_ROWS_PROCESSED_PTR 
> which is not
> > > documented as 64-bit. However SQL_ATTR_ROWS_FETCHED_PTR 
> > which correspond
> > > to IRD SQL_DESC_ROWS_PROCESSED_PTR is documented as 64-bit. So is
> > > SQL_DESC_ROWS_PROCESSED_PTR 32 or 64 bit?? Is it 64-bit 
> > only for IRD??
> > > Does pirow maps really to SQL_ATTR_PARAMS_PROCESSED_PTR 
> > that maps on IPD
> > > SQL_DESC_ROWS_PROCESSED_PTR?
> > > 
> > > Someone have a 64-bit windows machine to execute some 
> > test?? I can pass
> > > some source test in order to test all that stuff... just to 
> > know how MS
> > > implemented its specifications... Is MingW available for 64-bit??
> > > 
> > > freddy77
> > > _______________________________________________
> > > FreeTDS mailing list
> > > FreeTDS AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/freetds
> > > 
> > 
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> > 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 21 Jan 2008 09:35:49 +0100
> From: Sebastien FLAESCH <sf AT 4js.com>
> Subject: Re: [freetds] ODBC on 64 bit linux fix.
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Message-ID: <47945965.5090006 AT 4js.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hello Frediano,
> 
> Yes please send us the binaries, but please give a clear description
> (step by step) to execute the test.
> 
> I known nothing about the regression tests (what is "common.[ch]" or
> the PWD file)?
> 
> Do we have to compile the test?
> 
> Will you provide us only binaries?
> 
> Should we compile the whole HEAD sources on Win64 and run our tests?
> 
> Cheers,
> Seb
> 
> ZIGLIO, Frediano, VF-IT wrote:
> >> We have Windows 64b (with VC++ 8 of course) and Linux 64b 
> >> machines here...
> >>
> >> Send us a test program and we'll check if you want.
> >>
> >> Seb
> >>
> > 
> > I wrote a small test at
> > 
> http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/un
> ittests/te
> > st64.c?view=log. This source is a unittest for freetds so it require
> > common.c and common.h to compile and PWD file to configure.
> > 
> > It works under win32 and linux x86_64 (I used unixODBC and 
> ubuntu 7.10).
> > 
> > Yesterday I managed to get win64 cross compile (thanks to mingw-w64
> > project!). Can I send you compiled freetds for win64 to test?
> > 
> > freddy77
> > 
> >> ZIGLIO, Frediano, VF-IT wrote:
> >>>> On Jan 18, 10:22am, sf AT 4js.com (Sebastien FLAESCH) wrote:
> >>>> -- Subject: Re: [freetds] ODBC on 64 bit linux fix.
> >>>>
> >>>> | Thank you Steve,
> >>>> | 
> >>>> | Here is what we have tested:
> >>>> | 
> >>>> | CFLAGS="-D BUILD_REAL_64_BIT_MODE" ./configure 
> >>>> --prefix=/opt3/dbs/tds/0.83 --with-odbc-nodm=/opt3/dbs/uxo/3.0
> >>>> | 
> >>>> | But when compiling, we get:
> >>>> | 
> >>>> | odbc.c:794: conflicting types for `SQLParamOptions'
> >>>> | /dbs/64bits/uxo/3.0/include/sqlext.h:1893: previous 
> >>>> declaration of `SQLParamOptions'
> >>>> | 
> >>>> | Am I missing something or is this what Christos tried to fix?
> >>>> | 
> >>>> | The headers comme from UnixODBC 2.2.12 ...
> >>>> | 
> >>>> | Cheers,
> >>>> | Seb
> >>>>
> >>>> Yes, this is what I fixed.
> >>>>
> >>>> christos
> >>> See 
> http://support.microsoft.com/?scid=kb%3Ben-us%3B298678&x=14&y=7
> >>>
> >>> Also from our configure.ac
> >>>
> >>>                 # check is SQLParamOptions accept SQLULEN
> >>>                 AC_TRY_COMPILE([#if defined(_WIN32) || 
> >> defined(WIN32) ||
> >>> defined(__MINGW32__)
> >>> #include <windows.h>
> >>> #endif
> >>> #include <sql.h>
> >>> #include <sqlext.h>
> >>>
> >>> SQLRETURN SQL_API SQLParamOptions(SQLHSTMT       hstmt,
> >>>         SQLULEN crow, SQLULEN *pirow) {
> >>>         return SQL_SUCCESS;
> >>> }], [return 0],
> >>>                 AC_DEFINE(TDS_SQLPARAMOPTIONS_SQLLEN, 1, 
> >> [Define to 1 if
> >>> SQLParamOptions accept SQLULEN as arguments]))
> >>>         )
> >>>
> >>> but in odbc.c
> >>>
> >>> SQLRETURN ODBC_API
> >>> SQLParamOptions(SQLHSTMT hstmt, SQLULEN crow, SQLULEN FAR * pirow)
> >>> {
> >>>         SQLRETURN res;
> >>>
> >>> This is a problem in MS specifications... pirow should 
> correspond to
> >>> SQL_ATTR_PARAMS_PROCESSED_PTR which is not 64-bit according 
> >> which above
> >>> link. Also SQL_ATTR_PARAMS_PROCESSED_PTR (see SQLSetStmtAttr
> >>> documentation) maps to IPD SQL_DESC_ROWS_PROCESSED_PTR 
> which is not
> >>> documented as 64-bit. However SQL_ATTR_ROWS_FETCHED_PTR 
> >> which correspond
> >>> to IRD SQL_DESC_ROWS_PROCESSED_PTR is documented as 64-bit. So is
> >>> SQL_DESC_ROWS_PROCESSED_PTR 32 or 64 bit?? Is it 64-bit 
> >> only for IRD??
> >>> Does pirow maps really to SQL_ATTR_PARAMS_PROCESSED_PTR 
> >> that maps on IPD
> >>> SQL_DESC_ROWS_PROCESSED_PTR?
> >>>
> >>> Someone have a 64-bit windows machine to execute some 
> >> test?? I can pass
> >>> some source test in order to test all that stuff... just to 
> >> know how MS
> >>> implemented its specifications... Is MingW available for 64-bit??
> >>>
> >>> freddy77
> >>> _______________________________________________
> >>> FreeTDS mailing list
> >>> FreeTDS AT lists.ibiblio.org
> >>> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>>
> >> _______________________________________________
> >> FreeTDS mailing list
> >> FreeTDS AT lists.ibiblio.org
> >> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> > 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> 
> End of FreeTDS Digest, Vol 60, Issue 31
> ***************************************
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 




------------------------------

_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds


End of FreeTDS Digest, Vol 61, Issue 9
**************************************