472,123 Members | 1,447 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,123 software developers and data experts.

mysqli: prepared statements and fetch_array method?

I'm rewriting a database interface that our company currently has.
Currently it's using the Pear::DB interface, but we found that that was
introducing a bit too much overhead. I'm rewriting the interface to use
mysqli. Most of what the interface does is to simplify getting results in
the form of arrays (ordered and associative). Most of the code using the
interface used sql queries with placeholders and parameters. For that
reason I'd like to use prepared statements in mysqli, but I'm running into
a few problems.

The mysql_result object has a fetch_array method that I'd like to use, but
as far as I can tell it doesn't appear that prepared statements (the
mysqli_stmt class) even uses the mysql_result class. It appears that,
with prepared statements, you must bind variables to the mysqli_stmt
object with bind_result, which causes the statement to set those variables
when you use it's fetch() method. The mysqli_result object can only be
obtained (as far as I can see) using the mysqli_query method with an
unprepared query. (Please let me know if I'm mistaken on this.)

That's were I ran into a more significant problem. When variables are
bound to the statements results, mysqli attempts to convert them to the
appropriate php data types, and I can't find any way to prevent it from
doing so. This makes it impossible to select large integers (larger than
the php integer size) into string variables. mysqli always tries to
convert them to integers and this of course wraps. The existing code
using my interface simply has to have the ability to do this...changing
the underlying SQL to cast columns or the like isn't an option.

Interestingly, the mysqli_result fetch_array method appears to select
everything as strings, much like the old mysql interface. I would prefer
that, as I have code in my interface to do data conversions if and when I
need to. But again, I see no way of using this with prepared statements.

Unless I'm mistaken on this I may have to scrap using prepared statements
altogether and emulate prepared statements by parsing and replacing the
queries placeholders myself (much like pear does) which I'd rather avoid.

Thanks in advance for any suggestions!

Tom
Aug 29 '05 #1
1 3643
On Mon, 29 Aug 2005 18:05:50 -0400, Tom D <no***@nowhere.com> wrote:
I'm rewriting a database interface that our company currently has.
Currently it's using the Pear::DB interface, but we found that that was
introducing a bit too much overhead. I'm rewriting the interface to use
mysqli. Most of what the interface does is to simplify getting results in
the form of arrays (ordered and associative). Most of the code using the
interface used sql queries with placeholders and parameters. For that
reason I'd like to use prepared statements in mysqli, but I'm running into
a few problems.


This isn't a direct answer, it's one of those annoying "you're doing X with Y
but have you looked at Z" answers: if overhead was the main issue, have you
compared it with ADOdb? It fares quite well in benchmarks, particularly when
compared with PEAR which seems to do quite badly.

ADOdb emulates prepared statements for older versions of MySQL, but also has
mysqli support which from a glance at the code does use mysqli_stmt_bind_param,
so is using native prepared statements.

Can't comment as to whether it would solve the other issues, though.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Aug 29 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Mark | last post: by
1 post views Thread by webguynow | last post: by
26 posts views Thread by Dodger | last post: by
2 posts views Thread by ojorus | last post: by
12 posts views Thread by davids58 | last post: by
4 posts views Thread by sugapablo | last post: by
11 posts views Thread by macca | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.