![]()
|
Programming with SQL Relay using the Ruby DBI API
To use SQL Relay, you have to identify the connection that you intend to use.
After calling connect() and prepare(), 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 QueriesCall prepare() and execute() to run a query.
Commits and RollbacksIf you need to execute a commit or rollback, you should use the commit() and rollback() methods rather than sending a "commit" or "rollback" query. There are two reasons for this. First, it's much more efficient to call the methods. 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() methods you instruct the database connection daemon to call the commit and rollback API methods for that database rather than issuing them as queries. If the API's have no commit or rollback methods, 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 setting the AutoCommit attribute of the database handle. The following command turns Autocommit on. db["AutoCommit"]=true The following command turns Autocommit off. db["AutoCommit"]=false 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, setting the AutoCommit attribute has no effect. Catching ErrorsIf your call to execute() raises an exception, the query failed. You can find out why by catching the exception.
Bind VariablesPrograms rarely execute fixed queries. More often than not, some part of the query is dynamically generated. The Ruby DBI API provides the bind_param method for using bind variables in those queries. For a detailed discussion of binds, see this document.
Re-Binding and Re-ExecutionA 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.
Accessing Fields in the Result SetThe fetch(), fetch_many() and fetch_all() methods are useful for processing result sets. fetch() returns a list of values. fetch_many() and fetch_all() each return an Array of rows where each row is an Array of values. The rows() method gives the number of rows in the result set of a select query.
The fetch_scroll() method provides arbitrary access to the result set. You can use it to skip forward or backward.
Concurrent StatementsIt is possible to execute queries while processing the result set of another query. You can select rows from a table in one query, then iterate through it's result set, inserting rows into another table, using only 1 database connection for both operations. For example:
Getting Column InformationAfter executing a query, column information can be retrieved using the column_info() method. column_info() returns an Array of hashes. Each hash contains 'name', 'type_name' and 'precision' keys.
|