| Oracle® Services for Microsoft Transaction Server Developer's Guide 10g Release 1 (10.1) for Windows Part Number B10114-01 |
|
|
View PDF |
| Oracle® Services for Microsoft Transaction Server Developer's Guide 10g Release 1 (10.1) for Windows Part Number B10114-01 |
|
|
View PDF |
This chapter describes how to program with Microsoft Transaction Server and an Oracle database.
This chapter contains these topics:
The focal point of the transaction process is a component of Microsoft Transaction Server called Microsoft Distributed Transaction Coordinator (MS DTC). When a client computer starts a business method on a transactional component, Microsoft Transaction Server begins a transaction coordinated by the MS DTC. The Oracle connection pooling layer enables the database to act as a resource manager (RM) in the MS DTC-coordinated transaction. Figure 5-1 and Table 5-1 provide an overview of how these and other components perform a transaction.
Table 5-1 Component Integration in a Transaction
| Component | Major Responsibilities |
|---|---|
| Client computer connection |
|
| Transactional application logic COM components | Embed the business logic (If the component is transactional, Microsoft Transaction Server starts a transaction for every method invocation on that component.)
Acquire pooled connections to a Oracle database through the Oracle resource dispenser and Oracle Call Interface (OCI), Oracle Open Database Connectivity (ODBC) Driver, Oracle Provider for OLE DB, or Oracle Objects for OLE (OO4O) Decide the outcome of the operation by notifying Microsoft Transaction Server of its decision to commit or terminate the changes to all RMs. |
| Oracle ODBC Driver, OO4O, Oracle Provider for OLE DB, and OCI | Obtain a service context to the Oracle database through the OCI connection pooling componentProvide connection pooling resources, if necessary (through Oracle Provider for OLE DB or Oracle ODBC Driver). The Oracle ODBC Driver provides pooled ODBC connections. Oracle Provider for OLE DB provides pooled data source objects. OO4O uses the OCI connection pool. |
| OCI connection pool | Performs the following for transaction components:Enlists the RM (Oracle database) in the component's Microsoft Transaction Server transactionStarts an Oracle global transaction corresponding to the Microsoft Transaction Server transaction of which the component is a partActs as a resource dispenser to perform client-side connection pooling |
| Oracle MTS Recovery Service |
Recovers Microsoft Transaction Server-related, in-doubt Oracle transactions that originated from the host computer |
| MS DTC (part of Microsoft Transaction Server) | Commits and terminates transactions using the two-phase commit protocolMonitors transactions that require recovery. Multiple MS DTCs can be involved in a single transaction. When a transactional Microsoft Transaction Server component on computer A invokes another transactional Microsoft Transaction Server component on computer B, a connection is opened between the MS DTC on computer A and the MS DTC on computer B. When the root MS DTC commits or terminates a transaction, it sends the request through all involved MS DTCs. The transaction request is then passed to the OCI connection pooling/Microsoft Transaction Server integration, which sends it to the database. |
| Oracle Database | Acts as an RM for Microsoft Transaction Server. This is the database on which the client transaction request is performed. |
Regardless of the application program interface (API) you use, OCI connection pooling is used in nearly all cases to coordinate a transaction. Review the following sections for information about how a transaction is registered and how OCI connection pooling coordinates the transaction:
Microsoft Transaction Server Component Registration Overview
Microsoft Transaction Server-Coordinated Component Transaction Overview
Application components that run in the Microsoft Transaction Server environment are created as dynamic link libraries (DLLs). Application components are registered with Microsoft Transaction Server using the Microsoft Transaction Server Explorer graphical user interface (GUI) tool. When you register the application component, you mark it as one of the types described in Table 5-2.
Table 5-2 Microsoft Transaction Server Component Registration
| Type | The Component... |
|---|---|
| Requires a transaction | Must run in a transaction. If the transaction does not currently exist, Microsoft Transaction Server automatically creates a new transaction for each method invocation on the component. |
| Requires a new transaction | Must run within their own transaction. Microsoft Transaction Server automatically creates a new transaction for each method invocation on the component. |
| Supports transactions | Can run within the client's transaction. When a new component is created, its context inherits the transaction from the context of the invoking client. If the client does not have a transaction, the new context is also created without one. |
| Does not support transactions | Does not run within a transaction. Each method invocation on the component is performed without a surrounding transaction, regardless of whether the invoking client includes a transaction. |
How you register an application component determines if it runs in a Microsoft Transaction Server-coordinated transaction. Table 5-3 describes this process.
Table 5-3 Running Components in a Microsoft Transaction Server Transaction
| If the Application Component... | Then... |
|---|---|
| Runs in a Microsoft Transaction Server-coordinated transaction | OCI connection pooling is always used and Microsoft Transaction Server and its MS DTC component coordinate the creation, startup, management, and commitment phases of the transaction. Microsoft Transaction Server ensures that all changes made by the component are committed if the transaction succeeds, or are terminated if the transaction fails.
See Also: "Microsoft Transaction Server-Coordinated Component Transaction Overview" |
| Does not run in a Microsoft Transaction Server-coordinated transaction | The component runs in a Microsoft Transaction Server environment, but the databases that it accesses may or may not take part in MS DTC-coordinated transactions. If the transaction is not MS DTC-coordinated, the client application must create, start, manage, and commit the transaction. OCI connection pooling may be used, depending upon the interface accessing the database (such as Oracle Provider for OLE DB, Oracle ODBC Driver, OO4O, or others).
See Also: "MS DTC-Coordinated Component Transaction Overview" |
This section describes how OCI connection pooling, Microsoft Transaction Server, and MS DTC operate with application components in a Microsoft Transaction Server-coordinated transaction environment.
The client API being used (Oracle ODBC Driver, OCI, OO4O, ODP.NET or Oracle Provider for OLE DB) calls OCI function OraMTSSvcGet() to obtain a service context from the OCI connection pooling component.
The OCI connection pooling component enlists the transaction, which is to be coordinated by the MS DTC component of Microsoft Transaction Server.
These actions return OCI service and environment handles to client applications.
The client application:
Performs the database operations.
Calls OCI function OraMTSSvcRel() to release the OCI pooling connection obtained at the beginning of the transaction.
Calls SetComplete (to commit database operations) or SetAbort (to terminate database operations) on the Microsoft Transaction Server context object associated with the component.
MS DTC performs the two-phase commit protocol to prepare and commit (or terminate) the transaction, which notifies the OCI connection pooling component and ends the transaction.
OCI connection pooling is notified and performs the necessary steps to complete phase one (the prepare phase) and phase two (the commit or abort phase).
This section describes how OCI connection pooling, Microsoft Transaction Server, and MS DTC operate with application components not running in a Microsoft Transaction Server-coordinated transaction, but using MS DTC.
The client application starts an MS DTC transaction and connects to the Oracle database. This is either a:
Nonpooled OCI connection obtained through OCI logon calls (for example, OCIServerAttach() and OCISessionBegin()). For these connections, the application calls OraMTSEnlCtxGet() to associate the OCI service context with an Microsoft Transaction Server enlistment context.
Connection pool obtained by calling OraMTSSvcGet(..,..,ORAMTS_CFLG_NOIMPLICIT), and not yet released with OraMTSSvcRel()
For nonpooled connections, the client application passes in the enlistment context to OraMTSJoinTxn().
For pooled connections, the client application passes the OCI service context into OraMTSSvcEnlist().
The OCI connection pooling component enlists the connection (pooled or nonpooled) in the transaction coordinated by the MS DTC component of Microsoft Transaction Server.
The client application:
Performs database operations.
Calls OraMTSSvcEnlist() with a NULL transaction reference to de-enlist from an MS DTC coordinated transaction. For nonpooled connections, OraMTSTxnJoin() is invoked with a NULL transaction reference to perform the de-enlistment.
Calls OraMTSSvcRel() to release a pooled connection back to the pool. For nonpooled connections, the client calls OraMTSEnlCtxRel() to release the enlistment context and then logs off the database.
Calls the commit or abort method on the MS DTC transaction object (for example, pTransaction->Commit() or pTransaction->Abort()).
MS DTC performs the two-phase commit protocol to commit the transaction.
OCI connection pooling is notified and performs the necessary steps to complete phase one (the prepare phase) and phase two (the commit or abort phase).
The following OCI functions enable you to integrate the OCI client application with Microsoft Transaction Server and a Oracle database. Review the following sections for information about this integration:
The only code change to make is in obtaining and releasing the OCI service context handle. An OCI service context handle and environment handle are acquired when you obtain a pooled OCI connection to the database with the OCI function OraMTSSvcGet(). Include the oramts.h header and link with the oramts.lib library. When you are finished, call OCI function OraMTSSvcRel() to release the service context handle and environment handle. Using OraMTSSvcGet() enables you to receive connection pooling and implicit transaction support (if you registered the application component to run in a Microsoft Transaction Server transaction).
In releases prior to 9.0, OraMTSSvcEnlist() and OraMTSSvcEnlistEx() enlisted nonpooled OCI connections in Microsoft Transaction Server transactions. This is no longer supported. These functions are still available to enlist pooled connections in MS DTC-coordinated transactions. To enlist nonpooled OCI connections in Microsoft Transaction Server-started and MS DTC-coordinated transactions, the client must use OraMTSJoinTxn().
Ensure that for each process, you call OCIInitialize at least once before executing any other OCI calls. This initializes the OCI process environment. In addition, you must pass it the OCI_THREADED flag. If you are using Microsoft Internet Information Server (IIS) and the components are being called as in-process libraries, then OCIInitialize is already called for you. The registry key ORAMTS_OCI_OBJ_MODE has been added. Set the value to 1 to initialize OCI in Object mode; otherwise OCI will initialize in the threaded mode.
#include <oci.h>
#include <oramts.h>
#include <xolehlp.h>
// other MTS relevant includes ...
// prototype for the error handler.
BOOL Chekerr(sword swOCIStat, OCIError *OCIErrh);
// MTS component method
HRESULT OCITestMethod()
{
IObjectContext *pObjectContext = NULL;
OCIEnv *myenvh = NULL;
OCISvcCtx *mysvch = NULL;
OCIError *myerrh = NULL;
OCIStnt *mystmh = NULL;
DWORD dwStat;
HRESULT hRes = S_OK;
sword swOCIStat;
BOOL bCommit = FALSE;
char *lpzStmt = "UPDATE EMP SET SAL = SAL + 1000";
// Initialize the OCI environment first -- request OCI_THREADED
OCIInitialize(OCI_THREADED, (dvoid*)NULL,NULL,NULL,NULL);
// attempt to get a connection to the database through the resource dispenser
OraMTSSvcGet(
"hr","hr_password","finprod_db",&mysvch, &myenvh, ORAMTS_CFLG_ALLDEFAULT);
// validate return status
if(dwStat != ORAMTS_ERR_NOERROR)
{
printf("error: failed to obtain a connection to the database - %ld",
dwStat);
goto cleanup;
}
// successful logon and enlistment in the MTS transaction. allocate statement
// handles and other handles using the OCI environment handle myenvh ....
swOCIStat = OCIHandleAlloc(myenvh, (void *)&myerrh,OCI_HTYPE_ERROR, 0 , NULL);
if (Checkerr(swOCIStat, myerrh)) goto cleanup;
swOCIStat = OCIHandleAlloc(myenvh, (dvoid *)&mystmh,OCI_HTYPE_STMT, 0,NULL);
if (Checkerr(swOCIStat, myerrh)) goto cleanup;
// prepare a DML statement
OCIStmtPrepare(mystmh, myerrh, lpzStmt, lstrlen(lpzStmt), OCI_NTV_SYNTAX,
OCI_DEFAULT)
Checkerr(swOCIStat, myerrh);
// execute the statement -- ensure that AUTOCOMMIT is not requested.
OCIStmtExecute(mysvch, mystmh, myerrh, 1, 0, NULL, NULL, OCI_DEFAULT);
if (Checkerr(swOCIStat, myerrh)) goto cleanup;
// all's well so far choose to go for a commit
bCommit = TRUE;
cleanup:
if (mystmh) OCIHandleFree((void*)mystmh, OCI_HTYPE_STMT);
if (myerrh OCIHandleFree((void*)myerrh, OCI_HTYPE_ERROR);
if (mysvch) OraMTSSvcRel(mysvch);
if (bCommit)
pObjectContext->SetComplete();
else
pObjectContext->Abort();
return(bCommit ? S_OK : E_FAIL);
}
Figure 5-2 provides a high-level overview of how to use the OCI functions OraMTSSvcGet(), OraMTSSvcRel(), and OraMTSJoinTxn.
COM applications not hosted by the Microsoft Transaction Server environment (also known as standalone applications) can also use methods 2, 3, and 4 in Figure 5-2. However, these application types cannot use declarative transactions (through the Microsoft Transaction Server Explorer Microsoft Management Console).
OraMTSSvcGet() obtains a pooled connection (also known as an OCI service context) from the OCI connection pool. The pooled connection includes an OCI service context handle and OCI environment handle.
DWORD OraMTSSvcGet(
text* lpUname,
text* lpPsswd,
text* lpDbnam,
OCISvcCtx** pOCISvc,
OCIEnv** pOCIEnv,
ub4 dwConFlgs
);
Table 5-4 describes the OraMTSSvcGet() parameters. Table 5-5 describes the possible connections flags for the ub4 datatype.
Table 5-4 OraMTSSvcGet() Parameters
| Datatype | Parameter | Description |
|---|---|---|
text* |
lpUname(IN) |
Username for connecting to the Oracle database |
text* |
lpPsswd(IN) |
Password for the username |
text* |
lpDbnam(IN) |
The net service name for connecting to the database (created with Oracle Net Manager or Oracle Net Configuration Assistant) |
OCISvcCtx** |
pOCISvc(OUT) |
Pointer to the OCI service context handle |
OCIEnv** |
pOCIEnv(OUT) |
Pointer to the OCI environment handle |
ub4 |
dwConFlgs(IN) |
Connection flags. Possible values are represented in Table 5-5. |
Table 5-5 Possible Connection Flags for ub4 Datatype
Returns ORAMTSERR_NOERROR upon successful acquisition of an OCI pooling connection (OCI service context).
OraMTSSvcGet() returns a pooled OCI connection to the caller, enabling a database transaction using OCI to begin. Use OraMTSSvcGet() to implicitly enlist the OCI connection in a transaction coordinated by Microsoft Transaction Server. In this type of transaction, Microsoft Transaction Server controls the creation, startup, management, and commitment phases of the transaction through its MS DTC component.
OraMTSSvcGet() also provides connection pooling without enlisting the Oracle database in a Microsoft Transaction Server transaction. This is done by setting OraMTSSvcGet() as follows:
OraMTSSvcGet(...,ORAMTS_CFLG_NOIMPLICIT)
In all cases where OraMTSSvcGet() is used, you must always use OraMTSSvcRel() to release the connection when finished.
Use the flags ORAMTS_CFLG_SYSDBALOGN and ORAMTS_CFLG_SYSOPRLOGN when connecting as SYSDBA and SYSOPER, respectively.
To obtain a nonenlisted connection using the hr/hr_password account, call OraMTSSvcGet() as follows:
OraMTSSvcGet("hr", "hr_password", "oracle", &OCISvc, &OCIEnv, ORAMTS_CFLG_ALLDEFAULT | ORAMTS_CFLG_NOIMPLICIT);
OraMTSSvcGet() does not support placing the username (lpUname), password (lpPsswd), and net service name syntax (lpDbname) together in the username argument (for example, hr/hr_password@prod_fin). Instead, the caller must fill in lpUname, lpPsswd, and lpDbname separately (as shown in the previous syntax example). Calling OraMTSSvcGet() with the username and password as NULL strings uses external authentication (operating system authentication) for the connection.
OraMTSSvcRel() releases a pooled OCI connection (OCI service context) back to the connection pool. Use OraMTSSvcRel() to release connections that were acquired with OraMTSSvcGet().
An OCI pooled connection obtained through a previous call to OraMTSSvcGet() is released back to the connection pool. Once released back to the connection pool, the OCI service context, its environment handle, and all child handles are invalid.
A nontransactional client component must explicitly call OCITransCommit() or OCITransAbort() prior to releasing a connection obtained through OraMTSSvcGet(…,…,ORAMTS_CFLG_ALLDEFAULT) back to the pool. Otherwise, all changes made in that session are rolled back. A transaction component uses the SetComplete or SetAbort methods on its Microsoft Transaction Server object context.
Components that have called OraMTSSvcGet(…,…,ORAMTS_CFLG_NOIMPLICIT) to obtain a connection resource must first de-enlist the resource if enlisted. If the connection was enlisted explicitly, pTransaction->Commit() or pTransaction->Abort() must be called. Otherwise, OCITransCommit() or OCITransAbort() must be called before releasing the connection back to the pool.
OraMTSSvcEnlist() enlists or de-enlists an OCI connection in a transaction coordinated by MS DTC. Use this call to explicitly enlist pooled connections. Nonpooled connections must enlist with OraMTSJoinTxn().
DWORD OraMTSSvcEnlist(
OCISvcCtx* OCISvc,
OCIError* OCIErr,
void* lpTrans,
unsigned dwFlags
);
Table 5-7 describes the OraMTSSvcEnlist() parameters.
Table 5-7 OraMTSSvcEnlist() Parameters
Use this call to explicitly enlist or de-enlist a pooled connection. For enlisting and de-enlisting nonpooled connections, use OraMTSSvcRel().
OraMTSSvcEnlist() enlists (or de-enlists) pooled OCI connections obtained previously through OraMTSSvcGet() with the ORAMTS_CFLG_NOIMPLICIT flag and not yet released with OraMTSSvcRel(). The pooled OCI connections must be explicitly enlistable. When the transaction is complete, you must de-enlist OraMTSSvcEnlist(), passing NULL as the transaction pointer as follows:
OraMTSSvcEnlist(OCISvc,OCIErr,NULL,ORAMTS_ENFLG_DEFAULT)
You must use OraMTSSvcRel() to release the connection when done.
Callers must:
Allocate a connection.
Enlist the connection.
Perform work.
De-enlist the connection.
Release the connection.
Attempt to commit or abort.
OraMTSSvcEnlistEx() enlists an OCI connection or service context in an MS DTC transaction. Use this call only to explicitly enlist pooled connections. Nonpooled connections must enlist with OraMTSJoinTxn().
DWORD OraMTSSvcEnlistEx(
OCISvcCtx* OCISvc,
OCIError* OCIErr,
void* lpTrans,
unsigned dwFlags,
char* lpDBName
);
Table 5-8 describes the OraMTSSvcEnlistEx() parameters.
Table 5-8 OraMTSSvcEnlistEx() Parameters
OraMTSEnlCtxGet() creates an enlistment context for a nonpooled OCI connection.
DWORD OraMTSEnlCtxGet(
text* lpUname,
text* lpPsswd,
text* lpDbnam,
OCISvcCtx* pOCISvc,
OCIError* pOCIErr,
ub4 dwFlags,
void** pCtxt
);
Table 5-9 describes the OraMTSEnlCtxGet() parameters.
Table 5-9 OraMTSEnlCtxGet() Parameters
| Datatype | Parameter | Description |
|---|---|---|
text* |
lpUname(IN) |
Username for connecting to the Oracle database |
text* |
lpPsswd(IN) |
Password for connecting to the Oracle database |
text* |
lpDbnam(IN) |
Net service name for connecting to a database |
OCISvcCtx* |
pOCISvc(IN) |
OCI service context for a nonpooled connection |
OCIError* |
pOCIErr(IN) |
OCI error handle |
ub4 |
dwFlags(IN) |
Enlistment flags. The only value currently permitted is 0. |
void** |
pCtxt(OUT) |
Enlistment context to be created |
This call sets up an enlistment context for a nonpooled connection. This call must be started just after the caller establishes the OCI connection to the database. Once created, this context can be passed into OraMTSJoinTxn() calls. Prior to deleting the OCI connection, OraMTSEnlCtxRel() must be called to delete the enlistment context.
Callers must:
Allocate a nonpooled connection through OCI.
Create an enlistment context by calling OraMTSEnlCtxGet().
Enlist the connection by calling OraMTSJoinTxn().
Perform database work.
De-enlist the connection by calling OraMTSJoinTxn() with a NULL transaction pointer.
Attempt to commit or terminate work.
Release the enlistment context by calling OraMTSEnlCtxRel().
Release the nonpooled OCI connection and delete its associated OCI environment handle.
OraMTSEnlCtxRel() eliminates a previously set up enlistment context for a nonpooled OCI connection.
Before dropping a nonpooled OCI connection, a client must call OraMTSEnlCtxRel() to eliminate any enlistment context it may have created for that connection. The enlistment context can maintain OCI handles allocated off the connection's OCI environment handle. This makes it imperative that the environment handle is not deleted for the associated enlistment context.
OraMTSJoinTxn() enlists a nonpooled OCI connection in an MS DTC transaction.
Clients use this call with nonpooled OCI connections to enlist connections in MS DTC-coordinated transactions. The client passes in the wide reference to the enlistment context representing the OCI connection, along with a reference to an MS DTC transaction object. If pTrans is NULL, the OCI connection is de-enlisted from any MS DTC transaction in which it is currently enlisted. You can enlist a previously-enlisted OCI connection in a different MS DTC transaction.
OraMTSTransTest() tests if you are running inside a Microsoft Transaction Server-started transaction.
Returns true if running inside a Microsoft Transaction Server transaction. Otherwise, false is returned.
Microsoft Transaction Server transactional components use OraMTSTransTest() to check if a component is running within the context of a Microsoft Transaction Server transaction. Note that this call can only test Microsoft Transaction Server-started transactions. Transactions started by directly calling the MS DTC are not detected.
OraMTSOCIErrGet() retrieves the OCI error code and message text (if any) from the last OraMTS function operation, typically OraMTSSvcGet() or OraMTSJoinTxn().
Returns true if an OCI error is encountered. Otherwise, false is returned. If true is returned and lpcEMsg and lpdLen are valid, and there is a stashed error message, up to lpdLen bytes are copied into lpcEMsg. lpdLen is set to the actual number of message bytes.
OraMTSOCIErrGet() retrieves the OCI error code and OCI error message text, if any, from the last OraMTSSvc operation on this thread. For example:
DWORD dwStat = OraMTSSvcGet("hr", "invalid_password","fin_prod",db",&mysvch, &myenvh, ORAMTS_CFLG_ALLDEFAULT);
if (dwStat != ORAMTS_ERR_NOERROR)
{
DWORD dwOCIErr;
char errBuf[MAX_PATH];
DWORD errBufLen = sizeof(effBuf);
if (OraMTSOCIErrGet(&dwOCIErr, &errBuf, &errBufLen))
printf("OCIError %d: %s"\n);
}
This section describes how to use Oracle ODBC Driver with Microsoft Transaction Server and a Oracle database. Specific topics discussed are:
Using Oracle ODBC Driver (recommended)
OCI connection pooling operates as described in "Microsoft Transaction Server Application Development Overview", with no changes to OCI code required for ODBC to operate.
To use Microsoft Transaction Server with either Oracle ODBC Driver 10.1 or Microsoft Oracle ODBC driver, you must set the connection attribute. Use the function SQLSetConnectAttr to call the parameter SQL_ATTR_ENLIST_IN_DTC in the ODBC code. This enables you to receive connection pooling and implicit transaction support.
|
See Also: "Setting Up MTS to Access Oracle" in the Microsoft Transaction Server online Help for instructions. |
The ODBC Driver Manager distributed with ODBC 3.0 is a Resource Dispenser that supports connection pooling. Oracle ODBC Driver release 10.1 integrates with the ODBC 3.0 Driver Manager by supporting the SQLSetConnectAttr(...,..., SQL_ATTR_ENLIST_IN_DTC) call to enlist or de-enlist the ODBC connection in or from MS DTC-coordinated transactions.
|
See Also: Microsoft Transaction Server SDK for information |
Use the Oracle ODBC Driver 10.1 with:
Applications you develop
The sample banking application that Microsoft provides with Microsoft Transaction Server.
To configure Oracle ODBC Driver:
Choose Start > Settings > Control Panel.
The Control Panel window appears.
Double-click ODBC.
The ODBC Data Source Administrator dialog box appears.
Choose the File DSN tab.
To make Oracle ODBC Driver work with Microsoft sample banking application demo, follow Substeps 4` through 4d. Otherwise, go to Step 5.
Back up Microsoft mtssamples.dsn file. This file is located in ROOTDRIVE:\program files\common files\odbc\data sources.
Click Yes when prompted.
This deletes the configuration file that enables the Microsoft Transaction Server sample application demo to use the Microsoft ODBC driver.
Go to step 5.
Click Add to create a new File data source name (DSN).
The Create New Data Source wizard appears.
Select Oracle in HOME_NAME.
Click Advanced.
Add the following information in the keywords and values field:
SERVER=database_alias USERNAME=hr PASSWORD=hr_password
The following table describes the keywords and values.
| Where... | Is... |
|---|---|
SERVER |
The database alias used by the demo to access the database (mtsdemo) |
USERNAME |
hr (database username for this application) |
PASSWORD |
hr_password (database password for username hr, unless you changed it) |
|
Note: Verify that thehr schema contains the account and receipt tables. |
Click OK.
Click Next to continue with the Create New Data Source wizard.
Review the following table and enter the name of the file DSN to which to save this connection information:
| If Using Oracle's ODBC For... | Then Enter... |
|---|---|
| Microsoft sample application | mtssamples.dsn (Microsoft ODBC name). This name must exactly match the name you removed in Substep 4b. |
| Applications you develop | Any appropriate name |
Complete the remaining Create New Data Source wizard pages.
Click OK to exit the ODBC Data Source Administrator dialog box.
Exit the Control Panel window.
If the database release is 8.0.5 or earlier, you cannot use the integration information described in this chapter. However, there is a solution if you use the Microsoft Oracle ODBC driver. No other APIs are supported.
You can use the Microsoft Oracle ODBC Driver included in Windows NT Option Pack 4 to enable applications to interact with Microsoft Transaction Server and a Oracle database. If you use this driver, the rest of the information in this chapter does not apply and you do not receive the following:
Performance benefits
Other API support of Oracle integration
Oracle client support
|
See Also: "Setting Up MTS to Access Oracle" in the Microsoft Transaction Server online Help for instructions on enabling Microsoft Oracle ODBC Driver |
After enabling Microsoft's Oracle ODBC Driver perform these additional steps:
To configure Microsoft's Oracle ODBC Driver:
Install Oracle Required Support Files (RSF) release 10.1 and SQL*Net 2.3 or later on the computer where Microsoft's Oracle ODBC Driver is operating.
Run the ORACLE_BASE\ORACLE_HOME\oramts\samples\ sql\omtssamp.sql script.
Use SQL*Net Easy Config to set up a database alias connection. This is the alias that the mtssamples.dsn file uses.
If you installed the release 10.1 RSFs in a home with Oracle Net installed, be sure to set the following registry parameter at HKEY_LOCAL_MACHINE\ SOFTWARE\ORACLE:
ORAOCI = ORA73.DLL
Oracle Services for Microsoft Transaction Server provides integration with OO4O, Oracle Provider for OLE DB, and Oracle Data Provider for .NET.
|
See Also:
|
|
 Copyright © 1996, 2003 Oracle Corporation All Rights Reserved. |
|