Hans Lellelid wrote:
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 googlePrepared api calls use a binary protocol, which is totally different
searches to no avail. This is really unfortunate. This API sucks!
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 ->
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