Skip site navigation (1) Skip section navigation (2)

Handling from UPDATE, SELECT, ... with now rows affected

From: RSchiele(at)FIDUCIA(dot)de
To: " - *pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Cc: " - *nick(at)easysoft(dot)com" <nick(at)easysoft(dot)com>
Subject: Handling from UPDATE, SELECT, ... with now rows affected
Date: 2000-09-01 12:01:34
Message-ID: 0057540006618721000002L412*@MHS (view raw or flat)
Lists: pgsql-bugs
Hello PostgreSQL-Team,

sorry that i'm not using the standard bug report, but I think i have not a bug.

I'm using the unixODBC with PostgreSQL and I have a little problems discussed
with nick the
maintainer from unixODBC. And for now we are stuck. So what is the problem. I
hope i can get it
on the point.

Looking in the PostgreSQL  C-API  to the ExecStatusType there is no Retcode for

"I process the command or query but not a single row is returned or touched"

for long: for example using an UPDATE-Statment that does not touch any row, I
does not
get this info. Sure i can get before an UPDATE count(*) .... but this is ugly
and wrong. The same
is for an SELECT-Statment, I can handle this with looking in the RowCount, but
I get a problem using
SELECT MIN(...) (look at the end).

So now the question/suggestion: Is it possible to get the backend get the
information back to the client
if a row is touched/queried in the ExecStatusType for Example:

Hope to hear from you


*An: nick
Von: Rainer Schiele
BTB/Tel: SYTKIV  / 0721/4004-1843
Datum: 01.09.2000 12.58.36
*Thema: unixODBC - SQLFetch RC

Hello Nick,

i think i have discovered a mismatch in the Handling of SQLFetch. We have had a
similary Problem (but not the same, I put it on the end: Problem1).

OK, let's start:

Linux 2.2.14, PostgreSQL 7.0.2, unixODBC-1.8.12

For example when I use and SQL-Statement like

SELECT Number FROM TEDAV003 WHERE id = 1000

and the Row with id = 1000 does not exists i get an SQL_NO_DATA_FOUND from
This seems OK.

But using the statment:

SELECT MIN(Number) FROM TEDAV003 WHERE id = 1000

SQLFetch return SQL_SUCCESS (Wrong) and the Binded Cols where not been touched

I think the problem is using the Row Count from the Select-Results which is 1,
but this does not mean we found data !!!


PS: Had you time to look in my Threading-Problem. I have get a deep breath and
going in your code
(..\Drivers\ProstgreSQL\statement.c line 770) where you decide to start a
transaction or not. And I did
not seen a synchronization there. Will that be synchronized in the upper layers

Problem 1

I have a problem with SQL-Updates and the Retcode from SQLExecDirect.

I think i make something wrong because the problem is so trivial that this can
not be a bug!

Let's start:

I have a very simple Routine that makes an update in the Database:

int DBProduktForTargInsert(DBHandle    *dbHandle,
                           short       prodNr,
                           int         targNr,
                           int         jobNr,
                           char        *userId,
                           DBErrInfo   *errInfo) {

    SQLRETURN  sqlrc;

    sprintf(stmt, StmtProduktForTargInsert1,
            prodNr, targNr, jobNr, userId,
            prodNr, targNr);

    sqlrc = SQLExecDirect(dbHandle->hstmt, stmt, SQL_NTS);
    fprintf(stderr, "sqlrc: %d\n", sqlrc);
    if (sqlrc != SQL_SUCCESS) {
        DBFillErrInfo(dbHandle, errInfo);
        return sqlrc;

    return sqlrc;

The SQL-Statement that is going to the Database is:

SET  prod_nr = 1,
 targ_nr = 2,
 job_nr  = 3,
 upd_uid = 'UserID',
 upd_date = CURRENT_DATE,
 upd_time = CURRENT_TIME
WHERE prod_nr = 1 AND targ_nr = 2

Seems quite right!

In the table there are no entries !! This is OK!

BUT the sqlrc is SQL_SUCCESS (0) not SQL_NO_DATA_FOUND (100).

My Dokumentation (IBM DB2/2) says for a Searched Update with no rows satisfy
the serach condition SQL_NO_DATA_FOUND must be returned!!!!!!

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2000-09-01 15:51:39
Subject: min and max function in time data type columns
Previous:From: pgsql-bugsDate: 2000-08-31 23:56:53
Subject: Responses to bugs should appear publically with bug reports

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group