Thread: SQLParamOptions(): Incorrect base for returned row.

SQLParamOptions(): Incorrect base for returned row.

From
Barry Cohen
Date:
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

Re: SQLParamOptions(): Incorrect base for returned row.

From
Hiroshi Inoue
Date:
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/

Re: SQLParamOptions(): Incorrect base for returned row.

From
Hiroshi Inoue
Date:
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/

Re: SQLParamOptions(): Incorrect base for returned row.

From
Barry Cohen
Date:
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/

Re: SQLParamOptions(): Incorrect base for returned row.

From
Barry Cohen
Date:
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/

...

From
Simeó Reig
Date:
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!