[ic] Database transaction?

[T. Stoffels]

Just did some testing, it seems to work quite well:

--
Fire: broken del query (sql error)<br>
[tmp mysqlresult_del][query sql=|delete from nonexistanttable where
cats = 7|][/query][/tmp]
Result is '[scratch mysqlresult_del]' |
Result[if type=explicit compare=" $Scratch->{mysqlresult_del} ==0
"]==0[else]!=0[/else][/if] |
Result[if type=explicit compare=" $Scratch->{mysqlresult_del} eq '' "]
eq ''[else] ne ''[/else][/if]<br>

Fire: healthy del query, 0 rows affected<br>
[tmp mysqlresult_del2][query sql=|delete from test where cats =
7|][/query][/tmp]
Result is '[scratch mysqlresult_del2]' |
Result[if type=explicit compare=" $Scratch->{mysqlresult_del2} == 0
"]==0[else]!=0[/else][/if] |
Result[if type=explicit compare=" $Scratch->{mysqlresult_del2} eq ''
"] eq ''[else] ne ''[/else][/if]<br>
--

Outputs:
--
Fire: broken del query (sql error)
Result is '' | Result==0 | Result eq ''
Fire: healthy del query, 0 rows affected
Result is '0' | Result==0 | Result ne ''
--

So it seems as the result is 0 (the number) if the query worked, but
affected no rows
and '' (empty string, nothing) if there was an error.

The only way to distinguish between a 0-rows query and a failed query
is an explicit if with
--
eq ''
--
in it.

I ran some tests and even the transactions thing seems to work
perfectly with commit/rollback. (if I do commit, all changes are in
the db, if I do rollback database is unchanged.)

I agree that it doesn't give you the amount of control a perl-solution
would, but since it's working and there's only 1 page requiring
transcational processing (so no big effort in case I have to chage it
later on) I think I'll stick with it until it blows up right in my
face =)