Thread: SQLParamOptions(): Incorrect base for returned row.
Server: PostgreSQL Server on Linux (as bundled with RedHat 7.3) Client: Windows Insight Distribution Systems driver 7.02.00.03 Hello, When performing a block insert, SQLParamOptions() can be used to return the index of the last row processed. According to the MSDN documentation, the index should be one based. MSDN: "As a statement executes, the driver sets pirow to the number of the current row of parameter values; the first row is row number 1. The contents of pirow can be used as follows: ..." The PostgreSQL driver seems to be returning an index that is zero based. Thanks in advance for any info. Regards, bjc
Barry Cohen wrote:
>
> Server: PostgreSQL Server on Linux (as bundled with RedHat 7.3)
> Client: Windows Insight Distribution Systems driver 7.02.00.03
>
> Hello,
>
> When performing a block insert, SQLParamOptions() can be used
> to return the index of the last row processed. According to
> the MSDN documentation, the index should be one based.
>
> MSDN: "As a statement executes, the driver sets pirow to the
> number of the current row of parameter values; the first row
> is row number 1. The contents of pirow can be used as follows: ..."
>
> The PostgreSQL driver seems to be returning an index that is zero based.
Is this only for error cases ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Barry Cohen wrote: > > Yes. The index problem seems to only occur during an error case. > > If all rows are successfully inserted, then 'pirow' equals 'crow', > which is correct. > > The index problem occurs for error encountered during block inserts, > deletes, and updates. Please try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/
Yes. The index problem seems to only occur during an error case.
If all rows are successfully inserted, then 'pirow' equals 'crow', which is
correct.
The index problem occurs for error encountered during block inserts,
deletes, and updates.
Regards,
bjc
-----Original Message-----
From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
Sent: Sunday, October 27, 2002 9:57 PM
To: Barry Cohen
Cc: 'pgsql-odbc@postgresql.org'
Subject: Re: [ODBC] SQLParamOptions(): Incorrect base for returned row.
Barry Cohen wrote:
>
> Server: PostgreSQL Server on Linux (as bundled with RedHat 7.3)
> Client: Windows Insight Distribution Systems driver 7.02.00.03
>
> Hello,
>
> When performing a block insert, SQLParamOptions() can be used
> to return the index of the last row processed. According to
> the MSDN documentation, the index should be one based.
>
> MSDN: "As a statement executes, the driver sets pirow to the
> number of the current row of parameter values; the first row
> is row number 1. The contents of pirow can be used as follows: ..."
>
> The PostgreSQL driver seems to be returning an index that is zero based.
Is this only for error cases ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Yes. This seems to resolve the problem. -----Original Message----- From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp] Sent: Tuesday, October 29, 2002 4:43 AM To: Barry Cohen Cc: 'pgsql-odbc@postgresql.org' Subject: Re: [ODBC] SQLParamOptions(): Incorrect base for returned row. Barry Cohen wrote: > > Yes. The index problem seems to only occur during an error case. > > If all rows are successfully inserted, then 'pirow' equals 'crow', > which is correct. > > The index problem occurs for error encountered during block inserts, > deletes, and updates. Please try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/
Hi My scenario : Freebsd 4.5, postgrsql 7.1.3 , 70 concurrent users via ODBC Now ADO seems that it don't see any error like 'permission denied', it rest the answer indefinitely . Last week I've been optimizing postgresql but I believe it's not the problem because Access see the error, but our program is the same . Any idea please ? Thanks a lot!