freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "James K. Lowden" <jklowden AT schemamania.org>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] RETCODE conflict
- Date: Wed, 30 Mar 2005 09:05:25 -0500
"Frederick N. Brier" <multideck AT comcast.net> wrote:
> Does #undef work on a typedef? I would have thought #undef is a symbol
> in the preprocessor and typedef is a symbol in the compiler's symbol
> table.
You are correct. Freddy's code:
> >#include <sql.h>
> >#define RETCODE DBRETCODE
> >#include <sybdb.h>
> >#undef RETCODE
> >
> >DBRETCODE ret; // dblib return code
> >RETCODE rc; // ODBC return code
effectively replaces all RETCODE references in sybdb.h with DBRETCODE,
allowing the .c file to use DBRETCODE for functions declared in sybdb.h,
and RETCODE for functions declared in sql.h.
> What I am trying to do is call bcp_* routines in the dblib using
> an ODBC connection. The approach is put together a DBPROCESS struct
> from the various TDS structs pointed to by the ODBC based structs since
> both dblib/bcp* functions in the dblib as well as the ODBC library are
> built on the same underlying TDS structs and methods.
Novel, interesting, tricky, and might work. Each library maintains its
own state information, so if you're going to mix ODBC and db-lib functions
on the same connection, you have to be very careful at the application
level to do what the server expects. Be advised that if you make a
protocol error, very often the server's response will be simply to drop
the connection.
That said, as long as you clearly segregate the bcp work from the ODBC
querying, I can't think of any reason it wouldn't work, or couldn't be
made to.
--jkl
-
[freetds] RETCODE conflict,
Frederick N. Brier, 03/29/2005
- <Possible follow-up(s)>
-
RE: [freetds] RETCODE conflict,
ZIGLIO, Frediano, VF-IT, 03/30/2005
- Re: [freetds] RETCODE conflict, Brian Bruns, 03/30/2005
-
Re: [freetds] RETCODE conflict,
Frederick N. Brier, 03/30/2005
- Re: [freetds] RETCODE conflict, James K. Lowden, 03/30/2005
Archive powered by MHonArc 2.6.24.