Skip to Content.
Sympa Menu

freetds - Re: [freetds] parameters missing in RC 64 Bits

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Igor Chudov <igor AT chudov.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] parameters missing in RC 64 Bits
  • Date: Sun, 20 Apr 2008 17:29:07 -0500


On Sun, Apr 20, 2008 at 02:24:18PM -0400, James K. Lowden wrote:
> Federico Alves wrote:
> > I have a perl script that I use to test my application, and executes a
> > stored procedure against SQL 2005, with "OUTPUT" parameters. It works
> > fine in 32 bits but fails to return any parameters in 64 Bits.
>
> Igor Chudov wrote:
> >
> > col_types array ref, which used to work and contained valid type
> > numbers, no longer works on 64 bit ubuntu Hardy. Instead of valid
> > types, it contains a bunch of zeroes (as many as columns).
>
> Gentlemen,
>
> Your questions are too high-level for me to answer without a great deal of
> work. I don't have a 64-bit environment to test on, and don't even know
> what function, if any, is alleged to fail.

Whatever I can do to help you, I will.

I actually have some understanding of the issue.

Ubuntu Hardy uses a different odbc.h where some types have been
redefined for 64 bit.

I had to make some changes to make our odbc C++ code (no relation to
the particular problem I came here with) compile under 64 bit ubuntu.

That c++ code uses freetds-devel package.

These odbc.h changes come from Debian.

Anyway. I can give you a user account on a 64 bit Ubuntu Hardy
computer. (no root). I also do not have a MSSQL server, so you would
need to use your own over the internet. But I will be delighted to
give you an account and install whatever packages you want.

> Do all src/ctlib/unittests work? Many of them rely on column metadata,
> and rpc_ct_param.c tests output parameters. If they pass, we at least can
> say ct-lib works as expected. Not right, necessasrily, but as expected.
>
> Problems like this are always a matter of the function behaving as the
> caller expects. You need to narrow down who the caller is and what it
> expects (and whether that's the right expectation). Then we can see if
> how the function behaves, and what needs to be changed.

I will give this a try, what do I need to download and compile?

i




Archive powered by MHonArc 2.6.24.

Top of Page