Closed GitMensch closed 2 years ago
In some of these cases (notably not the one above) the error does not originate in the driver/DBMS (which is never hit) but by some logic/consistency issue. For instance: https://github.com/mridoni/gixsql/blob/081674b3c03e1b97b0a2edf854a152d765331bee/runtime/libgixsql/gixsql.cpp#L907-L911
The logic is (bugs like in your case aside) that if dbi
is NULL, we do not try to retrieve an error code/message from the DB driver, because it would be useless, we just build one from the supplied error code (e.g. DBERR_EMPTY_QUERY
). Unfortunately, in many of these cases SQLERRM
is simply not set.
I totally agree - this has likely to be checked for each invocation - and possibly a comment be left in the code that explains the logic (more or less copy+paste +delete from your comment above).
Another place to definitely pass dbi
: in line 960 - error for prepare (actually any place that uses DBERR_SQL_ERRROR
.
Another place to definitely pass
dbi
: in line 960 - error for prepare (actually any place that usesDBERR_SQL_ERRROR
.
Noted (and done). Also: SQLERRM
- in my internal repository - should now be correctly set for "internal" error codes (those emitted without a corresponding error from the DBMS/driver), I want make another "pass" to be sure that all error messages are covered.
seems to be fine in 1.0.18dev2
I've recognized this in
GIXSQLExecSelectIntoOne
https://github.com/mridoni/gixsql/blob/081674b3c03e1b97b0a2edf854a152d765331bee/runtime/libgixsql/gixsql.cpp#L943 but there are lots of other calls ofsetStatus
that passNULL
- even with a validdbi
available - and in many other cases I do wonder if it shouldn't be requested from the validconn
we often have.Because of this missing call the return is not:
but
Because of performance reasons (not sure if this makes an actual difference) you may consider that for a bunch of known return status (like the 02000 above) you directly set SQLERRM to 0+space, but that's your's to consider :-)