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 <[EMAIL PROTECTED]> 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
>>
>>
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
