> From: Cesare D'Amico [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 23, 2003 3:27 PM > > 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.
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 doesn’t 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
