mikie wrote:
> 2007/3/1, Martin Marques <martin@bugs.unl.edu.ar>:
>
>> mikie wrote:
>> >> > But getting back to my problem - perhaps there is something I
>> >> > misunderstood: is it the client application responsibility to
>> check if
>> >> > the transaction failed or succeeded and issue COMMIT or ROLLBACK
>> >> > accordingly (how do I close the transaction block in that case)?
>> >> > Or is it the database server that is suppose to check if transaction
>> >> > succeded and perform the query, or ROLLBACK if anything went wrong?
>> >>
>> >> PG will rollback all transactions that have an error in some part,
>> as it
>> >> can't commit the transaction as a whole.
>> >
>> > OK, so my way of programming seems correct.
>> > Then why do I have to send another COMMIT after failed transaction to
>> > continue with next queries in the same php script ?
>>
>> I may not have gotten your question right, but with one commit (or end)
>> is enough. Transaction gets closed (commited or rolled back), and you
>> can start a new transaction with BEGIN.
>
>
> Thats exactly what I was thinking, too. But PHP does things in some
> other way, I guess.
> I am sending an entire sql transaction block to the PHP pg_query
> command, so it starts with BEGIN and ends with COMMIT. Then I still
> have to execute another pg_query with "commit;" only - thats why I am
> asking here if maybe someone know what the problem is.
Try executing the query without the last commit, and afterwords execute
another query with commit.
I personaly don't like to mix diferent querys and comands in one
pg_query() line. Also, I am more bound to using things like MDB2 or PDO,
which makes life easier.
BTW, if you have log_statments = 'all', could you see those logs to
check if the commits are really getting to the server?
Martín