Pippijn,
You are right, ODBCVER is a symbol that gets pulled in from
<sqlext.h>, which isn't included by rtt and is only pulled in when
the C compiler is run on the .c file that rtt writes out. It is interesting
that this has not caused a problem for anyone prior to this, maybe
it is a relatively recent attempt to fix a compiler warning on some
platform. The solution used elsewhere in the sources is to use our
own typedef, so remove the ODBCVER-based #ifdef with
SQL_LENORIND numrows;
I'll take care of this in CVS. SQL_LENDORIND should read
SQL_LENORINT, it is a SQLLEN or SQLINTEGER depending
on the ODBC version.
The csym < 256 question you asked is from the iconc source code,
and I agree that it is weird. It is either an oblique way to refer to the
n_val field of the union, or a possible bug. I'll forward your question
to my iconc developer, who almost certainly did not write this code,
but rather inherited it.
Thanks for the reports.
Cheers,
Clint
On Nov 28, 2007 11:06 AM, Pippijn van Steenhoven <[EMAIL PROTECTED]> wrote:
> the runtime translator doesn't know the macro ODBCVER resulting in
> incorrect compilation of the following code:
>
> #ifdef ISQL
> if ((status & Fs_ODBC) == Fs_ODBC) { /* ODBC file */
> struct ISQLFile *fp;
> int rc;
> #if (ODBCVER >= 0x0351)
> SQLLEN numrows;
> #else /* ODBCVER >= 0x0351 */
> SQLINTEGER numrows;
> #endif /* ODBCVER >= 0x0351 */
> fp = BlkLoc(x)->file.fd.sqlf;
> rc = SQLRowCount(fp->hstmt, &numrows);
> return C_integer(numrows);
> }
> #endif /* ISQL */
>
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
