Re: Select after insert to the unique column

Поиск
Список
Период
Сортировка
От juleni@livetrade.cz
Тема Re: Select after insert to the unique column
Дата
Msg-id 3223019531.20041213170417@livetrade.cz
обсуждение исходный текст
Ответ на Re: Select after insert to the unique column  ("Frank D. Engel, Jr." <fde101@fjrhome.net>)
Ответы Re: Select after insert to the unique column
Список 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@softhome.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
>>
>>


В списке pgsql-general по дате отправления:

Предыдущее
От: "Frank D. Engel, Jr."
Дата:
Сообщение: Re: relation "sql_features" does not exist
Следующее
От: Bruno Wolff III
Дата:
Сообщение: Re: table with sort_key without gaps