Re: Select after insert to the unique column

From: juleni(at)livetrade(dot)cz
To: "Frank D(dot) Engel, Jr(dot)" <fde101(at)fjrhome(dot)net>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>, Juleni <julo(at)opensubsystems(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Select after insert to the unique column
Date: 2004-12-13 16:04:17
Message-ID: 3223019531.20041213170417@livetrade.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thank you for your answer. I think it's very interesting behaviour. Is
it a feature or bug ?

I have try this my jUnit test for another DB systems (e.g. Oracle 9i,
MS SQL Server 2000, MySQL, DB2, Sybase, SAP DB) and it works for each of
these databases (it was possible tu run next command successfully after
an exception occured before).

With baset regards,

Julian Legeny


Monday, December 13, 2004, 4:26:24 PM, you wrote:

FDEJ> If you attempted the inserts within a single transaction and any of
FDEJ> them fail, they will all fail. The server will automatically undo any
FDEJ> and all changes made by the transaction, and any further steps in the
FDEJ> transaction will simply result in the error message you are getting.
FDEJ> You will not be able to (successfully) issue any further database
FDEJ> commands until you end the transaction and start a new one.

FDEJ> On Dec 11, 2004, at 2:29 PM, Bruno Wolff III wrote:

>> On Wed, Dec 08, 2004 at 14:50:04 +0100,
>> Julian Legeny <legeny(at)softhome(dot)net> wrote:
>>> Hello,
>>>
>>> Then I want to process command
>>> select count(*) from UNIQUE_COLUMN_TEST
>>> that I want to know how many records was already inserted before id
>>> faied.
>>>
>>> But when I try to process that SELECT COUNT(*), there is error
>>> occured again:
>>>
>>> org.postgresql.util.PSQLException:
>>> ERROR: current transaction is aborted, commands ignored until end
>>> of transaction block
>>>
>>> How can I solve this?
>>
>> Depending on what you really want to do, you could do each insert in
>> its
>> own transaction.
>>
>> If you don't want any of the inserts to succeed if there are problems,
>> then
>> you should do the counting in the application doing the inserts.
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>>
>>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Hans-Michael Stahl 2004-12-13 16:36:16 "Complex" data types like BYTEA in embedded SQL with ecpg
Previous Message Frank D. Engel, Jr. 2004-12-13 15:55:26 Re: relation "sql_features" does not exist