Gregory Stark <[EMAIL PROTECTED]> writes:
> "Pit M." <[EMAIL PROTECTED]> writes:
>> The goal is to maintain a valid cursor that can be used to FETCH other
>> records.
>> It would be ideal to skip this record an continue fetching the next record ->
>> but how can i achieve this?
> Well ideally the
"Pit M." <[EMAIL PROTECTED]> writes:
> The goal is to maintain a valid cursor that can be used to FETCH other
> records.
> It would be ideal to skip this record an continue fetching the next record ->
> but how can i achieve this?
Well ideally the answer would be to wrap each FETCH in a savepoi
On Mon, Jun 11, 2007 at 03:28:22PM +0200, Pit M. wrote:
We handle exceptions errors through libpq, and if a FETCH leads to such
a runtime error, we try to FETCH the first record again.
The problem is that we can't use this cursor any more -> it seems to be
corrupt after that error.
An aborte
On Mon, Jun 11, 2007 at 03:28:22PM +0200, Pit M. wrote:
> We handle exceptions errors through libpq, and if a FETCH leads to such
> a runtime error, we try to FETCH the first record again.
> The problem is that we can't use this cursor any more -> it seems to be
> corrupt after that error.
An ab
Thank you Pavel!
The problem is, that the CAST function may be used in any SQL query,
since our software allows using a free SQL-query. The query itself
doesn't fail, because the syntax is correct.
The problem is that there may be other functions in a query that can
lead to a runtime error dur
Unfortunately this is not possible, because this should happen on the
client. The client calls FETCH for every record available in that cursor
when the user (application) wants to display the data (scrollable
list of records)
So do you think i should wrap each FETCH statement?
We handle excep
Yes i know that i can't, but why the transaction fails?
because casting fails. First FETCH was ok, and evaluating of next row
(which need second FETCH) was broken. When any statement in
transaction fail, you have to rollback current transaction.
Pavel
---(end of broa
I didn't try myself, but wrapping the whole into a PL/pgSQL function and
using exceptions might do the work;
http://www.postgresql.org/docs/8.2/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
Ciao,
Thomas
Unfortunately this is not possible, because this should happen on the
cl
Pavel Stehule schrieb:
Hello
I thing so problem is there
AND Cast("CUSTOMERS"."ZIP" as integer) < 2
You cannot cast 'A1234' to integer
Regards
Pavel Stehule
Yes i know that i can't, but why the transaction fails?
Pit
---(end of broadcast)
I didn't try myself, but wrapping the whole into a PL/pgSQL function and
using exceptions might do the work;
It's not good advice. I tested it, and problem is in where clause. I
don't understand problem well, but one possibility is change from cast
to to_number function like:
postgres=# begi
Hi,
On Monday 11 June 2007 13:45, Pit M. wrote:
| Assume a user doing a query which shall select all customers having a
| ZIP in [1;2[ by using a CAST. If the cursor now fetches the row
| with ID 4 we get an error (invalid input syntax) as "A1234" cannot be
| casted as integer. This is ok,
Hello
I thing so problem is there
AND Cast("CUSTOMERS"."ZIP" as integer) < 2
You cannot cast 'A1234' to integer
Regards
Pavel Stehule
2007/6/11, Pit M. <[EMAIL PROTECTED]>:
We use PG 8.2.4 with as cursors over libpq and get an error:
ERROR: current transaction is ab
We use PG 8.2.4 with as cursors over libpq and get an error:
ERROR: current transaction is aborted, commands ignored until end of
transaction block
How can we avoid this error or make the cursor still working afterwards?
Assume following contents of table CUSTOMERS:
ID | ZIP (varchar
13 matches
Mail list logo
