[SQL Relay文档] SQL Relay用于PHP Pear DB API的程序设计 (英文)

Programming with SQL Relay using the PHP Pear DB API

• Establishing a Sessions
• Executing Queries
• Commits and Rollbacks
• Temporary Tables
• Catching Errors
• Bind Variables
• Re-Binding and Re-Executing
• Accessing Fields in the Result Set
• Cursors
• Getting Column Information
• Stored Procedures

Establishing a Session

To use SQL Relay, you have to identify the connection that you intend to use.

 '';

  DBconnect"";
 DBisError 
         getMessage;


 execute some queries 

disconnect;

In this connect string, the following components have the following meanings:

testuser	- the username to use to connect to the SQL Relay server, corresponds to the username in an entry in the "users" tag of the sqlrelay.conf file
testpassword	- the password to use to connect to the SQL Relay server, corresponds to the password in an entry in the "users" tag of the sqlrelay.conf file
testhost	- the hostname that the SQL Relay server is running on
9000	- the port that the SQL Relay server is listening on
testdb	- this parameter is ignored; the pear DB spec requires that a database name be included in the connect string, but the database that SQL Relay is connected to is defined in the sqlrelay.conf file

After calling the constructor, a session is established when the first execute() is run.

For the duration of the session, the client stays connected to a database connection daemon. While one client is connected, no other client can connect. Care should be taken to minimize the length of a session.

If you're using a transactional database, ending a session has a catch. Database connection daemons can be configured to send either a commit or rollback at the end of a session if DML queries were executed during the session with no commit or rollback. Program accordingly.

Executing Queries

Call query() to run a query. query() will return DB_OK for successful DML or DDL queries or a result set for select queries.

 '';

  DBconnect"";
 DBisError 
         getMessage;


 query""DB_OK 
         getMessage;


 query""DB_OK 
         getMessage;


query"";

 process the result set 

free;

disconnect;

Commits and Rollbacks

If you need to execute a commit or rollback, you should use the commit() and rollback() functions rather than sending a "commit" or "rollback" query. There are two reasons for this. First, it's much more efficient to call the functions. Second, if you're writing code that can run on transactional or non-transactional databases, some non-transactional databases will throw errors if they receive a "commit" or "rollback" query, but by calling the commit() and rollback() functions you instruct the database connection daemon to call the commit and rollback API functions for that database rather than issuing them as queries. If the API's have no commit or rollback functions, the calls do nothing and the database throws no error. This is especially important when using SQL Relay with ODBC.

You can also turn Autocommit on or off by passing true or false to the autoCommit() function.

The following command turns Autocommit on.

autoCommit;

The following command turns Autocommit off.

autoCommit;

When Autocommit is on, the database performs a commit after each successful DML or DDL query. When Autocommit is off, the database commits when the client instructs it to, or (by default) when a client disconnects. For databases that don't support Autocommit, autoCommit() has no effect.

Temporary Tables

Some databases support temporary tables. That is, tables which are automatically dropped or truncated when an application closes it's connection to the database or when a transaction is committed or rolled back.

For databases which drop or truncate tables when a transaction is committed or rolled back, temporary tables work naturally.

However, for databases which drop or truncate tables when an application closes it's connection to the database, there is an issue. Since SQL Relay maintains persistent database connections, when an application disconnects from SQL Relay, the connection between SQL Relay and the database remains, so the database does not know to drop or truncate the table. To remedy this situation, SQL Relay parses each query to see if it created a temporary table, keeps a list of temporary tables and drops (or truncates them) when the application disconnects from SQL Relay. Since each database has slightly different syntax for creating a temporary table, SQL Relay parses each query according to the rules for that database.

In effect, temporary tables should work when an application connects to SQL Relay in the same manner that they would work if the application connected directly to the database.

Catching Errors

For most functions, you can find out if an error occurred by calling DB::isError() on the result.

When running DML or DDL queries, the query() function should return DB_OK. If it returns anything else, then that also indicates that an error has occurred. When running a select, query() returns a result set and DB::isError() must be used to determine if an error has occurred.

After determining that an error has occurred you can find out why by calling getMessage().

 '';

  DBconnect"";
 DBisError 
         getMessage;


 query""DB_OK 
         getMessage;


 query""DB_OK 
         getMessage;


query"";
 DBisError 
         getMessage;


 process the result set 

free;

disconnect;

Bind Variables

Programs rarely execute fixed queries. More often than not, some part of the query is dynamically generated. The Pear DB API provides means for using bind variables in those queries.

For a detailed discussion of substitutions and binds, see this document.

Here is an example where an associative array is used to bind a set of values to a set of variables. The values in the array are the values that will be substituted in place of the bind variables. The keys in the array may refer to either the name or (1-based) position of the bind variable. The query must be run by calling prepare() and execute(). The array is passed as the second parameter of the call to execute().

 '';

  DBconnect"";
 DBisError 
         getMessage;


prepare"";
""  ,
                ""  "",
                ""  "",
                ""  "",
                ""  "";
execute,;

disconnect;

When passing a floating point number in as a bind or substitution variable, you have to supply precision and scale for the number. See this page for a discussion of precision and scale.

Re-Binding and Re-Execution

Another feature of the prepare/bind/execute paradigm is the ability to prepare, bind and execute a query once, then re-bind and re-execute the query over and over without re-preparing it. If your backend database natively supports this paradigm, you can reap a substantial performance improvement.

 '';

  DBconnect"";
 DBisError 
         getMessage;


prepare"";

""  ,
                ""  "",
                ""  "",
                ""  "",
                ""  "";
execute,;

""  ,
                ""  "",
                ""  "",
                ""  "",
                ""  "";
execute,;

""  ,
                ""  "",
                ""  "",
                ""  "",
                ""  "";
execute,;

""  ,
                ""  "",
                ""  "",
                ""  "",
                ""  "";
execute,;


disconnect;

Accessing Fields in the Result Set

The fetchRow() and fetchInto() methods are useful for processing result sets. fetchRow() returns a row and fetchInto() populates a pre-allocated row. Both can be used to return ordered or associative arrays. The parameter to determine whether the array is ordered or associative may be passed directly into the call or (when using fetchRow()) may be set previously using setFetchMode().

Here is an example using fetchRow() to return an ordered array.

 '';

  DBconnect"";
 DBisError 
         getMessage;


query"";


setFetchModeDB_FETCHMODE_ORDERED;
fetchRow;
;
;
;
;
;

  something with the fields 


fetchRowDB_FETCHMODE_ORDERED;
;
;
;
;
;

  something with the fields 


fetchRowDB_FETCHMODE_ORDERED,;
;
;
;
;
;

  something with the fields 

free;

disconnect;

Here is an example using fetchRow() to return an associative array.

 '';

  DBconnect"";
 DBisError 
         getMessage;


query"";


setFetchModeDB_FETCHMODE_ASSOC;
fetchRow;
'';
'';
'';
'';
'';

  something with the fields 


fetchRowDB_FETCHMODE_ASSOC;
'';
'';
'';
'';
'';

  something with the fields 


fetchRowDB_FETCHMODE_ASSOC,;
'';
'';
'';
'';
'';

  something with the fields 

free;

disconnect;

Here is an example using fetchInto() to populate an ordered array.

 '';

  DBconnect"";
 DBisError 
         getMessage;


query"";


fetchInto,DB_FETCHMODE_ASSOC;
;
;
;
;
;

  something with the fields 


fetchInto,DB_FETCHMODE_ASSOC,;
;
;
;
;
;

  something with the fields 

free;

disconnect;

Here is an example using fetchInto() to populate an associative array.

 '';

  DBconnect"";
 DBisError 
         getMessage;


query"";


fetchInto,DB_FETCHMODE_ASSOC;
'';
'';
'';
'';
'';

  something with the fields 


fetchInto,DB_FETCHMODE_ASSOC,;
'';
'';
'';
'';
'';

  something with the fields 

free;

disconnect;

The Pear DB API also provides convenience functions for fetching an entire result set, single row, single column or single value from a query, all in one step. setFetchMode() applies to some of these functions as well.

getAll() runs a query and fetches the entire result set, all in one step.

 '';

  DBconnect"";
 DBisError 
         getMessage;



setFetchModeDB_FETCHMODE_ORDERED;
getAll"";

"";
  ""    "";
  ""    "";
 etc 
"";
  ""    "";
  ""    "";
 etc 



setFetchModeDB_FETCHMODE_ASSOC;