Defining Transaction objects for multiple database connections – PB Docs 150

Use one Transaction object per connection

To perform operations in multiple databases at the same time,
you need to use multiple Transaction objects, one for each database
connection. You must declare and create the additional Transaction
objects before referencing them, and you must destroy these Transaction
objects when they are no longer needed.

Caution

PowerBuilder creates and destroys SQLCA automatically.
Do not attempt to create or destroy it.

Creating the nondefault Transaction object

To create a Transaction object other than SQLCA, you first declare a variable of
type transaction:

You then instantiate the object:

For example, to create a Transaction object named DBTrans,
code:

Assigning property values

When you assign values to properties of a Transaction object
that you declare and create in a PowerBuilder script, you must assign
the values one property at a time, like this:

You cannot assign values by setting the
nondefault Transaction object equal to SQLCA,
like this:

Specifying the Transaction object in SQL statements

When a database statement requires a Transaction object, PowerBuilder assumes
the Transaction object is SQLCA unless
you specify otherwise. These CONNECT statements
are equivalent:

However, when you use a Transaction object other than SQLCA, you must specify
the Transaction object in the SQL statements
in Table 12-3 with
the USING TransactionObject clause.

Always code the Transaction object

Although specifying the USING TransactionObject clause
in SQL statements is optional
when you use SQLCA and required
when you define your own Transaction object, it is good practice
to code it for any Transaction object, including SQLCA. This avoids confusion
and ensures that you supply USING TransactionObject when
it is required.

Example

The following statements use the default Transaction object
(SQLCA) to communicate with
a SQL Anywhere database and a nondefault Transaction object named ASETrans to
communicate with an Adaptive Server Enterprise database:

Using error checking

An actual script would include error checking after the CONNECT, INSERT, and DISCONNECT statements.

For details, see “Error handling after
a SQL statement”.