This chapter provides reference information for the Transaction Log API (XLA) described in Chapter 5, "XLA and TimesTen Event Management". It includes the following topics:
This section includes general information about XLA functions.
All of the XLA API functions described in this chapter return a value of type SQLRETURN, which is defined by ODBC to have one of the following values:
SQL_SUCCESS
SQL_SUCCESS_WITH_INFO
SQL_NO_DATA_FOUND
SQL_ERROR
See "Handling XLA errors" for information on handling XLA errors.
In the function descriptions:
All parameters are input-only unless otherwise indicated.
Output parameters are prefixed with OUT.
Input-output parameters are prefixed with IN OUT.
Most routines in this API copy results to application buffers. Those few routines that produce pointers to buffers containing results are guaranteed to remain valid only until the next call with the same XLA handle.
Exceptions to this rule include the following.
Buffers remain valid across calls to the ttXlaError function that supplies diagnostic information.
Results returned by ttXlaNextUpdate remain valid until the next call to ttXlaNextUpdate.
For ttXlaConfigBuffer, or ttXlaAcknowledge in persistent mode, if the application must retain access to the buffers for a longer time, it must copy the information from the buffer returned by XLA to an application-owned buffer.
Character string values in XLA are null- terminated, except for actual column values. Fixed-length CHAR columns are space-padded to their full length. VARCHAR columns have an explicit length encoded.
XLA uses the same data structures for both 32- and 64-bit platforms. The types SQLUINTEGER and SQLUBIGINT are used to refer to 32- and 64-bit integers unambiguously. Issues of alignment and padding are addressed by filling the type definition so that each SQLUINTEGER value is on a four-byte boundary and each SQLUBIGINT value is on an eight-byte boundary. For a description of storage requirements for other TimesTen data types, see "Understanding rows" in Oracle TimesTen In-Memory Database Operations Guide.
"Access control impact on XLA" introduces the effects of TimesTen access control features on XLA functionality. Any XLA functionality requires the system privilege XLA.
As described in Chapter 5, "XLA and TimesTen Event Management", TimesTen XLA can be used to detect updates on a database or as a toolkit to build your own replication solution. You can initialize XLA in either persistent or non-persistent mode, but use of non-persistent mode is discouraged.
This section categorizes the XLA functions based on their use and provides a brief description of each function. It includes the following categories:
The following table lists core XLA functions that can be used by any XLA application:
| Function | Description |
|---|---|
ttXlaClose |
Closes the XLA handle opened by ttXlaPersistOpen. |
ttXlaConvertCharType |
Converts column data into the connection character set. |
ttXlaError |
Retrieves error information. |
ttXlaErrorRestart |
Resets error stack information. |
ttXlaGetColumnInfo |
Retrieves information about all the columns in the table. |
ttXlaGetTableInfo |
Retrieves information about a table. |
ttXlaGetVersion |
Retrieves the current version of XLA. |
ttXlaNextUpdate |
Retrieves a batch of updates from TimesTen. |
ttXlaNextUpdateWait |
Retrieves a batch of updates from TimesTen. Will wait for a specified time if no updates are available in the transaction log. |
ttXlaTableByName |
Finds the system and user table identifiers for a table given the table's owner and name. |
ttXlaTableStatus |
Sets and retrieves XLA status for a table. |
ttXlaSetVersion |
Sets the XLA version to be used. |
ttXlaTableVersionVerify |
Checks whether the cached table definitions are compatible with the XLA record being processed. |
ttXlaVersionColumnInfo |
Retrieves information about the columns in a table for which a change update record must be processed. |
ttXlaVersionCompare |
Compares two XLA versions. |
See "Writing an XLA event-handler application" for a discussion on how to use most of these functions.
The following table lists data type conversion functions that can be used by any XLA application:
| Function | Description |
|---|---|
ttXlaDateToODBCCType |
Converts a TTXLA_DATE_TT value to an ODBC C value usable by applications. |
ttXlaDecimalToCString |
Converts a TTXLA_DECIMAL_TT value to a character string usable by applications. |
ttXlaNumberToBigInt |
Converts a TTXLA_NUMBER value to a SQLBIGINT C value usable by applications. |
ttXlaNumberToCString |
Converts a TTXLA_NUMBER value to a character string usable by applications. |
ttXlaNumberToDouble |
Converts a TTXLA_NUMBER value to a long floating point number value usable by applications. |
ttXlaNumberToInt |
Converts a TTXLA_NUMBER value to an integer usable by applications. |
ttXlaNumberToSmallInt |
Converts a TTXLA_NUMBER value to a SQLSMALLINT C value usable by applications. |
ttXlaNumberToTinyInt |
Converts a TTXLA_NUMBER value to a SQLCHAR C value usable by applications. |
ttXlaNumberToUInt |
Converts a TTXLA_NUMBER value to an unsigned integer usable by applications. |
ttXlaOraDateToODBCTimeStamp |
Converts a TTXLA_DATE value to an ODBC timestamp usable by applications. |
ttXlaOraTimeStampToODBCTimeStamp |
Converts a TTXLA_TIMESTAMP value to an ODBC timestamp usable by applications. |
ttXlaRowidToCString |
Converts a ROWID value to a character string value usable by applications. |
ttXlaTimeToODBCCType |
Converts a TTXLA_TIME value to an ODBC C value usable by applications. |
ttXlaTimeStampToODBCCType |
Converts a TTXLA_TIMESTAMP_TT value to an ODBC C value usable by applications. |
For more information about XLA data types, see "About XLA data types".
The following table lists the functions that are exclusive to operating XLA in persistent mode:
| Function | Description |
|---|---|
ttXlaPersistOpen |
Initializes a handle to a database to access the transaction log in persistent mode. |
ttXlaAcknowledge |
Acknowledges receipt of one or more transaction update records from the transaction log. |
ttXlaDeleteBookmark |
Deletes a transaction log bookmark. |
ttXlaGetLSN |
Retrieves the log record identifier of the current bookmark for a database. |
ttXlaSetLSN |
Sets the log record identifier of the current bookmark for a database. |
See "Writing an XLA event-handler application" for a discussion on how to use these functions.
Note:
TimesTen recommends using XLA in persistent mode.The following table lists the functions that are exclusive to operating XLA in non-persistent mode:
| Function | Description |
|---|---|
ttXlaOpenTimesTen |
Initializes a handle to a database to access the transaction log in non-persistent mode. |
ttXlaConfigBuffer |
Sets the size of the XLA staging buffer. |
ttXlaStatus |
Retrieves the current XLA status. |
ttXlaResetStatus |
Resets all the XLA statistics counters. |
The following table lists the functions that are exclusive to using XLA as a replication mechanism include the following.
| Function | Description |
|---|---|
ttXlaApply |
Applies the update to the database associated with the XLA handle. |
ttXlaTableCheck |
Verifies that the named table in the table description received from the sending database is compatible with the receiving database. |
ttXlaLookup |
Looks for an update record for a table with a specific key value. |
ttXlaRollback |
Rolls back a transaction. |
ttXlaCommit |
Commits a transaction. |
ttXlaGenerateSQL |
Generates a SQL statement that expresses the effect of an update record. |
See "Using XLA as a replication mechanism" for a discussion on how to use these functions.
This section provides reference information for each XLA function. Functions are listed in alphabetical order.
This function is used in persistent mode to acknowledge that one or more records have been read from the transaction log by the ttXlaNextUpdate or ttXlaNextUpdateWait function.
After you make this call, the bookmark is reset so that you cannot reread any of the previously returned records. Call ttXlaAcknowledge only when messages have been completely processed.
Notes:
The bookmark is only reset for the specified handle. Other handles in the system may still be able to access those earlier transactions.
The bookmark is reset even if there are no relevant update records to acknowledge.
Note that ttXlaAcknowledge is an expensive operation that should be used only as necessary. Calling ttXlaAcknowledge more than once per reading of the transaction log file does not reduce the volume of the transaction log since XLA only purges transaction logs a file at a time. To detect when a new transaction log file is generated, you can find out which log file a bookmark is in by examining the purgeLSN (represented by the PURGELSNHIGH and PURGELSNLOW values) for the bookmark in the system table SYS.TRANSACTION_LOG_API. You can then call ttXlaAcknowledge to purge the old transaction log files. (Note that you must have ADMIN or SELECT ANY TABLE privilege to view this table.)
The second purpose of ttXlaAcknowledge is to ensure that the XLA application does not see the acknowledged records if it were to connect to a previously used bookmark by calling the ttXlaPersistOpen function with the XLAREUSE option. If you intend to reuse a bookmark, call ttXlaAcknowledge to reset the bookmark position to the current record before calling ttXlaClose.
See "Retrieving update records from the transaction log" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaAcknowledge(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
rc = ttXlaAcknowledge(xlahandle);
ttXlaNextUpdatettXlaNextUpdateWait
Applies an update to the database associated with the transaction log handle. The return value indicates whether the update was successful. The return also shows if the update encountered a persistent problem. (To see whether the update encountered a transient problem such as a deadlock or timeout, you must call ttXlaError and check the error code.)
If the ttXlaUpdateDesc_t record is a transaction commit, the underlying database transaction is committed. No other transaction commits are performed by ttXlaApply. If the parameter test is true, the "old values" in the update description are compared against the current contents of the database for record updates and deletions. If the old value in the update description does not match the corresponding row in the database, this function rejects the update and returns an sb_ErrXlaTupleMismatch error.
See "Using XLA as a replication mechanism" for a discussion about using this function.
Note:
ttXlaApply cannot be used if the table definition was updated since it was originally written to the transaction log. Unique key and foreign key constraints are checked at the row level rather than at the statement level.Requires the system privilege ADMIN.
Additional privileges may be required on the target database for the ttXlaApply operation. For example, to apply a CREATETAB (create table) record to the target database, you must have CREATE TABLE or CREATE ANY TABLE privilege, as appropriate.
SQLRETURN ttXlaApply(ttXlaHandle_h handle, ttXlaUpdateDesc_t* record, SQLINTEGER test)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
record |
ttXlaUpdateDesc_t* |
Transaction to generate SQL statement. |
test |
SQLINTEGER |
Test for old values:
|
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
If test is 1 and ttXlaApply detects an update conflict, an sb_ErrXlaTupleMismatch error is returned.
This example applies an update to a database without testing for the previous value of the existing record:
ttXlaUpdateDesc_t record; rc = ttXlaApply(xlahandle, &record, 0);
When calling ttXlaApply, it is possible for the update to timeout or deadlock with concurrent transactions. In such cases, it is the application's responsibility to roll the transaction back and reapply the updates.
ttXlaCommitttXlaRollbackttXlaLookupttXlaTableCheckttXlaGenerateSQL
Closes an XLA handle that was opened by ttXlaPersistOpen. See "Terminating an XLA application" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaClose(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The ODBC handle for the database. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
To close the XLA handle opened in the previous example, use the following call:
rc = ttXlaClose(xlahandle);
ttXlaPersistOpen
Commits the current transaction being applied on the transaction log handle. This routine commits the transaction regardless of whether the transaction has completed. You can call this routine to respond to transient errors (timeout or deadlock) reported by ttXlaApply, which applies the current transaction if it does not encounter an error.
See "Handling timeout and deadlock errors" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaCommit(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
rc = ttXlaCommit(xlahandle);
ttXlaApplyttXlaRollbackttXlaLookupttXlaTableCheckttXlaGenerateSQL
This function is valid only when XLA is in non-persistent mode (which is generally discouraged).
You can use the ttXlaConfigBuffer function to both set and get the size of the XLA staging buffer, which is where XLA stages the update records obtained from the transaction log and makes them available to be read by the application.
To first set the size of the staging buffer, specify a value for the newSize parameter and a null value for the oldSize parameter. The new size of the staging buffer is retrieved from *newSize. A size of zero indicates no staging buffer should be allocated.
To change the size of the staging buffer, specify a value for newSize and provide an oldSize parameter. Upon return, *oldSize contains the previous size of the staging buffer, or 0 if the size had not been set.
To retrieve but not change the current size of the staging buffer, specify a null value for newSize. The current size of the staging buffer is returned in *oldSize.
When choosing the size of your staging buffer, consider that if the buffer is too small, TimesTen updates will exhaust the buffer, causing further updates to be rejected. Conversely, over-allocating space for the buffer wastes memory.
After setting the size of your staging buffer, you can resize it at any time. However, resizing may result in copying the current buffer and therefore incurring substantial performance penalties.
Changes to the staging buffer size are carried out immediately. When the buffer is resized, records that were returned by previous calls to ttXlaNextUpdate or ttXlaNextUpdateWait become invalid.
Only one buffer may be configured for a database. When the buffer is resized, values returned by previous calls on ttXlaNextUpdate become invalid.
Notes:
If the XLA staging buffer is set to a nonzero size and no XLA reader is connected, updates on the database will be written into the buffer. When the staging buffer becomes full, database operations cannot successfully complete until you either delete the staging buffer (size set to 0) or connect an XLA reader and begin reading from the buffer.
If a smaller size is specified for the staging buffer and the current contents will not fit in the smaller size, the buffer size is not changed and an error is returned.
Requires the system privilege XLA.
SQLRETURN ttXlaConfigBuffer(ttXlaHandle_h handle, out SQLUBIGINT* oldSize, SQLUBIGINT* newSize)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
oldSize |
out SQLUBIGINT* |
Current size of the staging buffer. |
newSize |
SQLUBIGINT* |
New size of the staging buffer. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
Assume the following declarations for our examples:
SQLUBIGINT currentSize, requestedSize;
To find the current size of the staging buffer without changing the size:
rc = ttXlaConfigBuffer(xlahandle, ¤tSize, NULL);
To set the size of the staging buffer to 400,000 bytes:
requestedSize = 400000; ... rc = ttXlaConfigBuffer(xlahandle, NULL, &requestedSize);
To change the size of the staging buffer to 400,000 bytes and retrieve the previous size:
requestedSize = 400000; ... rc = ttXlaConfigBuffer(xla_handle, ¤tSize, &requestedSize);
To delete the staging buffer:
requestedSize = 0; ... rc = ttXlaConfigBuffer(xlahandle, NULL, &requestedSize);
Buffer resizing may copy the current buffer and therefore incur substantial performance penalties. If a smaller size is specified for the staging buffer and the current contents will not fit in the smaller size, the staging buffer size is not changed and an error is returned.
ttXlaOpenTimesTenttXlaStatusttXlaResetStatus
Converts the column data indicated by the colinfo and tup parameters into the connection character set associated with the transaction log handle and places the result in a buffer.
Requires the system privilege XLA.
SQLRETURN ttXlaConvertCharType (ttXlaHandle_h handle, ttXlaColDesc_t* colinfo, void* tup, void* buf, size_t buflen)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
colinfo |
ttXlaColDesc_t* |
A pointer to the buffer that holds the column descriptions. |
tup |
void* |
The data that is to be converted. |
buf |
void* |
Location where the converted data is placed. |
buflen |
size_t |
Size of the buffer where the converted data is placed. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
Converts a TTXLA_DATE_TT value to an ODBC C value usable by applications. See "Converting complex data types" for a discussion about using this function.
Call this function only on a column of data type TTXLA_DATE_TT. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaDateToODBCCType(void* fromData, out DATE_STRUCT* returnData)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the date value returned from the transaction log. |
returnData |
out DATE_STRUCT* |
Pointer to storage allocated to hold the converted date. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
Converts a TTXLA_DECIMAL_TT value to a string usable by applications. The scale and precision values can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function. The scale parameter specifies the maximum number of digits after the decimal point. If the decimal value is larger than 1, the precision parameter should specify the maximum number of digits before and after the decimal point. If the decimal value is less than 1, precision equals scale.
Call this function only for a column of type TTXLA_DECIMAL_TT. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
See "Converting complex data types" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaDecimalToCString(void* fromData, out char* returnData, SQLSMALLINT precision, SQLSMALLINT scale)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the decimal value returned from the transaction log. |
returnData |
out char* |
Pointer to storage allocated to hold the converted string. |
precision |
SQLSMALLINT |
If fromData is larger than 1, precision is the maximum number of digits before and after the decimal point. If fromData is less than 1, precision equals scale. |
scale |
SQLSMALLINT |
Maximum number of digits after the decimal point. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example assumes you have obtained the offset, precision, and scale values from a ttXlaColDesc_t structure and used the offset to obtain a decimal value, pColVal, in a row returned in a transaction log record.
char decimalData[50];
static ttXlaColDesc_t colDesc[255];
rc = ttXlaDecimalToCString(pColVal, (char*)&decimalData,
colDesc->precision,
colDesc->scale);
Deletes the bookmark associated with the specified transaction log handle. After the bookmark has been deleted, it is no longer accessible and its identifier may be reused for another bookmark. The deleted bookmark is no longer associated with the database handle and the effect is the same as having opened the persistent connection with the XLANONE option.
If the bookmark is in use, it cannot be deleted until it is no longer in use.
See "Deleting bookmarks" for a discussion about using this function.
Notes:
Do not confuse this with the TimesTen built-in procedure ttXlaBookmarkDelete, documented in "ttXlaBookmarkDelete" in Oracle TimesTen In-Memory Database Reference.
You cannot delete replicated bookmarks while the replication agent is running.
Requires the system privilege XLA.
SQLRETURN ttXlaDeleteBookmark(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
Delete the bookmark for xlahandle:
rc = ttXlaDeleteBookmark(xlahandle);
ttXlaPersistOpenttXlaGetLSNttXlaSetLSN
Reports details of any errors encountered from the previous call on the given transaction log handle. Multiple errors may be returned through subsequent calls to ttXlaError. The error stack is cleared following each call to a function other than ttXlaError itself and ttXlaErrorRestart.
See "Handling XLA errors" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaError(ttXlaHandle_h handle, out SQLINTEGER* errCode, out char* errMessage, SQLINTEGER maxLen, out SQLINTEGER* retLen)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
errCode |
out SQLINTEGER* |
The code of the error message to be copied into the errMessage buffer. |
errMessage |
out char* |
Buffer to hold the error text. |
maxLen |
SQLINTEGER |
The maximum length of the errMessage buffer. |
retLen |
out SQLINTEGER* |
The actual size of the error message. |
SQL_SUCCESS if error information is returned and SQL_NO_DATA_FOUND if no more errors are found in the error stack. If the errMessage buffer is not large enough, ttXlaError returns SQL_SUCCESS_WITH_INFO.
There can be multiple errors on the error stack. This example shows how to read them all.
char message[100];
SQLINTEGER code;
for (;;) {
rc = ttXlaError(xlahandle, &code, message, sizeof (message), &retLen);
if (rc == SQL_NO_DATA_FOUND)
break;
if (rc == SQL_ERROR) {
printf("Error in fetching error message\n");
break;
}
else {
printf("Error code %d: %s\n", code, message);
}
}
If you use multiple threads to access a TimesTen transaction log over a single XLA connection, TimesTen creates a latch to control concurrent access. If for some reason the latch cannot be acquired by a thread, the XLA function returns SQL_INVALID_HANDLE.
Resets the error stack so that an application can reread the errors. See "Handling XLA errors" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaErrorRestart(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
rc = ttXlaErrorRestart(xlahandle);
Generates a SQL DML or DDL statement that expresses the effect of the update record. The generated statement is not applied to any database. Instead, the statement is returned in the given buffer, whose maximum size is specified by the maxLen parameter. The actual size of the buffer is returned in actualLen. For update and delete records, ttXlaGenerateSQL requires a primary key or a unique index on a non-nullable column to generate the correct SQL.
The generated SQL statement is encoded in the connection character set that is associated with the ODBC connection of the XLA handle.
Also see "Replicating updates to a non-TimesTen database".
Requires the system privilege XLA.
SQLRETURN ttXlaGenerateSQL(ttXlaHandle_h handle, ttXlaUpdateDesc_t* record, out char* buffer, SQLINTEGER maxLen, out SQLINTEGER* actualLen)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
record |
ttXlaUpdateDesc_t* |
The record to be translated into SQL. |
buffer |
out char* |
Location of the translated SQL statement. |
maxLen |
SQLINTEGER |
The maximum length of the buffer, in bytes. |
actualLen |
out SQLINTEGER* |
The actual length of the buffer, in bytes. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example generates the text of a SQL statement that is equivalent to the UPDATE expressed by an update record:
ttXlaUpdateDesc_t record;
char buffer[200];
/*
* Get the desired update record into the varable record.
*/
SQLINTEGER actualLength;
rc = ttXlaGenerateSQL(xlahandle, &record, buffer, 200,
&actualLength);
The ttXlaGenerateSQL function cannot generate SQL statements for update records associated with a table that has been dropped or altered since the record was generated.
ttXlaApplyttXlaCommitttXlaRollbackttXlaLookupttXlaTableCheck
Retrieves information about all the columns in the table. Normally, the output parameter for number of columns returned, nreturned, is set to the number of columns returned in colinfo. The systemTableID or userTableID parameter describes the desired table. This call is serialized with respect to changes in the table definition.
See "Obtaining column descriptions" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaGetColumnInfo(ttXlaHandle_h handle, SQLUBIGINT systemTableID, SQLUBIGINT userTableID, out ttXlaColDesc_t* colinfo, SQLINTEGER maxcols, out SQLINTEGER* nreturned)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
systemTableID |
SQLUBIGINT |
System ID of table. |
userTableID |
SQLUBIGINT |
User ID of table. |
colinfo |
out ttXlaColDesc_t* |
A pointer to the buffer large enough to hold a separate description for maxcols columns. |
maxcols |
SQLINTEGER |
The maximum number of columns that can be stored in the colInfo buffer. If the table contains more than maxcols columns, an error is returned. |
nreturned |
out SQLINTEGER* |
The number of columns returned. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
For this example, assume the following definitions:
ttXlaColDesc_t colinfo[20]; SQLUBIGINT systemTableID, userTableID; SQLINTEGER ncols;
To get the description of up to 20 columns using the system table identifier, issue the following call:
rc = ttXlaGetColumnInfo(xlahandle, systemTableID, 0, colinfo, 20, &ncols);
Likewise, the user table identifier can be used:
rc = ttXlaGetColumnInfo(xlahandle, 0, userTableID, colinfo, 20, &ncols);
See "ttXlaColDesc_t" for details and an example on how to access the column data in a returned row.
ttXlaGetTableInfottXlaDecimalToCStringttXlaDateToODBCCTypettXlaTimeToODBCCTypettXlaTimeStampToODBCCType
Returns the Current Read log record identifier for the connection specified by the transaction log handle. See "How bookmarks work" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaGetLSN(ttXlaHandle_h handle, out tt_XlaLsn_t* LSN)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
LSN |
out tt_XlaLsn_t* |
The Current Read log record identifier for the handle. |
Note:
Be aware thattt_XlaLsn_t, particularly the logFile and logOffset fields, is used differently than in earlier releases, referring to log record identifiers rather than sequentially increasing LSNs. See the note in "tt_XlaLsn_t".SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example returns the Current Read log record identifier, CurLSN.
tt_XlaLsn_t CurLSN; rc = ttXlaGetLSN(xlahandle, &CurLSN);
Retrieves information about the rows in the table (refer to the description of the ttXlaTblDesc_t data type.) If the userTableID parameter is nonzero, then it is used to locate the desired table. Otherwise, the systemTableID value is used to locate the table. If both are zero, an error is returned. The description is stored in the output parameter tblinfo. This call is serialized with respect to changes in the table definition.
Requires the system privilege XLA.
SQLRETURN ttXlaGetTableInfo(ttXlaHandle_h handle, SQLUBIGINT systemTableID, SQLUBIGINT userTableID, out ttXlaTblDesc_t* tblinfo)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
systemTableID |
SQLUBIGINT |
System table ID. |
userTableID |
SQLUBIGINT |
User table ID. |
tblinfo |
out ttXlaTblDesc_t* |
Row information. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
For this example, assume the following definitions:
ttXlaTblDesc_t tabinfo; SQLUBIGINT systemTableID, userTableID;
To get table information using a system identifier, find the system table identifier using ttXlaTableByName or other means and issue the following call:
rc = ttXlaGetTableInfo(xlahandle, systemTableID, 0, &tabinfo);
Alternatively, the table information can be retrieved using a user table identifier:
rc = ttXlaGetTableInfo(xlahandle, 0, userTableID, &tabinfo);
This function is used in combination with ttXlaSetVersion to ensure XLA applications written for older versions of XLA operate on a new version. The configured version is typically the older version, while the actual version is the newer one.
The function retrieves the currently configured XLA version and stores it into configuredVersion parameter. The actual version of the underlying XLA is stored in actualVersion. Due to calls on ttXlaSetVersion, the results in configuredVersion may vary from one call to the next, but the results in actualVersion remain the same.
See "XLA persistent mode" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaGetVersion(ttXlaHandle_h handle, out ttXlaVersion_t* configuredVersion, out ttXlaVersion_t* actualVersion)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
configuredVersion |
out ttXlaVersion_t* |
The configured version of XLA. |
actualVersion |
out ttXlaVersion_t* |
The actual version of XLA. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
Assume the following directions for this example:
ttXlaVersion_t configured, actual;
To determine the current version configuration, use the following call:
rc = ttXlaGetVersion(xlahandle, &configured, &actual);
ttXlaVersionComparettXlaSetVersion
This function looks for a record in the given table with key values according to the keys parameter. The formats of the keys and result records are the same as for ordinary rows. This function requires a primary key on the underlying table.
Requires the system privilege XLA.
SQLRETURN ttXlaLookup(ttXlaHandle_h handle, ttXlaTableDesc_t* table, void* keys, out void* result, SQLINTEGER maxsize, out SQLINTEGER* retsize)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
table |
ttXlaTblDesc_t* |
The table to search. |
keys |
void* |
A record in the defined structure for the table. Only those columns of the keys record that are part of the primary key for the table are examined. |
result |
out void* |
The located record is copied into the result. If no record exists with the matching key columns, an error is returned. |
maxsize |
SQLINTEGER |
The size of the largest record that can fit into the result buffer. |
retsize |
out SQLINTEGER* |
The actual size of the record. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example looks up a record given a pair of integer key values. Before this call, table should describe the desired table and keybuffer contains a record with the key columns set.
char keybuffer[100];
char recbuffer[2000];
ttXlaTableDesc_t table;
SQLINTEGER recordSize;
rc = ttXlaLookup(xlahandle, &table, keybuffer, recbuffer,
sizeof (recbuffer), &recordSize);
ttXlaApplyttXlaCommitttXlaRollbackttXlaTableCheckttXlaGenerateSQL
This function fetches up to a specified maximum number of update records from the transaction log and returns the records associated with committed transactions to a specified buffer. The actual number of returned records is reported in the nreturned output parameter. This function requires a bookmark to be present in the database and to be associated with the connection used by the function.
When operating the transaction log in persistent mode, each call to ttXlaNextUpdate resets the bookmark to the last record read to enable the next call to ttXlaNextUpdate to return the next list of records.
See "Retrieving update records from the transaction log" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaNextUpdate(ttXlaHandle_h handle, out ttXlaUpdateDesc_t*** records, SQLINTEGER maxrecords, out SQLINTEGER* nreturned)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
records |
out ttXlaUpdateDesc_t*** |
The buffer to hold the completed transaction records. |
maxrecords |
SQLINTEGER |
Maximum number of records to be fetched. |
nreturned |
out SQLINTEGER* |
The actual number of returned records, where 0 is returned if no update data is available. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example retrieves up to 100 records and describes a loop in which each record can be processed:
ttXlaUpdateDesc_t** records;
SQLINTEGER nreturned;
SQLINTEGER i;
rc = ttXlaNextUpdate(xlahandle, &records, 100, &nreturned);
/* Check for errors; if none, process the records */
for (i = 0; i < nreturned; i++) {
process(records[i]);
}
Updates are generated for all data definition statements, regardless of tracking status. Updates are generated for data update operations for all tracked tables associated with the bookmark.
In addition, updates are generated for certain special operations, including assigning application-level identifiers for tables and columns and changing a table's tracking status.
ttXlaNextUpdateWaitttXlaAcknowledge
This is similar to the ttXlaNextUpdate function, with the addition of a seconds parameter that specifies the number of seconds to wait if no records are available in the transaction log. The actual number of seconds of wait time can be up to two seconds more than the specified seconds value.
Also see "Retrieving update records from the transaction log".
Requires the system privilege XLA.
SQLRETURN ttXlaNextUpdateWait(ttXlaHandle_h handle, out ttXlaUpdateDesc_t*** records, SQLINTEGER maxrecords, out SQLINTEGER* nreturned, SQLINTEGER seconds)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
records |
out ttXlaUpdateDesc_t*** |
The buffer to hold the completed transaction records. |
maxrecords |
SQLINTEGER |
The maximum number of records to be fetched.
Note: The largest effective value is 1000 records. |
nreturned |
out SQLINTEGER* |
The actual number of records returned, where 0 is returned if no update data is available within the seconds wait period. |
seconds |
SQLINTEGER |
Number of seconds to wait if the log is empty. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example retrieves up to 100 records and will wait for up to 60 seconds if there are no records available in the transaction log.
ttXlaUpdateDesc_t** records;
SQLINTEGER nreturned;
SQLINTEGER i;
rc = ttXlaNextUpdateWait(xlahandle, &records, 100, &nreturned, 60);
/* Check for errors; if none, process the records */
for (i = 0; i < nreturned; i++) {
process(records[i]);
}
ttXlaNextUpdatettXlaAcknowledge
Converts a TTXLA_NUMBER value to a SQLBIGINT value usable by an application.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToBigInt(void* fromData, SQLBIGINT* bint)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
bint |
SQLBIGINT* |
The SQLBIGINT value converted from the XLA number value. |
SQL_SUCCESS if successful. Otherwise, use ttXlaError to report an error.
Converts a TTXLA_NUMBER value to a character string usable by an application.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToCString(ttXlaHandle_h handle, void* fromData, char* buf, int buflen int* reslen)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
buf |
char* |
Location where the converted data is placed. |
buflen |
int |
Size of the buffer where the converted data is placed. |
reslen |
int* |
If buflen >= reslen, then reslen is the number of bytes that were written.
If |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
Converts a TTXLA_NUMBER value to a long floating point number value usable by applications.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToDouble(void* fromData, double* dbl)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
dbl |
double* |
The long floating point number value converted from the XLA number value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Converts a TTXLA_NUMBER value to a SQLINTEGER value usable by an application.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToInt(void* fromData, SQLINTEGER* ival)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
ival |
SQLINTEGER* |
The SQLINTEGER value converted from the XLA number value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Converts a TTXLA_NUMBER value to a SQLSMALLINT value usable by an application.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToSmallInt(void* fromData, SQLSMALLINT* smint)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
smint |
SQLSMALLINT* |
The SQLSMALLINT value converted from the XLA number value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Converts a TTXLA_NUMBER value to a tiny integer value usable by an application.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToTinyInt(void* fromData, SQLCHAR* tiny)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
tiny |
SQLCHAR* |
The tiny integer value converted from the XLA number value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Converts a TTXLA_NUMBER value to an unsigned integer value usable by an application.
Call this function only for a column of type TTXLA_NUMBER. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaNumberToInt(void* fromData, SQLUINTEGER* ival)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
ival |
SQLUINTEGER* |
The integer value converted from the XLA number value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Initializes a transaction log handle to a database to enable access to the transaction log in non-persistent mode. The hdbc parameter is an ODBC connection handle to a database that will be used to apply updates. Do not issue any other ODBC calls against this connection until it is closed by ttXlaClose. The handle parameter is initialized by this call and must be provided on each subsequent call that applies updates.
In non-persistent mode, only one application at a time can read from the transaction log. See "Initializing XLA in non-persistent mode" for related discussion.
Note:
Most applications should usettXlaPersistOpen to initialize XLA in persistent mode.Requires the system privilege XLA.
SQLRETURN ttXlaOpenTimesTen(SQLHDBC hdbc, out ttXlaHandle_h* handle)
| Parameter | Type | Description |
|---|---|---|
hdbc |
SQLHDBC |
The ODBC handle for the database. |
handle |
out ttXlaHandle_h* |
The transaction log handle for the database. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
The following example opens a transaction log in non-persistent mode and returns a handle named xlahandle for the ODBC connection:
SQLHDBC hdbc; ttXlaHandle_h xlahandle; rc = ttXlaOpenTimesTen(hdbc, &xlahandle);
Use of multiple threads over the same XLA handle is not recommended by TimesTen. Multithreaded applications should use ttXlaPersistOpen to create a separate XLA handle for each thread. If multiple threads must use the same XLA handle, use a mutex to serialize thread access to that XLA handle so that only one thread can execute an XLA operation at a time.
ttXlaConfigBufferttXlaStatusttXlaResetStatusttXlaClose
Converts a TTXLA_DATE value to an ODBC timestamp.
Call this function only for a column of type TTXLA_DATE. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaOraDateToODBCTimeStamp(void* fromData, TIMESTAMP_STRUCT* returnData)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
returnData |
TIMESTAMP_STRUCT* |
An ODBC timestamp value converted from the XLA Oracle DATE value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Converts a TTXLA_TIMESTAMP value to an ODBC timestamp.
Call this function only for a column of type TTXLA_TIMESTAMP. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
SQLRETURN ttXlaOraTimeStampToODBCTimeStamp(void* fromData, TIMESTAMP_STRUCT* returnData)
Requires the system privilege XLA.
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the number value returned from the transaction log. |
returnData |
TIMESTAMP_STRUCT* |
An ODBC timestamp value converted from the XLA Oracle TIMESTAMP value. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report an error.
Initializes a transaction log handle to a database to enable access to the transaction log in persistent mode. The hdbc parameter is an ODBC connection handle to a database. Create only one XLA handle for each ODBC connection. After you have created an XLA handle on an ODBC connection, do not issue any other ODBC calls over the ODBC connection until it is closed by ttXlaClose.
The tag is a string that identifies the persistent bookmark (see "About XLA bookmarks"). The tag can identify a new bookmark, either non-replicated or replicated, or one that exists in the system, as specified by the options parameter. The handle parameter is initialized by this call and must be provided on each subsequent call to XLA.
Some actions can be done without a bookmark. When performing these types of actions, you can use the XLANONE option to access the transaction log without a bookmark. Actions that cannot be done without a bookmark are the following:
In persistent mode, multiple applications can concurrently read from the transaction log. See "Initializing XLA and obtaining an XLA handle" for a discussion about using this function.
When this function is successful, XLA sets the autocommit mode to off.
If this function fails but still creates a handle, the handle must be closed to prevent memory leaks.
Requires the system privilege XLA.
SQLRETURN ttXlaPersistOpen(SQLHDBC hdbc, SQLCHAR* tag, SQLUINTEGER options, out ttXlaHandle_h* handle)
| Parameter | Type | Description |
|---|---|---|
hdbc |
SQLHDBC |
The ODBC handle for the database. |
tag |
SQLCHAR* |
The identifier for the persistent bookmark. Can be null, in which case options should be set to XLANONE. Maximum allowed length is 31. |
options |
SQLUINTEGER |
Bookmark options:
|
handle |
out ttXlaHandle_h* |
The transaction log handle returned by this call. Space is allocated by this call. User should call ttXlaClose to free space. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example opens a transaction log in persistent mode, returns a handle named xlahandle, and creates a new non-replicated bookmark named mybookmark:
SQLHDBC hdbc;
ttXlaHandle_h xlahandle;
rc = ttXlaPersistOpen(hdbc, ( SQLCHAR*)mybookmark,
XLACREAT, &xlahandle);
Alternatively, create a new replicated bookmark as follows:
SQLHDBC hdbc;
ttXlaHandle_h xlahandle;
rc = ttXlaPersistOpen(hdbc, ( SQLCHAR*)mybookmark,
XLAREPL, &xlahandle);
Multithreaded applications should create a separate XLA handle for each thread. If multiple threads must use the same XLA handle, use a mutex to serialize thread access to that XLA handle so that only one thread can execute an XLA operation at a time.
ttXlaClosettXlaDeleteBookmarkttXlaGetLSNttXlaSetLSN
This function is valid only when XLA is in non-persistent mode (which is generally discouraged).
Resets all the XLA status counters reported in the ttXlaStatus_t structure returned by ttXlaStatus. Currently, only the xlabufminfree value is reset.
Requires the system privilege XLA.
SQLRETURN ttXlaResetStatus(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
The following example resets the XLA status counters:
rc = ttXlaResetStatus(xlahandle);
ttXlaOpenTimesTenttXlaConfigBufferttXlaStatus
Rolls back the current transaction being applied on the transaction log handle. You can call this routine to respond to transient errors (timeout or deadlock) reported by ttXlaApply.
See "Handling timeout and deadlock errors" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaRollback(ttXlaHandle_h handle)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
rc = ttXlaRollback(xlahandle);
ttXlaApplyttXlaCommitttXlaLookupttXlaTableCheckttXlaGenerateSQL
Converts a ROWID value to a string value usable by applications.
Requires the system privilege XLA.
SQLRETURN ttXlaRowidToCString(void* fromData, char* buf, int buflen)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the ROWID value returned from the transaction log. |
buf |
char* |
Pointer to storage allocated to hold the converted string. |
buflen |
int |
Length of the converted string. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
char charbuf[18]; void* rowiddata; /* ... */ rc = ttXlaRowidToCString(rowiddata, charbuf, sizeof(charbuf));
Sets the Current Read log record identifier for the database specified by the transaction handle. The specified LSN value should be returned from ttXlaGetLSN. It cannot be a user-created value and cannot be earlier than the current bookmark Initial Read log record identifier.
See "About XLA bookmarks" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaSetLSN(ttXlaHandle_h handle, tt_XlaLsn_t* LSN)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
LSN |
tt_XlaLsn_t* |
The new log record identifier for the handle. |
Note:
Be aware thattt_XlaLsn_t, particularly the logFile and logOffset fields, is used differently than in earlier releases, referring to log record identifiers rather than sequentially increasing LSNs. See the note in "tt_XlaLsn_t".SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example sets the Current Read log record identifier to CurLSN.
tt_XlaLsn_t CurLSN; rc = ttXlaSetLSN(xlahandle, &CurLSN);
Sets the version of XLA to be used by the application. This version must be either the same as the version received from ttXlaGetVersion or from an earlier version.
See "XLA persistent mode" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaSetVersion(ttXlaHandle_h handle, ttXlaVersion_t* version)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
version |
ttXlaVersion_t* |
The desired version of XLA. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
To set the configured version to the value specified in requestedVersion, issue the following call:
rc = ttXlaSetVersion(xlahandle, &requestedVersion);
ttXlaVersionComparettXlaGetVersion
This function is valid only when operating XLA in non-persistent mode (which is generally discouraged).
Retrieves status information on the transaction log buffer and your XLA staging buffer and stores it in the *status parameter, which is of data type ttXlaStatus_t. This data structure includes the following:
The free and occupied space in the staging buffer
The number of transactions and records in the staging buffer
The free and occupied space in the transaction log buffer
Whether the system is accepting new transaction updates
The ttXlaStatus_t ->xlabufminfree value is the minimum number of free bytes in the transaction log buffer and is a useful statistic if you want to recalculate the optimum size of the staging buffer. As the transaction log buffer expands and contracts, xlabufminfree may no longer accurately reflect the minimum space. You can call ttXlaResetStatus, generally used to reset the value of the ttXlaStatus_t ->xlabufminfree field, to set xlabufminfree to NULL. Then, at some later time, you can call ttXlaStatus to obtain a new minimum value before calculating the optimum newSize value to pass to the ttXlaConfigBuffer function.
Requires the system privilege XLA.
ttXlaStatus(ttXlaHandle_h handle, out ttXlaStatus_t* status)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
status |
out ttXlaStatus_t* |
The current XLA status. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example gets the current XLA status:
ttXlaStatus_t s; rc = ttXlaStatus(xlahandle, &s);
ttXlaOpenTimesTenttXlaConfigBufferttXlaResetStatus
Finds the system and user table identifiers for a table or materialized view by providing the owner and name of the table or view. See "Specifying which tables to monitor for updates" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaTableByName(ttXlaHandle_h handle, char* owner, char* name, out SQLUBIGINT* sysTableID, out SQLUBIGINT* userTableID)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
owner |
char* |
The owner for the table or view as a string. |
name |
char* |
The name of the table or view. |
sysTableID |
out SQLUBIGINT* |
Where the system table ID is returned. |
userTableID |
out SQLUBIGINT* |
Where the user table ID is returned. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
To get the system and user table IDs associated with the table PURCHASING.INVOICES, use the following call:
SQLUBIGINT sysTableID;
SQLUBIGINT userTableID;
rc = ttXlaTableByName(xlahandle, "PURCHASING", "INVOICES",
&sysTableID, &userTableID);
When using XLA as a replication mechanism, this function verifies that the named table in the ttXlaTblDesc_t structure received from a master database is compatible with a subscriber database or database associated with the transaction log handle. The compat parameter indicates whether the tables are compatible.
See "Checking table compatibility between databases" for a discussion about using this function.
Requires the system privilege XLA.
SQLRETURN ttXlaTableCheck(ttXlaHandle_h handle, ttXlaTblDesc_t* table, ttXlaColDesc_t* columns, out SQLINTEGER* compat)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
table |
ttXlaTblDesc_t* |
A table description. |
columns |
ttXlaColDesc_t* |
Column description for the table. |
compat |
out SQLINTEGER* |
Returns compatibility information.
|
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example checks the compatibility of a table:
SQLINTEGER compat;
ttXlaTblDesc_t table;
ttXlaColDesc_t columns[20];
/*
* Get the desired table and column definitions into
* the variables "table" and "columns"
*/
rc = ttXlaTableCheck(xlahandle, &table, columns, &compat);
if (compat) {
/*
* Compatible
*/
}
else {
/*
* Not compatible or some other error occurred
*/
}
ttXlaApplyttXlaCommitttXlaRollbackttXlaLookupttXlaGenerateSQL
Returns the update status for a table. Identify the table by specifying either a user ID (userTableID) or a system ID (systemTableID). If userTableID is nonzero, it is used to locate the table. Otherwise systemTableID is used. If both are zero, an error is returned.
Specifying a value for newstatus sets the update status to *newstatus. A nonzero status means the table specified by systemTableID is available through XLA. Zero means the table is not tracked. Changes to table update status are effective immediately.
Updates to a table are tracked only if update tracking was enabled for the table at the time the update was performed. This call is serialized with respect to updates to the underlying table. Therefore, transactions that update the table run either completely before or completely after the change to table status.
To use ttXlaTableStatus, the user must be connected to a bookmark in persistent mode. The function reports inserts, updates, and deletes only to the bookmark that has subscribed to the table. It reports DDL events to all bookmarks. DDL events include CREATAB, DROPTAB, CREAIND, DROPIND, CREATVIEW, DROPVIEW, CREATSEQ, DROPSEQ, CREATSYN, DROPSYN, ADDCOLS, DRPCOLS, TRUNCATE, SETTBL1, and SETCOL1 transactions.
See "Specifying which tables to monitor for updates" for a discussion about using this function.
Note:
DML updates to a table being tracked through XLA will not preventttXlaTableStatus from running. However, DDL updates to the table being tracked, which take a lock on SYS.TABLES, will delay ttXlaTableStatus from running in serializable isolation against SYS.TABLES.Requires the system privilege XLA.
SQLRETURN ttXlaTableStatus(ttXlaHandle_h handle, SQLUBIGINT systemTableID, SQLUBIGINT userTableID, out SQLINTEGER* oldstatus, SQLINTEGER* newstatus)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
systemTableID |
SQLUBIGINT |
System ID of table. |
userTableID |
SQLUBIGINT |
User ID of table. |
oldstatus |
out SQLINTEGER* |
XLA old status:
|
newstatus |
SQLINTEGER* |
XLA new status:
|
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
The following examples assume that the system or user table identifiers are found using ttXlaTableByName or some other means.
Assume these declarations for the example:
SQLUBIGINT systemTableID; SQLUBIGINT userTableID; SQLINTEGER currentStatus, requestedStatus;
To find the status of a table given its system table identifier, use the following call:
/* Get system table identifier into systemTableID, then ... */
rc = ttXlaTableStatus(xlahandle, systemTableID, 0,
¤tStatus, NULL);
The currentStatus value will be nonzero if update tracking for the table is enabled, or zero otherwise.
To enable update tracking for a table given a system table identifier, set the requested status to 1 as follows:
requestedStatus = 1;
rc = ttXlaTableStatus(xlahandle, systemTableID, 0,
NULL, &requestedStatus);
You can set a new update tracking status and retrieve the current status in a single call, as in the following example:
requestedStatus = 1;
rc = ttXlaTableStatus(xlahandle, systemTableID, 0,
¤tStatus, &requestedStatus);
The above call enables update tracking for a table by system table identifier and retrieves the prior update tracking status in the variable currentStatus.
All of these examples can be done using user table identifiers as well. To retrieve the update tracking status of a table through its user table identifier, use the following call:
/* Get system table identifier into userTableID, then ... */
rc = ttXlaTableStatus(xlahandle, 0, userTableID,
¤tStatus, NULL);
Converts a TTXLA_TIME value to an ODBC C value usable by applications. See "Converting complex data types" for a discussion about using this function.
Call this function only for a column of type TTXLA_TIME. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaTimeToODBCCType (void* fromData, out TIME_STRUCT* returnData)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the time value returned from the transaction log. |
returnData |
out TIME_STRUCT* |
Pointer to storage allocated to hold the converted time. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
This example assumes you have used the offset value returned in a ttXlaColDesc_t structure to obtain a time value, pColVal, from a row returned in a transaction log record.
TIME_STRUCT time; rc = ttXlaTimeToODBCCType(pColVal, &time);
Converts a TTXLA_TIMSTAMP_TT value to an ODBC C value usable by applications. See "Converting complex data types" for a discussion about using this function.
Call this function only for a column of type TTXLA_TIMSTAMP_TT. The data type can be obtained from the ttXlaColDesc_t structure returned by the ttXlaGetColumnInfo function.
Requires the system privilege XLA.
SQLRETURN ttXlaTimeStampToODBCCType(void* fromData, out TIMESTAMP_STRUCT* returnData)
| Parameter | Type | Description |
|---|---|---|
fromData |
void* |
Pointer to the timestamp value returned from the transaction log. |
returnData |
out TIMESTAMP_STRUCT* |
Pointer to storage allocated to hold the converted timestamp. |
SQL_SUCCESS if successful. Otherwise, use ttXlaError to report the error.
This example assumes you have used the offset value returned in a ttXlaColDesc_t structure to obtain a timestamp value, pColVal, from a row returned in a transaction log record.
TIMESTAMP_STRUCT timestamp; rc = ttXlaTimeStampToODBCCType(pColVal, ×tamp);
Verifies that the cached table definitions are compatible with the XLA record being processed. Table definitions change only when the ALTER TABLE statement is used to add or remove columns.
You can monitor the XLA stream for XLA records of transaction type ADDCOLS and DRPCOLS to avoid the overhead of using this function. When an XLA record of transaction type ADDCOLS or DROPCOLS is encountered, refresh the table and column definitions. See "Inspecting record headers and locating row addresses" for information about monitoring XLA records for transaction type.
Requires the system privilege XLA.
SQLRETURN ttXlaTableVersionVerify(ttXlaHandle_h handle ttXlaTblVerDesc_t* table, ttXlaUpdateDesc_t* record out SQLINTEGER* compat)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
table |
ttXlaTblVerDesc_t* |
A cached table description. |
record |
ttXlaUpdateDesc_t* |
The XLA record that must be processed. |
compat |
out SQLINTEGER* |
Returns compatibility information.
|
SQL_SUCCESS if cached table definition is compatible with the XLA record being processed. Otherwise, use ttXlaError to report the error.
This example checks the compatibility of a table.
SQLINTEGER compat;
ttXlaTbVerDesc_t table;
ttXlaUpdateDesc_t* record;
/*
* Get the desired table definitions into the variable "table"
*/
rc = ttXlaTableVersionVerify(xlahandle, &table, record, &compat);
if (compat) {
/*
* Compatible
*/
}
else {
/*
* Not compatible or some other error occurred
* If not compatible, issue a call to ttXlaVersionTableInfo and
* ttXlaVersionColumnInfo to get the new definition.
*/
}
ttXlaVersionColumnInfottXlaVersionTableInfo
Retrieves information about the columns in a table for which a change update XLA record must be processed.
Requires the system privilege XLA.
SQLRETURN ttXlaVersionColumnInfo(ttXlaHandle_h handle, ttXlaUpdateDesc_t* record, out ttXlaColDesc_t* colinfo, SQLINTEGER maxcols, out SQLINTEGER* nreturned)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
record |
ttXlaUpdateDesc_t* |
The XLA record that must be processed. |
colinfo |
out ttXlaColDesc_t* |
A pointer to the buffer large enough to hold a description for maxcols columns. |
maxcols |
SQLINTEGER |
The maximum number of columns the table can have. If the table contains more than maxcols columns, an error is returned. |
nreturned |
out SQLINTEGER* |
The number of columns returned. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
For this example, assume the following definitions:
ttXlaHandle_h xlahandle ttXlaUpdateDesc_t* record; ttXlaColDesc_t colinfo[20]; SQLINTEGER ncols;
The following call retrieves the description of up to 20 columns:
rc = ttXlaVersionColumnInfo(xlahandle, record, colinfo, 20, &ncols);
Compares two XLA versions and returns the result.
Requires the system privilege XLA.
SQLRETURN ttXlaVersionCompare(ttXlaHandle_h handle, ttXlaVersion_t* version1, ttXlaVersion_t* version2, out SQLINTEGER* comparison)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
version1 |
ttXlaVersion_t* |
The version of XLA you want to compare with version2. |
version2 |
ttXlaVersion_t* |
The version of XLA you want to compare with version1. |
comparison |
out SQLINTEGER* |
The comparison result.
|
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
To compare the configured version against the actual version of XLA, issue the following call:
ttXlaVersion_t configured, actual;
SQLINTEGER comparision;
rc = ttXlaGetVersion (xlahandle, &configured, &actual);
rc = ttXlaVersionCompare (xlahandle, &configured, &actual,
&comparison);
When connecting two systems with XLA-based replication, use the following protocol:
At the primary site, retrieve the XLA version using ttXlaGetVersion. Send this version information to the standby site.
At the standby site, retrieve the XLA version using ttXlaGetVersion. Use ttXlaVersionCompare to determine which version is earlier. The earlier version number must be used to ensure proper operation between the two sites. Use ttXlaSetVersion to specify the version of the interface to use at the standby site. Send the earlier version number back to the primary site.
When the chosen version is received at the primary site, use ttXlaSetVersion to specify the version of XLA to use.
ttXlaGetVersionttXlaSetVersion
Retrieves the table definition for the change update record that must be processed. The table description is stored in the tableinfo output parameter.
Requires the system privilege XLA.
SQLRETURN ttXlaVersionTableInfo(ttXlaHandle_h handle, ttXlaUpdateDesc_t* record, out ttXlaTblVerDesc_t* tblinfo)
| Parameter | Type | Description |
|---|---|---|
handle |
ttXlaHandle_h |
The transaction log handle for the database. |
record |
ttXlaUpdateDesc_t* |
The XLA record that must be processed. |
tableinfo |
out ttXlaTblVerDesc_t* |
Information about table definition. |
SQL_SUCCESS if call is successful. Otherwise, use ttXlaError to report the error.
For this example, assume the following definitions:
ttXlaHandle_h xlahandle; ttXlaUpdateDesc_t* record; ttXlaTblVerDesc_t tabinfo;
The following call retrieves a table definition:
rc = ttXlaVersionTableInfo(xlahandle, record, &tabinfo);
This section describes the C data structures used by the XLA functions described in this chapter. These structures are defined in the following file:
install_dir/include/tt_xla.h
You must include this file when building your XLA application.
Table 9-1 Summary of C data structures
| C data structure | Description |
|---|---|
|
Describes the record type. Used at the beginning of records returned by XLA. |
|
|
Describes an update record. |
|
|
Describes XLA status information returned by |
|
|
Describes XLA version information returned by |
|
|
Describes table information returned by |
|
|
Describes table version returned by |
|
|
Describes table column information returned by |
|
|
Description of a log record identifier used by bookmarks. This structure is used by the |
|
|
Describes a log record identifier used by an XLA bookmark. |
Most C data structures begin with a standard header that describes the data record type and length. The standard header has the type ttXlaNodeHdr_t.
This header includes the following fields.
| Field | Type | Description |
|---|---|---|
nodeType |
char |
The type of record:
|
byteOrder |
char |
Byte order of the record.
|
length |
SQLUINTEGER |
Total length of record, including all attachments. |
This structure describes an update operation to a single row (or tuple) in the database. Each update record returned by a ttXlaNextUpdate or ttXlaNextUpdateWait function begins with a fixed length ttXlaUpdateDesc_t header followed by zero to two rows from the database. The row data differs depending on the record type reported in the ttXlaUpdateDesc_t header:
No rows are included in a COMMITONLY record.
One row is included in INSERTTUP, DELETETUP, or SETREPL records.
Two rows are included in an UPDATETUP record to report the row data before and after the update, respectively.
Special format rows are included in CREATAB, DROPTAB, CREAIND, DROPIND, CREATVIEW, DROPVIEW, CREATSEQ, DROPSEQ, CREATSYN, DROPSYN, ADDCOLS, DRPCOLS, SETTBLI, and SETCOLI records, which are described in "Special update data formats".
Note:
SETREPL, SETTBLI and SETCOLI records are not returned in persistent mode.The flags field is a bit-map of special options for the record update.
The connID field identifies the ODBC connection handle that initiated the update. This value can be used to determine if updates came from the same connection.
A separate commit XLA record is generated when a call to the ttApplicationContext procedure is not followed by an operation that generates an XLA record. See "Passing application context" for a description of the ttApplicationContext procedure.
XLA cannot receive notification of the following:
CREATE VIEW or DROP VIEW for a non-materialized view
CREATE GLOBAL TEMPORARY TABLE or DROP TABLE for a temporary table
The only XLA records that can be generated from an ALTER TABLE operation are of the following types:
ADDCOLS or DRPCOLS when columns are added or dropped
CREAIND or DROPIND when a unique attribute of a column is modified
While sequence creates (CREATESEQ) and drops (DROPSEQ) are visible through XLA, sequence increments are not.
All deletes resulting from cascading deletes and aging are visible through XLA. The flags value (discussed in the following table) indicates when deletes are due to cascading or aging.
The fields of the update header defined by ttXlaUpdateDesc_t are as follows.
| Field | Type | Description |
|---|---|---|
header |
ttXlaNodeHdr_t |
Standard data header. |
type |
SQLUSMALLINT |
Record type:
|
flags |
SQLUSMALLINT |
Special options on record update:
If the value of a specific column is 0, it indicates that column does not have a default value. The defaults for all nonzero values are concatenated in a string and are presented in order, with the array value indicating the length of the default value. For example, three columns with defaults 1 of type Decimal values for each of these TT_UPDCOMMIT 1 TT_UPDFIRST 2 TT_UPDREPL 4 TT_UPDCOLS 8 TT_UPDDEFAULT 64 TT_CASCDEL 256 TT_AGING 512 |
contextOffset |
SQLUINTEGER |
Offset to application-provided context value. This value is 0 if there is no context. A nonzero value indicates the location of the context relative to the beginning of the XLA record. |
connID |
SQLUBIGINT |
Connection ID owning the transaction. |
sysTableID |
SQLUBIGINT |
System-provided identifier of the affected table. |
userTableID |
SQLUBIGINT |
Application-defined table ID of the affected table. |
tranID |
SQLUBIGINT |
Read-only, system-provided transaction identifier. |
LSN |
tt_LSN_t |
Transaction log record identifier of this operation, used for diagnostics. |
tuple1 |
SQLUINTEGER |
Length of first row (tuple), or zero. |
tuple2 |
SQLUINTEGER |
Length of second row (tuple), or zero. |
Note:
Be aware thattt_LSN_t, particularly the logFile and logOffset fields, is used differently than in earlier releases, referring to log record identifiers rather than sequentially increasing LSNs. See the note in "tt_LSN_t".The data contained in an update record follows the ttXlaTblDesc_t header. This section describes the data formats for the special update records related to specific SQL operations.
For a CREATE TABLE operation, the special row value consists of the ttXlaTblDesc_t record describing the new table, followed by the ttXlaColDesc_t records that describe each column.
For an ALTER TABLE operation, the special row value consists of a ttXlaDropTableTup_t or ttXlaAddColumnTup_t value, followed by a ttXlaColDesc_t record that describes the column.
For a DROP TABLE operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
tblName |
char(31) |
Name of the dropped table. |
tblOwner |
char(31) |
Owner of the dropped table. |
For a TRUNCATE TABLE operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
tblName |
char(31) |
Name of the truncated table |
tblOwner |
char(31) |
Owner of the truncated table. |
For a CREATE INDEX operation, the row value is as follows.
| Field | Type | Description |
|---|---|---|
tblName |
char(31) |
Name of the table on which the index is defined. |
tblOwner |
char(31) |
Owner of the table on which the index is defined. |
ixName |
char(31) |
Name of the new index. |
flag |
char(31) |
Index flag:
|
nixcols |
SQLUINTEGER |
Number of indexed columns. |
ixColsSys |
SQLUINTEGER(16) |
Indexed column numbers using system numbers. |
ixColsUser |
SQLUINTEGER(16) |
Indexed column numbers using user-defined column IDs. |
ixType |
char |
Type of index:
|
ixUnique |
char |
Uniqueness of index:
|
pages |
SQLUINTEGER |
Number of pages for hash indexes. |
For a DROP INDEX operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
tblName |
char(31) |
Name of the table on which the index was dropped. |
tblOwner |
char(31) |
Owner of the table on which the index was dropped. |
ixName |
char(31) |
Name of the dropped index. |
For an ADD COLUMN operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
ncols |
SQLUINTEGER |
The number of additional columns. |
Following this special row are the ttXlaColDesc_t records describing the new columns.
For a DROP COLUMN operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
ncols |
SQLUINTEGER |
The number of dropped columns. |
Following this special row is an array of ttXlaColDesc_t records describing the columns that were dropped.
For a CREATE SEQUENCE operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
sqName |
char(31) |
Name of sequence. |
sqOwner |
char(31) |
Owner of sequence. |
cycle |
char |
Indicates whether the sequence number generator will continue to generate numbers after it reaches the maximum or minimum value:
|
minval |
SQLBIGINT |
Minimum value of sequence. |
maxval |
SQLBIGINT |
Maximum value of sequence. |
incr |
SQLBIGINT |
Increment between sequence numbers. Positive numbers indicate an ascending sequence and negative numbers indicate a descending sequence. In a descending sequence, the range goes from maxval to minval. In an ascending sequence, the range goes from minval to maxval. |
For a DROP SEQUENCE operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
sqName |
char(31) |
Name of sequence. |
sqOwner |
char(31) |
Owner of sequence. |
For a CREATE VIEW operation, the row value is as follows.
Note:
This applies to either materialized or non-materialized views.| Field | Type | Description |
|---|---|---|
vwName |
char(31) |
Name of view. |
vwOwner |
char(31) |
Owner of view. |
sysTableID |
SQLUBIGINT |
System table ID stored in SYS.TABLES. |
For a DROP VIEW operation, the row value is as follows.
Note:
This applies to either materialized or non-materialized views.| Field | Type | Description |
|---|---|---|
vwName |
char(31) |
Name of view. |
vwOwner |
char(31) |
Owner of view. |
For a CREATE SYNONYM operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
synName |
char(31) |
Name of synonym. |
synOwner |
char(31) |
Owner of synonym. |
objName |
char(31) |
Name of object the synonym points to. |
objOwner |
char(31) |
Owner of object the synonym points to. |
isPublic |
char |
Indicates whether the synonym is public:
|
isReplace |
char |
Indicates whether the synonym was created using CREATE OR REPLACE:
|
For a DROP SYNONYM operation, the row value is as follows:
| Field | Type | Description |
|---|---|---|
synName |
char(31) |
Name of synonym. |
synOwner |
char(31) |
Owner of synonym. |
isPublic |
char |
Indicates whether the synonym is public:
|
The description of the SET TABLE ID operation uses the previously assigned application table identifier in the main part of the update record and provides the new value of the application table identifier in the following special row.
| Field | Type | Description |
|---|---|---|
newID |
SQLUBIGINT |
The new user-defined table ID. |
The description of the SET COLUMN ID operation provides the following special row:
| Field | Type | Description |
|---|---|---|
oldUserColID |
SQLUINTEGER |
Previous user-defined column ID value. |
newUserColID |
SQLUINTEGER |
New user-defined column ID value. |
sysColID |
SQLUINTEGER |
System column ID. |
A change in a table's replication status provides the following special row.
| Field | Type | Description |
|---|---|---|
oldStatus |
SQLUINTEGER |
Previous replication status. |
newStatus |
SQLUINTEGER |
New replication status. |
See "Retrieving update records from the transaction log" and "Inspecting record headers and locating row addresses" for a detailed discussion on obtaining update records and inspecting the contents of ttXlaUpdateDesc_t headers. Below is a summary of these procedures.
The update header is immediately followed by the row data. The row data is stored in an internal format with the offsets given in the ttXlaColDesc_t structure returned by ttXlaGetColumnInfo.
You can locate the address of the row data by adding the address of the update header to its size.
For example:
char* Row = (char*)&ttXlaUpdateDesc_t +
sizeof(ttXlaUpdateDesc_t);
For UPDATETUP records, there are two rows of data following the ttXlaUpdateDesc_t header. The first row contains the data before the update, and the second row the data after the update.
Since the new row is right after the old row, you can calculate its address by adding the address of the old row to its length (tuple1).
For example:
char* oldRow = (char*)&ttXlaUpdateDesc_t +
sizeof(ttXlaUpdateDesc_t);
char* newRow = oldRow + ttXlaUpdateDesc_t.tuple1;
See "ttXlaColDesc_t" for details on how to access the column data in a returned row.
The ttXlaStatus_t structure shows runtime operational information about the XLA system. This structure is returned by the ttXlaStatus function when operating XLA in non-persistent mode.
| Field | Type | Description |
|---|---|---|
header |
ttXlaNodeHdr_t |
Standard data header. |
xlabuffree |
SQLUBIGINT |
Free bytes in the staging buffer. |
xlabufminfree |
SQLUBIGINT |
Minimum free bytes in the staging buffer. |
xlabufalloc |
SQLUBIGINT |
Allocated bytes in the staging buffer. |
xlabuftran |
SQLUBIGINT |
Number of transactions in the staging buffer. |
xlabufrec |
SQLUBIGINT |
Number of records in the staging buffer. |
logbuffree |
SQLUBIGINT |
Number of free bytes in the transaction log buffer. |
logbufminfree |
SQLUBIGINT |
Minimum free bytes in the transaction log buffer. |
logbufalloc |
SQLUBIGINT |
Number of allocated bytes in the transaction log buffer. |
flags |
SQLUINTEGER |
A bit map of status flags. Currently, only the TTXLASTAT_STALLED flag is defined. If set, this flag specifies that the XLA staging buffer is full and new updates are being rejected. |
To permit future extensions to XLA, a version structure ttXlaVersion_t describes the current XLA version and structure byte order. This structure is returned by the ttXlaGetVersion function.
This structure includes the following fields.
| Field | Type | Description |
|---|---|---|
header |
ttXlaNodeHdr_t |
Standard data header. |
hardware |
char(16) |
Name of hardware platform. |
wordSize |
SQLUINTEGER |
Native word size (32 or 64). |
TTMajor |
SQLUINTEGER |
TimesTen major version. |
TTMinor |
SQLUINTEGER |
TimesTen minor version. |
TTPatch |
SQLUINTEGER |
TimesTen point release number. |
OS |
char(16) |
Name of operating system. |
OSMajor |
SQLUINTEGER |
Operating system major version. |
OSMinor |
SQLUINTEGER |
Operating system minor version. |
Table information is portrayed through the ttXlaTblDesc_t structure. This structure is returned by the ttXlaGetTableInfo function.
This structure includes the following fields.
| Field | Type | Description |
|---|---|---|
header |
ttXlaNodeHdr_t |
Standard data header. |
tblName |
char(31) |
Name of the table, null-terminated. |
tblOwner |
char(31) |
Owner of the table, null-terminated. |
sysTableID |
SQLUBIGINT |
Unique system-defined table identifier. |
userTableId |
SQLUBIGINT |
User-defined table identifier. |
columns |
SQLUINTEGER |
Number of columns. |
width |
SQLUINTEGER |
Inline row size. |
nPrimCols |
SQLUINTEGER |
Number of primary columns. |
primColsSys |
SQLUINTEGER(16) |
System primary key column numbers. |
primColsUser |
SQLUINTEGER(16) |
User-defined primary key column numbers. |
The inline row size includes space for all fixed-width columns, null column flags, and pointer information for variable-length columns. Each varying-length column occupies four bytes of inline row space.
Note the following if the table has a declared primary key:
The nPrimCols value is greater than 0.
The primColsSys array contains the column numbers of the primary key, in the same order in which they were originally declared with the CREATE TABLE statement.
The primColsUser array contains the corresponding application-specified column identifiers.
This data structure contains the table version number and ttXlaTblDesc_t. It is returned by ttXlaVersionTableInfo. This structure includes the following fields.
| Field | Type | Description |
|---|---|---|
tblDesc |
ttXlaTblDesc_t |
Table description. |
tblVer |
SQLBIGINT |
System-generated table version number. |
Column information is given through this structure, which is returned by the ttXlaGetColumnInfo function.
The structure includes the following fields.
| Field | Type | Description |
|---|---|---|
header |
ttXlaNodeHdr_t |
Standard data header. |
colName [tt_NameLenMax] |
char |
Name of the column. |
pad0 |
SQLUINTEGER |
Pad to four-byte boundary. |
sysColNum |
SQLUINTEGER |
Ordinal number of the column as specified when the table is created or subsequently altered. It is the same as the corresponding COLNUM value in SYS.COLUMNS. (See "SYS.COLUMNS" in Oracle TimesTen In-Memory Database System Tables and Limits Reference.) |
userColNum |
SQLUINTEGER |
This is 0 or a column number optionally specified by the user through the ttSetUserColumnID TimesTen built-in procedure. (See "ttSetUserColumnID" in Oracle TimesTen In-Memory Database Reference.) |
dataType |
SQLUINTEGER |
Structure in ODBC TTXLA_* code.
|
size |
SQLUINTEGER |
Maximum or basic size of column. |
offset |
SQLUINTEGER |
Offset to fixed-length part of column. |
nullOffset |
SQLUINTEGER |
Offset to null byte; zero if not nullable. |
precision |
SQLSMALLINT |
Numeric precision for decimal types. |
scale |
SQLSMALLINT |
Numeric scale for decimal types. |
flags |
SQLUINTEGER |
Column flag:
|
The procedures for obtaining a ttXlaColDesc_t structure and inspecting its contents are described in "Inspecting column data". Below is a summary of these procedures.
The ttXlaColDesc_t structure is returned by the ttXlaGetColumnInfo function. This structure contains the metadata needed to access column information in a particular table. For example, you can use the offset field to locate specific column data in the row or rows returned in an update record after the ttXlaColDesc_t structure. By adding the offset to the address of a returned row, you can locate the address to the column value. You can then cast this value to the corresponding C types according to the dataType field, or pass it to one of the conversion routines described in "Converting complex data types".
TimesTen row data consists of fixed-length data followed by any variable-length data.
For fixed length column data, ttXlaColDesc_t returns the offset and size of the column data. The offset is relative to the beginning of the fixed part of the record. See Example 9-1 below.
For variable-length column data (VARCHAR and VARBINARY), offset is an address that points to a four-byte offset value. By adding the offset address to the offset value, you can obtain the address of the column data in the variable-length portion of the row. The first n bytes at this location is the length of the data, followed by the actual data (where n is 4 on 32-bit platforms or 8 on 64-bit platforms). For variable-length data, the returned size value is the maximum allowable column size. See Example 9-1 below.
For columns that can have null values, nullOffset points to a null byte in the record. This value is 1 if the column is null, or 0 if it is not null. See "Detecting null values" for a discussion.
The flags bits define whether the column is nullable, part of a primary key, or stored out of line.
The sysColNum value is the system column number to assign to the column. This value begins with 1 for the first column.
Example 9-1 Copying and printing a VARCHAR string
For fixed-length column data, the address of a column is the offset value in the ttXlaColDesc_t structure, plus the address of the row as follows:
ttXlaColDesc_t colDesc; void* pColVal = colDesc->offset + row;
The value of the column can be obtained by dereferencing this pointer using a type pointer that corresponds to the data type. For example, for SQL_INTEGER, the ODBC type is SQLINTEGER and the value of the column can be obtained by the following:
*((SQLINTEGER*) pColVal))
In the case of variable-length column data, the pColVal calculated above is the address of a four-byte offset value. Adding this offset value to the address of pColVal provides a pointer to the beginning of the variable-length column data. Assuming the operation is performed on a 64-bit platform, the first eight bytes at this location is the length of this data (var_len), followed by the actual data (var_data).
In this example, a VARCHAR string is copied and printed.
tt_ptrint* var_len = (tt_ptrint*)((char*)pColVal +
*((int*)pColVal));
char* var_data = (char*)(var_len+1);
char* buffer = malloc(*var_len+1);
memcpy(buffer,var_data,*var_len);
buffer[*var_len] = (char)NULL; /* NULL terminate the string */
printf("%s\n",buffer);
free(buffer);
Description of log record identifier used by bookmarks. This structure is used by the ttXlaUpdateDesc_t structure.
| Field | Type | Description |
|---|---|---|
logFile |
SQLUBIGINT |
Higher order portion of log record identifier. |
logOffset |
SQLUBIGINT |
Lower order portion of log record identifier. |
Note:
ThelogFile and logOffset field names are retained for backward compatibility, although their usage has changed. In previous releases the values referred to LSNs, which increased sequentially, and the values had very specific meanings, indicating the log file number plus byte offset. Now they refer to log record identifiers, which are more abstract and do not have a direct relationship to the log file number and byte offset. All you can assume about a sequence of log record identifiers is that a log record identifier B read at a later time than a log record identifier A will have a higher value.Description of a log record identifier used by bookmarks. This structure is returned by the ttXlaGetLSN function and used by the ttXlaSetLSN function.
The checksum is specific to an XLA handle to ensure that every log record identifier is related to a known XLA connection.
| Field | Type | Description |
|---|---|---|
checksum |
SQLUINTEGER |
Checksum used to ensure that it is a valid log record identifier handle. |
xid |
SQLUSMALLINT |
Transaction ID. |
logFile |
SQLUBIGINT |
Higher order portion of log record identifier. |
logOffset |
SQLUBIGINT |
Lower order portion of log record identifier. |
Note:
ThelogFile and logOffset field names are retained for backward compatibility, although their usage has changed. In previous releases the values referred to LSNs, which increased sequentially, and the values had very specific meanings, indicating the log file number plus byte offset. Now they refer to log record identifiers, which are more abstract and do not have a direct relationship to the log file number and byte offset. All you can assume about a sequence of log record identifiers is that a log record identifier B read at a later time than a log record identifier A will have a higher value.