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
Hi,
I would appreciate it if the database extensions would no longer return
false when no rows are left in the result set but instead return null.
The current way of returning false creates a level of ambiguity which can
lead to serious issue in error handling.
For example in mysql there is no w
21 matches
Mail list logo
