FreeTDS Development Group

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

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/SUNWspro/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/unittests/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/unittests/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
***************************************