X-Original-To: pgsql-interfaces@postgresql.org Received: from localhost (developer.postgresql.org [64.117.224.193]) by developer.postgresql.org (Postfix) with ESMTP id E4582926272 for ; Mon, 2 Jun 2003 12:08:42 -0400 (EDT) Received: from developer.postgresql.org ([64.117.224.193]) by localhost (developer.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 17161-01 for ; Mon, 2 Jun 2003 12:08:32 -0400 (EDT) Received: from candle.pha.pa.us (momjian.navpoint.com [207.106.42.251]) by developer.postgresql.org (Postfix) with ESMTP id 1E22292605C for ; Mon, 2 Jun 2003 12:08:31 -0400 (EDT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id h52G8Mm07571; Mon, 2 Jun 2003 12:08:22 -0400 (EDT) From: Bruce Momjian Message-Id: <200306021608.h52G8Mm07571@candle.pha.pa.us> Subject: Re: Bug in ODBC driver doing UPDATES and DELETES In-Reply-To: To: Tim Woodall Date: Mon, 2 Jun 2003 12:08:22 -0400 (EDT) Cc: pgsql-interfaces@postgresql.org X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Archive-Number: 200306/15 X-Sequence-Number: 4226 Got it and will apply shortly. Thanks. --------------------------------------------------------------------------- Tim Woodall wrote: > When doing an UPDATE or DELETE via ODBC, if no records are affected then > SQLExecute should return SQL_NO_DATA_FOUND and not SQL_SUCCESS. > > The following patch fixes this problem. > > Regards, > > Tim. > > diff -ur postgresql-7.1.3/src/interfaces/odbc/statement.c postgresql-7.1.3-patched/src/interfaces/odbc/statement.c > --- postgresql-7.1.3/src/interfaces/odbc/statement.c Mon Apr 23 02:00:49 2001 > +++ postgresql-7.1.3-patched/src/interfaces/odbc/statement.c Thu May 15 16:30:46 2003 > @@ -864,6 +864,13 @@ > Int2 oldstatus, > numcols; > QueryInfo qi; > + char was_rows_affected = 1; > + /* was_rows_affected is set to 0 iff an UPDATE or DELETE affects > + * no rows. In this instance the driver should return > + * SQL_NO_DATA_FOUND and not SQL_SUCCESS. > + * I'm not sure about the use of char rather than int but this is > + * consistent with the other was_* variables above. > + */ > > > conn = SC_get_conn(self); > @@ -998,6 +1005,13 @@ > > was_ok = QR_command_successful(self->result); > was_nonfatal = QR_command_nonfatal(self->result); > + if(self->result->command && > + (strncmp(self->result->command, "UPDATE", 6) == 0 || > + strncmp(self->result->command, "DELETE", 6) == 0) && > + strtoul(self->result->command + 7, NULL, 0) == 0) > + { > + was_rows_affected = 0; > + } > > if (was_ok) > self->errornumber = STMT_OK; > @@ -1055,7 +1069,10 @@ > } > > if (self->errornumber == STMT_OK) > - return SQL_SUCCESS; > + if(was_rows_affected) > + return SQL_SUCCESS; > + else > + return SQL_NO_DATA_FOUND; > > else > { > > -- > God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," > and there was light. > > http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073