• Compiling an SQL Relay Client Program
• Establishing a Sessions
• Executing Queries
• Commits and Rollbacks
• Temporary Tables
• Catching Errors
• Substitution and Bind Variables
• Re-Binding and Re-Executing
• Accessing Fields in the Result Set
• Dealing With Large Result Sets
• Cursors
• Getting Column Information
• Stored Procedures
• Caching The Result Set
• Suspending and Resuming Sessions

When writing an SQL Relay client program using the C API, you need to include the sqlrclientwrapper.h file.

#include <sqlrelay/sqlrclientwrapper.h>

You''''ll also need to link against the sqlrclientwrapper, sqlrclient and rudiments libraries. The include file is usually found in /usr/local/firstworks/include and the libraries are usually found in /usr/local/firstworks/lib.

The command to compile your .c file to object code will look something like this (assuming you''''re using the GNU C compiler):

gcc -I/usr/local/firstworks/include -c myprogram.c

The command to compile your .o file to an executable will look something like this (assuming you''''re using the GNU C++ compiler):

g++ -o myprogram myprogram.o -L/usr/local/firstworks/lib -lsqlrclientwrapper -lsqlrclient -lrudiments

Note that g++ was used to link, not gcc. You could alternatively link using gcc like this:

gcc -o myprogram myprogram.o -L/usr/local/firstworks/lib -lsqlrclientwrapper -lsqlrclient -lrudiments -lstdc++

When using the C API, it is important to compile the .c files to object code using the C compiler before linking them using the C++ compiler. Compiling/Linking in one step using the C++ compiler the will most likely fail as it will generate C++ style symbols for function calls which will not be resolved in the sqlrclientwrapper library since it contains C style function symbols. Compiling to object code using the C compiler as a seperate step ensures that C style symbols will be generated for function calls.

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

#include <sqlrelay/sqlrclientwrapper.h>
#include <stdio.h>

main() {

        sqlrcon      con=sqlrcon_alloc("host",9000,"","user","password",0,1);

        ... execute some queries ...

        sqlrcon_free(con);
}

After calling the constructor, a session is established when the first query, sqlrcur_ping() or sqlrcur_identify() 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.

Call sqlrcur_sendQuery() or sqlrcur_sendFileQuery() to run a query.

#include <sqlrelay/sqlrclientwrapper.h>
#include <stdio.h>

main() {

        sqlrcon      con=sqlrcon_alloc("host",9000,"","user","password",0,1);
        sqlrcur      cur=sqlrcur_alloc(con);

        sqlrcur_sendQuery(cur,"select * from my_table");

        ... do some stuff that takes a short time ...

        sqlrcur_sendFileQuery(cur,"/usr/local/myprogram/sql","myquery.sql");
        sqlrcon_endSession(con);

        ... do some stuff that takes a long time ...

        sqlrcur_sendQuery(cur,"select * from my_other_table");
        sqlrcon_endSession(con);

        ... process the result set ...

        sqlrcur_free(cur);
        sqlrcon_free(con);
}

Note the call to sqlrcon_endSession() after the call to sqlrcur_sendFileQuery(). Since the program does some stuff that takes a long time between that query and the next, ending the session there allows another client an opportunity to use that database connection while your client is busy. The next call to sqlrcur_sendQuery() establishes another session. Since the program does some stuff that takes a short time between the first two queries, it''''s OK to leave the session open between them.

If you need to execute a commit or rollback, you should use the sqlrcon_commit() and sqlrcon_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 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 sqlrcon_commit() and sqlrcon_rollback() functions 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 with the sqlrcon_autoCommitOn() and sqlrcon_autoCommitOff() functions. 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, sqlrcon_autoCommitOn() and sqlrcon_autoCommitOff() have no effect.

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

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ...  下一页 >>