differences in the RDBMS ext API's

I don't have the time to answer this in more detail, but some of these
calls are just not supported by ODBC (i.e. select_db). Some are, I just
haven't had the time to commit the patches that create the functionality
and fully test it.

Hi,

ok while talking to marcus about sqlite it came up again that some ext
have different function names for similar things which is really
unnecessary. Here is a list of some most used (just a guestimate)
functions. I used the mysql extension as the basis for the most part.

Some functions obviously don't exist in the ext because the underlying
RDBMS doesn't support it (like prepared queries, autoincrement and
selecting a database etc.).

Please correct me where I am wrong. Some query() functions might be
actually be unbuffered_query() etc. And while doing such a boring work
you tend to make mistakes. Finally I don't know all API's by heart nor
have I used all of them.

Finally I want to mention again that I only looked at the function names
and not at stuff like parameter order etc where I expect to be even more
needless API differences.

I removed the ext prefix for obvious reasons and I put diverging names,
ext where there is no equivalent function or other comments in
parenthesis:

• affected_rows
  missing in ibase, ingress, odbc, ora
  sqlite_changes
  mssql_rows_affected
  ocirowcount
• bind
  missing in ifx
  handled by execute in ibase, odbc
  mssql uses this method to handle stored procdures
  mysqli_bind_param
  ocibindbyname
  prepared not supported by fbsql, ingres, mssql, msql, mysql, pg,
  sqlite, sybase
• close
  ocilogoff
• connect
  ocilogon
  oralogon
  sqlite_open
• data_seek
  missing in ifx, ibase, ingress, odbc, oci, ora, pg
  sqlite_seek - due to spl
• errno
  ifx_error
  odbc_error
  ora_errorcode
  missing in ibase, ingress, mssql, msql, oci, pg, sqlite, sybase
• error
  ifx_errormsg
  ibase_errmsg
  mssql_get_last_message
  sybase_get_last_message
  odbc_errormsg
  ocierror
  pg_last_error
  sqlite_error_string
  missing in ingres
• escape_string
  missing in fbsql, ifx, ibase, ingress, mssql, msql, odbc, oci, ora,
  sybase
  mysqli_real_escape_string
• execute
  ifx_do
  mssql uses this method to handle stored procedures
  ociexecute
  ora_exec
  prepared not supported by fbsql, ingres, mssql, msql, mysql, pg,
  sqlite, sybase
• fetch_array
  missing in ifx, ibase
  ocifechtino
  ora_fetch_into
• fetch_assoc
  ifx_fetch_row
  missing in ingress, msql, odbc, oci, ora, sqlite
• fetch_object
  missing in ifx, oci, ora, sqlite
• fetch_row
  missing in ibase, oci, ora, sqlite
• free_query
  missing in ifx, mysqli, odbc, ora
  mysqli_stmt_close
  ocifreecursor
  prepared not supported by fbsql, ingres, mssql, msql, mysql, pg,
  sqlite, sybase
• free_result
  ocifreestatement
  missing in ingress, ora, sqlite
• insert_id
  sqlite_last_insert_rowid
  not supported by ifx, ibase, ingres, mssql*, msql, odbc, oci, ora,
  pg, sybase*
• next_result
  only exists in fbsql and mssql
• num_fields
  ocinumcols
  ora_numcols
• num_rows
  missing since buffering is not supported in ibase, oci
  ora_numrows
• pconnect
  missing because it was found to be not feasible in mysqli
  ora_plogon
  ociplogon
  sqlite_popen
• prepare
  ociparse
  ora_parse
  prepared not supported by fbsql, ingress, mssql, mysql, pg, sqlite,
  sybase
• query
  is unbuffered in ibase
  pg_send_query
  missing in odbc, oci, ora
• result
  missing in ifx, ibase, ingres, mysqli, oci, ora, sqlite
• select_db
  missing in ifx, ibase, ingres, odbc, oci, ora, pg, sqlite
• unbuffered_query
  missing in fbsql, ifx, ingres, mssql, msql, odbc, ora, pg
  ibase_query
  ociexecute

regards,
Lukas Smith
smith@backendmedia.com

---

BackendMedia
www.backendmedia.com
berlin@backendmedia.com

Linn Zwoch Smith GbR
Pariser Str. 44
D-10707 Berlin

Tel +49 30 83 22 50 00
Fax +49 30 83 22 50 07

---------------------------------------------------------------<
Dan Kalowsky "I thought you died alone,
http://www.deadmime.org/~dank a long long time ago."
dank-nom@aps-deadmime.org - "The Man Who Sold the World"
kalowsky@php.net David Bowie

Please correct me where I am wrong. Some query() functions might be
actually be unbuffered_query() etc. And while doing such a boring work
you tend to make mistakes. Finally I don't know all API's by heart nor
have I used all of them.

First of all, in my opinion it would be more useful to concentrate on a
true cross-database PHP-level data-object API which can really hide the
differences between db implementations, instead of using the exact same
function names, and ignoring the implementation differences between the
various systems. I'd rather implement buffered queries at the PHP-level
for all extensions instead of for Interbase only.

There are some things I'd like to add, mostly concerning the Interbase
extension:

• affected_rows

Has been implemented and committed to HEAD.

• bind

mssql_bind()/mysqli_bind_result() are used to bind output parameters to
variable references, which is totally different from binding variables
values at query execute time. The former is not supported directly by
the Interbase API, but could by implemented in the PHP layer.

• data_seek
• result
• query
• unbuffered_query

Query result buffering in Interbase is carried out by the client
library. The only tunable is the buffer count in ibase_connect(). It
would be possible to have ibase_query() fetch an entire result and store
it internally before returning. This would enable the use of
data_seek(), which is currently unsupported, but it would also break BC,
as current applications that work with huge result sets would start
consuming an awful amount of memory.

Maybe call it buffered_query() and let individual extensions decide
which version query() maps to ?

• errno
  ifx_error
  odbc_error
  ora_errorcode
  missing in ibase, ingress, mssql, msql, oci, pg, sqlite, sybase

Has been implemented and committed to HEAD as ibase_errcode() :-)
(So now is the time for a name change)

• escape_string
  missing in fbsql, ifx, ibase, ingress, mssql, msql, odbc, oci, ora,
  sybase

... and for a reason!

If you use params + binding, the medieval practice of escaping strings
is unnecessary. Will probably never be implemented for Interbase.

• fetch_array
• fetch_row
  missing in ibase, oci, ora, sqlite

Fetch_row /is/ supported by Interbase.
Is there a distinction in semantics between fetch_row() and
fetch_array() ? Don't all the fetch_() functions fetch a row ?

Maybe fetch_row() with a modifier should be an alias for the other fetch
functions (like in mysql) This would also allow changing the interfaces
without breaking BC.

• insert_id

Cannot be supported by Interbase, because it uses generators and trigger
for auto-inc fields. There's a function ibase_gen_id() in HEAD, which
can be used to generate an id and insert it manually into the id
position. This provides basically the same functionality.

• next_result
  only exists in fbsql and mssql

Only makes sense if you allow chained queries. This is not the case in
Interbase.

• num_rows

Has been implemented and removed again from HEAD, as the underlying API
function returns inconsistent results. Could be re-implemented to work
with buffered queries.

• select_db

Has no meaning in Interbase, because you cannot connect to a server
without specifying the database.

Hi Lukas,

good job!

• bind
  ..
  mysqli_bind_param
  and mysqli_bind_result

• errno/error
  mysqli supports 2 types of errno/error
  mysqli_errno/error and mysqli_sqlstate. mysqli_sqlstate returns ANSI/ODBC
  conform errorcodes.
• next_result
  only exists in fbsql and mssql
  on todo for mysqli until MySQL AB added an separate call for multi queries.

• pconnect
  missing because it was found to be not feasible in mysqli
  will be replaced by an call to an external broker

missing: fetch
to retrieve data from a prepared statement (mysqli_fetch)

Georg