mikie wrote:
2007/3/1, Martin Marques <martin@xxxxxxxxxxxxxxx>:
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
