Re: Does the recommendation against variable names starting with SQL apply to constants?

Y'all

IBM have some constants for CLI in a C/C++ include member, QSYSINC/H(SQLCLI). In there are these for SQLCODE -

/* RETCODE values */
#define SQL_SUCCESS 0
#define SQL_SUCCESS_WITH_INFO 1
#define SQL_NO_DATA_FOUND 100
#define SQL_NEED_DATA 99
#define SQL_NO_DATA SQL_NO_DATA_FOUND
#define SQL_ERROR -1
#define SQL_INVALID_HANDLE -2

There is no similar copy member for RPGLE - well, there is on, but it is very limited. All it has is 3 structures for date, time, and timestamp, using B data type for each component - not sure what use they are, but that's it.

I've made my own copy member that has all the stuff in the C version, modified for RPGLE. I think I used the same names. No problem there, since they are really IBM's names, seems to me.

These do seem to fit David's suggestions a la Charles' conventions more.

The effort to make an RPGLE version of the entire C include is not trivial, and it changes at various releases as more is supported. Still, it might be worth it - or else write all your CLI in C - not a bad option.

Vern

On 9/1/2010 3:09 AM, David FOXWELL wrote:

-----Message d'origine-----
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Schutte,
Michael D.
You know what they say about assuming? You could just change
the naming.

SUCCESSFUL_SQL_STATE
NO_DATA_SQL_STATE
NO_MORE_RS_SQL_STATE

I've been a follower of Charles' naming techniques for a while now. I don't think he'd like those names.

Maybe :
STATE_SQL_SUCCESSFUL
STATE_SQL_NO_DATA
STATE_SQL_NO_MORE_RS

would be more his style. Although I'm not sure why SQL and STATE need to be included in the constant names.

Presumably, they would be used like : if SQLSTATE = SQL_STATE_SUCCESS

Why not

RS_NOT_FOUND
RS_FOUND
RS_END_OF_FILE

etc.