t: Wednesday, October 22, 2003 7:18 PM
> > To: Lukas Smith; 'PHP Development'
> > Subject: Re: [PHP-DEV] database driver: no more
> rows
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > I wouldn't mind such a change myself,
At 03:02 PM 10/23/2003 +0200, Lukas Smith wrote:
mysql_error() will return you the last error over and over again.
Shouldn't the mysql extension clear the last error on a successful query?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
> While I think about it: There would be one solution that wouldn't break
BC:
> adding a function that would clear the last error. Then you could manually
> clear an error after you have read it.
I could see that mysql_reset_error() would be useful. + 1!
Regards,
Manuzhai
--
PHP Internals - PH
> 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
> > >
> > >
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 missi
> From: Cesare D'Amico [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 23, 2003 2:59 PM
> Alle 00:18, giovedì 23 ottobre 2003, Lukas Smith ha scritto:
> > run query that works
> > run query that doesn't
> >
> > now when you fetch the rows of the first query you will usually
> > determine if yo
Alle 00:18, giovedì 23 ottobre 2003, Lukas Smith ha scritto:
> run query that works
> run query that doesn't
>
> now when you fetch the rows of the first query you will usually
> determine if you hit the end if the result set by checking if you
> don't get an array returned
>
> if you don't get an
On Wed, 22 Oct 2003, Ard Biesheuvel wrote:
> > Err .. I don't agree.
> > Null means no data
> > False means error.
>
> Maybe historically (PHP-wise) it does.
> But the way I see it, every fetch() can 'fail' for two reasons: an
> expected well-defined reason (eof), and an unexpected undefined rea
On Wed, 22 Oct 2003, Lukas Smith wrote:
> > I wouldn't mind such a change myself, however what about all the
> > installations
> > where people do while (*fetch_row() !== false) ?
>
> Yeah ... php5 would be a good time to make this change.
Not really, this is just too much of a BC break to me.
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 23, 2003 12:06 AM
> >I don't think I've had any experince with those functions returning FALSE
> >for me, but I think it's more logical that they differentiate between the
> >FALSE and the NULL for the reasons stated above.
At 06:04 PM 10/22/2003 -0400, [EMAIL PROTECTED] wrote:
Well, this would be my first time contributing to any discussion on this
list since I joined, but I have a question.
It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so
much different than PHP 4 that scripts would have to
In a message dated 10/22/2003 6:00:11 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
>>Err .. I don't agree.
>>Null means no data
>>False means error.
>
>Maybe historically (PHP-wise) it does.
>But the way I see it, every fetch() can 'fail'
At 12:00 AM 10/23/2003 +0200, Lukas Smith wrote:
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2003 11:58 PM
> At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
> >>Err .. I don't agree.
> >>Null means no data
> >>False means error.
> >
> >Maybe historically (PHP-w
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2003 11:58 PM
> At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
> >>Err .. I don't agree.
> >>Null means no data
> >>False means error.
> >
> >Maybe historically (PHP-wise) it does.
> >But the way I see it, every fe
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
Err .. I don't agree.
Null means no data
False means error.
Maybe historically (PHP-wise) it does.
But the way I see it, every fetch() can 'fail' for two reasons: an
expected well-defined reason (eof), and an unexpected undefined reason
(error).
Err .. I don't agree.
Null means no data
False means error.
Maybe historically (PHP-wise) it does.
But the way I see it, every fetch() can 'fail' for two reasons: an
expected well-defined reason (eof), and an unexpected undefined reason
(error). Labelling the well-defined reason as 'false' and th
> From: Ard Biesheuvel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2003 7:56 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] database driver: no more rows
>
> >>I wouldn't mind such a change myself, however what about all the
> >>i
I wouldn't mind such a change myself, however what about all the
installations
where people do while (*fetch_row() !== false) ?
Wouldn't it be a lot easier to do it the other way around ?
I mean, the semantics of returning false when a fetch cannot be executed
because aren't any rows left is perfec
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2003 7:18 PM
> To: Lukas Smith; 'PHP Development'
> Subject: Re: [PHP-DEV] database driver: no more rows
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I wouldn'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wouldn't mind such a change myself, however what about all the installations
where people do while (*fetch_row() !== false) ?
Ilia
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/lrviLKekh381/CERAigRAJ0fRN4pB7YotuUscTQPZIHa
20 matches
Mail list logo
