It's completely capable, just inefficient.
Those 'basic functions' are relying on the particular way that mysqli works, which is different from many other db wrappers. PDO is a big use-case but there are others. I thought we were concerned about platform independence?
It's possible to rewrite almost all of the calls to DB_num_rows() as a simple check if there is data (DB_has_rows() as a check for if the data has columns could work equally fast for pretty much any db wrapper for example).
DB_data_seek isn't used much, but most of the time it's used to return to the first row. It's inefficient the way I've written the PDO extension now, but it works. It wouldn't be necessary to use it at all for most cases if the information from the first row was stored in a variable and used later.
(04-04-2014, 12:32 PM)phil Wrote: DB_fetch_row - always expects a non-associative array ... I think so the index is always 0,1,2...etc
DB_fetch_array - always returns an associative array with nice names as indexes we are trying to move to this function in 99% of places.
Seems like a show stopper for PDO if it is not capable of reproducing basic functions that are necessary in webERP code - not sure it is worth a re-write to be PDO capable?
OK I am for the switch away from DB_fetch_row if that is the case, there are a few cases where they are used inconsistent with this, but the code works since mysqli gives back both associative and numeric keys by default. When I tried strictly typing to associative or numeric it caused problems, but we can sort that out if we're rewriting anyway.