Alle 15:02, giovedì 23 ottobre 2003, Lukas Smith ha scritto:
. run query 1
. check if q1 worked
. run query 2
. check if q2 worked
. if q1 worked -> fetch data...and so on.
Perhaps I'm missing something, but I can't see a real issue here.
Yeah, you are missing something :-/
[...]
The other alternative would be to remember the last error and check
if that error is the same every time you check and all such solutions
are possible but very hacky of course.
Well, I didn't miss anything :)
What you call hacky is the way I usually work: do something, check if
there was an error; if so, collect the error, else (or then) go on.
I don't want to be polemical, only I can't see anything wrong (if you
need the mysql_error()) in doing something like:
. run query 1
. check if q1 worked
. if not -> q1_error = mysql_error()
. run query 2
. check if q2 worked
. if not -> q2_error = mysql_error()
. if q1 worked -> fetch data
It's obvious that I am no-one in the php decisional process ;)
I think that your proposal would be more elegant than the way things are
now; it would be also better, if it didn't break bc with ways of
programming that are commonly in use.
Again: no polemical spirit :)
Ciao
ce
Cesare D'Amico - http://www.phpday.it
"Eun'emergenza!!! Dovrei fare questo-e-questaltro ma non posso perche' la mia testa e piena di segatura e criceti!!!"
-- un utente [ http://www.soft-land.org/storie/ ]
From: Cesare D'Amico [mailto:cesare@ngi.it]
Sent: Thursday, October 23, 2003 3:27 PMAlle 15:02, giovedì 23 ottobre 2003, Lukas Smith ha scritto:
. run query 1
. check if q1 worked
. run query 2
. check if q2 worked
. if q1 worked -> fetch data...and so on.
Perhaps I'm missing something, but I can't see a real issue here.
Yeah, you are missing something :-/
[...]
The other alternative would be to remember the last error and check
if that error is the same every time you check and all such solutions
are possible but very hacky of course.Well, I didn't miss anything :)
What you call hacky is the way I usually work: do something, check if
there was an error; if so, collect the error, else (or then) go on.
Well errors are not always fatal .. and if they are not then it should be
possible to proceed without any further "harm" to your script.
For example in the sequence emulation in PEAR::DB you can optionally created
sequences on demand. This is done if the query to select the next value
failed with an error specifying that sequence does not exist. We currently
just trap that error and if the user wants we create the sequence for him
and everything should proceed as usual. However this doesnt work if we also
check for errors during fetching (unless we know the end of the result set
.. which you obviously could do with a counter and a call to
mysql_num_rows() unless of course you are doing an unuffered query). So
anyways the current situation is very messy. A fix to atleast let us do the
error checking would be to have a mysql_clear_error() or something like
that.
Anyways nuff said about this issue. :-)
Regards,
Lukas