Here are the results of my grep, hopefully this helps:
# ls
ANNOUNCE Makefile Solid.bs Solid.pm dbdimp.c
pm_to_blib
Changes Makefile.PL Solid.c Solid.xs dbdimp.h t
Const README Solid.h bench dbdimp.o
MANIFEST README.longs Solid.o blib make.out
# grep -i SQL_SUCCESS *
Changes: like SQL_NO_DATA_FOUND and SQL_SUCCESS_WITH_INFO only
dbdimp.c: if ( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: /* error code 00000 also means SQL_SUCCESS, according
dbdimp.c: if (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO)
dbdimp.c: } while (rc == SQL_SUCCESS || rc ==
SQL_SUCCESS_WITH_INFO);
dbdimp.c: if (badrc != SQL_SUCCESS && what)
dbdimp.c: if (badrc != SQL_SUCCESS)
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: i < imp_sth->n_result_cols && rc == SQL_SUCCESS;
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: imp_sth->eod = SQL_SUCCESS;
dbdimp.c: if( rc == SQL_SUCCESS_WITH_INFO )
dbdimp.c: /* with par: is always OK, *par gets SQL_SUCCESS */
dbdimp.c: *(RETCODE*)par = SQL_SUCCESS;
dbdimp.c: case SQL_SUCCESS:
dbdimp.c: case SQL_SUCCESS_WITH_INFO:
dbdimp.c: imp_sth->eod = SQL_SUCCESS;
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc == SQL_SUCCESS_WITH_INFO )
dbdimp.c: if( rc != SQL_SUCCESS )
dbdimp.c: if( rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO )
dbdimp.c: if( rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO )
dbdimp.c: if( rc != SQL_SUCCESS )
#
# grep SQL_SUCCESS *
Const.c: if (strEQ(name, "SQL_SUCCESS"))
Const.c:#ifdef SQL_SUCCESS
Const.c: return SQL_SUCCESS;
Const.c: if (strEQ(name, "SQL_SUCCESS_WITH_INFO"))
Const.c:#ifdef SQL_SUCCESS_WITH_INFO
Const.c: return SQL_SUCCESS_WITH_INFO;
Const.pm: SQL_SUCCESS
Const.pm: SQL_SUCCESS_WITH_INFO
Const.xs: if (strEQ(name, "SQL_SUCCESS"))
Const.xs:#ifdef SQL_SUCCESS
Const.xs: return SQL_SUCCESS;
Const.xs: if (strEQ(name, "SQL_SUCCESS_WITH_INFO"))
Const.xs:#ifdef SQL_SUCCESS_WITH_INFO
Const.xs: return SQL_SUCCESS_WITH_IN
Jim Cromie
<[EMAIL PROTECTED]
om> To
[EMAIL PROTECTED]
11/12/2003 04:19 cc
PM
Subject
[Fwd: Re: Compile of DBD Solid]
Patty,
Tim Bunce (the author of DBI) has asked a question that youre
in a position to answer, as you have the source code. See below for his
words.
please grep for SQL_SUCCESS in the Solid source-code and post an
excerpt/summary.
I infer that it should be used to conditionally define the rest of the
constants,
ala:
#ifndef SQL_SUCCESS
#define SQL_VARCHAR ....
....
#endif
but its possible that it is just unconditionally defined along with the
others
This could cause probs;
if its included *after* DBI/sql_types.h, which (properly, I infer) does
a conditional test on SQL_SUCCESS before defining the SQL_* constants
but which doesnt encounter the defined symbol
and if (as i believe) inclusion order matters, and is controlled from
command-line options -L
The warning messages seems to corroborate this reading, but im not 100%
sure im
interpreting it right, and I dont have the inclination at this point to
construct a test.
thanks (in advance) for following up.
jimc
-------- Original Message --------
Subject: Re: Compile of DBD Solid
Date: Tue, 11 Nov 2003 20:57:27 +0000
From: Tim Bunce <[EMAIL PROTECTED]>
To: Jim Cromie <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
On Tue, Nov 11, 2003 at 11:53:00AM -0700, Jim Cromie wrote:
> [EMAIL PROTECTED] wrote:
>
> >Here is the error I am getting when I run the make:
> >
> ># make .....
> >
> >In file included from Solid.h:57,
> > from Solid.xs:7:
> >/usr/solid/include/sqlext.h:398: warning: `SQL_INTERVAL_YEAR' redefined
> >/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBI/dbi_sql.h:58:
> >warning: this is the location of the previous definition
> >
>
> DBI/dbi_sql.h defines constants for sql data-types.
> apparently so does /usr/solid/include/sqlext.h
>
> but these are warnings, ok as long as the defined values are consistent.
>
> Q to list - is there a risk in adding #ifndef SQL_VARCHAR 'ing around
> the SQL datatype codes ?
> or is SQL_SUCCESS the standard way of doing this - and Solid not
> following the ODBC standard ?
Does Solid not define SQL_SUCCESS?
Certainly the DBI code could use defined(SQL_VARCHAR) ||
defined(SQL_SUCCESS)
to disable the defines. Or it could even add #ifdef's around each #define.
Any volunteers to send a patch?
Tim.
