RE: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Norland, Martin
Wishful thinking on my part, since it specified no version info because
it was likely only in CVS - I thought maybe it was *really new* :).

That is unfortunate then, definitely.  Perhaps a
mysqli_stmt_fetch_assoc() is forthcoming :(

- Martin Norland, Database / Web Developer, International Outreach x3257
The opinion(s) contained within this email do not necessarily represent
those of St. Jude Children's Research Hospital.


-Original Message-
From: Gerard Samuel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 26, 2004 8:49 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DB] mysqli prepared statement query result sets


Norland, Martin wrote:

>The functions you want exist in php5, if that's an option: 
>http://us2.php.net/manual/en/ref.mysqli.php -> 
>http://us2.php.net/manual/en/function.mysqli-fetch-assoc.php
>
>  
>
No this is not an option.
mysqli_fetch_* needs a "result" resource id to work.
mysqli statement functions needs object references (plus there are other
quirks). You cannot use mysqli_fetch_* functions with the mysqli
prepared statement functions...

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Hans Lellelid
Hi Gerard,

> I believe he is talking about ->
> http://dev.mysql.com/doc/mysql/en/SQLPS.html
> But IMHO, I think emulating via php would be faster, as that is
> alot of talking to a database to get the job done, especially if the
> database is on a remote host.

Ahh, ok.  Yes, this is interesting, but certainly not ideal from a uniform
API perspective.  I will stick w/ emulation in PHP.

> Granted, he is correct.  We have no right to say that is sucks.
> Me personally, I do not know at whom to point a finger to blame (maybe
> the mysql C API), but it is what it is unfortunately.
> We just have to make the best of it...

Yes, you're right.  Saying the API sucks was certainly an exaggeration. 
It is a disappointment, but no one sucks.  Georg did an awesome job
bringing this to PHP5. I'll stop complaining & just stick w/ classic mysql
API ;)

-Hans

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Gerard Samuel
Norland, Martin wrote:
The functions you want exist in php5, if that's an option:
http://us2.php.net/manual/en/ref.mysqli.php ->
http://us2.php.net/manual/en/function.mysqli-fetch-assoc.php
 

No this is not an option.
mysqli_fetch_* needs a "result" resource id to work.
mysqli statement functions needs object references (plus there are other
quirks).
You cannot use mysqli_fetch_* functions with the
mysqli prepared statement functions...
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Gerard Samuel
Hans Lellelid wrote:
Hi Georg,
 

Am Di, den 26.10.2004 schrieb Hans Lellelid um 12:57:
   

Ooops, I guess I should have searched the list itself; I did some google
searches to no avail.  This is really unfortunate.  This API sucks!
 

Prepared api calls use a binary protocol, which is totally different
from the "old" protocol. If you don't need binary protocol for prepared
statements, why don't you use native SQL Implementation for prepared
statements instead ??
   

What is "native SQL Implementation for prepared statments"?  All I want to
do is use prepared statements in a non-emulated way.  Like ODBC, OCI8,
mssql callable statements, etc.  I want the speed improvement of using
non-emulated prepared statements.
 

I believe he is talking about ->
http://dev.mysql.com/doc/mysql/en/SQLPS.html
But IMHO, I think emulating via php would be faster, as that is
alot of talking to a database to get the job done, especially if the
database is on a remote host.
It's always easy to claim that stuff other people created (and spent a
lot of time on it) sucks. But it sucks definitely more, if people are
not able to read the PHP and MySQL Documentation carefully.
   

Yes, it is easy, you're right. :) I was looking forward to the speed
increase of using native prepared statements, but it is not useful for
anything I'm doing if the prepared statement API is completely different
from standard queries.
I don't think that there's an issue with documentation here.  The behavior
of mysqli is consistent with everything I read, I just couldn't believe
that it was actually implemented that way.
Anyway, I assume this is a MySQL API, and doesn't have anything to do with
the PHP port.
Hopefully PDO can / does take advantage of the native prepared statements
without the exceptional API.
Granted, he is correct.  We have no right to say that is sucks.
Me personally, I do not know at whom to point a finger to blame (maybe
the mysql C API), but it is what it is unfortunately.
We just have to make the best of it...
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


RE: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Norland, Martin
The functions you want exist in php5, if that's an option:
http://us2.php.net/manual/en/ref.mysqli.php ->
http://us2.php.net/manual/en/function.mysqli-fetch-assoc.php


Cheers,
- Martin Norland, Database / Web Developer, International Outreach x3257
The opinion(s) contained within this email do not necessarily represent
those of St. Jude Children's Research Hospital.


-Original Message-
From: Hans Lellelid [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 26, 2004 5:57 AM
To: Gerard Samuel
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DB] mysqli prepared statement query result sets


Hi Gerard,

Thanks for the reply.

>> I'm writing a db abstraction layer driver for MySQLi.  I'm glad to
>> finally get a chance to play around with these new functions, but am 
>> completely stumped by this question:
>>
>> Is there no way to get back a standard resultset when using prepared
>> statement queries?
>>
>> I don't see the solution, but I hope I'm just missing something 
>> because I've been staring at it too long.
> 
> 
> 
> No you're not missing anything...
> I ran into the same thing... 
> http://marc.theaimsgroup.com/?l=php-db&m=109625996830773&w=2
> So I ended up simulating "prepared" statements via php itself. The way

> the mysqli extension is currently setup, is that you can either use 
> the normal functions by themselves, or you use the statement functions

> by themselves.  They cannot be used together, which I think Never 
> mind, I'll keep my thoughts to myself...

Ooops, I guess I should have searched the list itself; I did some google

searches to no avail.  This is really unfortunate.  This API sucks!  I 
was looking forward to being able to use native prepared statements 
rather than emulating, but I guess that's really not feasible for this 
project.  Argh.

Thanks again for response.

Hans

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Hans Lellelid
Hi Georg,

> Am Di, den 26.10.2004 schrieb Hans Lellelid um 12:57:
>
>> Ooops, I guess I should have searched the list itself; I did some google
>> searches to no avail.  This is really unfortunate.  This API sucks!
>
>
> Prepared api calls use a binary protocol, which is totally different
> from the "old" protocol. If you don't need binary protocol for prepared
> statements, why don't you use native SQL Implementation for prepared
> statements instead ??

What is "native SQL Implementation for prepared statments"?  All I want to
do is use prepared statements in a non-emulated way.  Like ODBC, OCI8,
mssql callable statements, etc.  I want the speed improvement of using
non-emulated prepared statements.

> It's always easy to claim that stuff other people created (and spent a
> lot of time on it) sucks. But it sucks definitely more, if people are
> not able to read the PHP and MySQL Documentation carefully.

Yes, it is easy, you're right. :) I was looking forward to the speed
increase of using native prepared statements, but it is not useful for
anything I'm doing if the prepared statement API is completely different
from standard queries.

I don't think that there's an issue with documentation here.  The behavior
of mysqli is consistent with everything I read, I just couldn't believe
that it was actually implemented that way.

Anyway, I assume this is a MySQL API, and doesn't have anything to do with
the PHP port.

Hopefully PDO can / does take advantage of the native prepared statements
without the exceptional API.

Cheers,
Hans

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Georg Richter
Am Di, den 26.10.2004 schrieb Hans Lellelid um 12:57:

> Ooops, I guess I should have searched the list itself; I did some google 
> searches to no avail.  This is really unfortunate.  This API sucks!  


Prepared api calls use a binary protocol, which is totally different
from the "old" protocol. If you don't need binary protocol for prepared
statements, why don't you use native SQL Implementation for prepared
statements instead ??

It's always easy to claim that stuff other people created (and spent a
lot of time on it) sucks. But it sucks definitely more, if people are
not able to read the PHP and MySQL Documentation carefully.

Just my 2 cents

Georg

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-26 Thread Hans Lellelid
Hi Gerard,
Thanks for the reply.
I'm writing a db abstraction layer driver for MySQLi.  I'm glad to 
finally get a chance to play around with these new functions, but am 
completely stumped by this question:

Is there no way to get back a standard resultset when using prepared 
statement queries?

I don't see the solution, but I hope I'm just missing something 
because I've been staring at it too long.

No you're not missing anything...
I ran into the same thing...
http://marc.theaimsgroup.com/?l=php-db&m=109625996830773&w=2
So I ended up simulating "prepared" statements via php itself.
The way the mysqli extension is currently setup, is that you can either
use the normal functions by themselves, or you use the statement functions
by themselves.  They cannot be used together, which I think
Never mind, I'll keep my thoughts to myself...
Ooops, I guess I should have searched the list itself; I did some google 
searches to no avail.  This is really unfortunate.  This API sucks!  I 
was looking forward to being able to use native prepared statements 
rather than emulating, but I guess that's really not feasible for this 
project.  Argh.

Thanks again for response.
Hans
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DB] mysqli prepared statement query result sets

2004-10-25 Thread Gerard Samuel
Hans Lellelid wrote:
Hi,
I'm writing a db abstraction layer driver for MySQLi.  I'm glad to 
finally get a chance to play around with these new functions, but am 
completely stumped by this question:

Is there no way to get back a standard resultset when using prepared 
statement queries?

I can't believe this would be the case, but it seems that the only 
option when using prepared statements is to call 
myslqi_stmt_bind_result(), binding results to php variables and then 
call mysqli_stmt_fetch($stmt) until it returns null.  i.e.

$sql = "SELECT name, age FROM friends WHERE country = ?";
$stmt = mysqli_prepare($link, $sql);
$country = "Haiti";
mysqli_bind_param($stmt, "s", $country);
mysqli_stmt_execute($stmt);
   /* bind result variables */
   mysqli_stmt_bind_result($stmt, $name, $age);
/* fetch values */
while (mysqli_stmt_fetch($stmt)) {
printf ("%s (%s)\n", $name, $code);
}
What I want to be able to do is use things like mysqli_fetch_assoc() 
instead of this weird, side-effect-prone mysqli_stmt_fetch() to 
retrieve the results.

I don't see the solution, but I hope I'm just missing something 
because I've been staring at it too long.

No you're not missing anything...
I ran into the same thing...
http://marc.theaimsgroup.com/?l=php-db&m=109625996830773&w=2
So I ended up simulating "prepared" statements via php itself.
The way the mysqli extension is currently setup, is that you can either
use the normal functions by themselves, or you use the statement functions
by themselves.  They cannot be used together, which I think
Never mind, I'll keep my thoughts to myself...
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[PHP-DB] mysqli prepared statement query result sets

2004-10-25 Thread Hans Lellelid
Hi,
I'm writing a db abstraction layer driver for MySQLi.  I'm glad to 
finally get a chance to play around with these new functions, but am 
completely stumped by this question:

Is there no way to get back a standard resultset when using prepared 
statement queries?

I can't believe this would be the case, but it seems that the only 
option when using prepared statements is to call 
myslqi_stmt_bind_result(), binding results to php variables and then 
call mysqli_stmt_fetch($stmt) until it returns null.  i.e.

$sql = "SELECT name, age FROM friends WHERE country = ?";
$stmt = mysqli_prepare($link, $sql);
$country = "Haiti";
mysqli_bind_param($stmt, "s", $country);
mysqli_stmt_execute($stmt);
/* bind result variables */
mysqli_stmt_bind_result($stmt, $name, $age);
/* fetch values */
while (mysqli_stmt_fetch($stmt)) {
printf ("%s (%s)\n", $name, $code);
}
What I want to be able to do is use things like mysqli_fetch_assoc() 
instead of this weird, side-effect-prone mysqli_stmt_fetch() to retrieve 
the results.

I don't see the solution, but I hope I'm just missing something because 
I've been staring at it too long.

Thanks in advance,
Hans
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php