Access Oracle from BSP

Question

Hi all,
My requirement is to access some values from the oracle database table residing on a different server and display them in a BSP page.
I think the connection to oracle is possible from an ABAP class.I am not really sure of how do we connect to an external database from ABAP.
If anyone has done something like this before, it would be great if they help me out in this regard.
Thanks in advace.
Vivek

Answer 1

Hi Vivek,
I found this help in my SAP-GUI. Could not find the same information in help.sap.com
Hope it helps.
<b>Secondary Database Connections with Open SQL</b>
You can use the CONNECTION addition to execute Open SQL commands on databases other than the R/3 standard database. This gives you a number of possibilities, for example you can transfer and update data in other databases, irrespective of whether the other system is an R/3 System or not. However, it is a prerequisite that it is a database system supported by SAP, because only in such a system is the software needed for an Open SQL access available in form of a shared library.
<b>Note</b>
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
<b>Setting Up a Secondary Database Connection</b>
To a access another database you need an entry in the table DBCON that describes the access data of the database. If the secondary database is from a different manufacturer than the R/3 System database, you will need the SAP shared library as well as the client software provided by the manufacturer. How to create the DBCON entry and install the additional software is described in the standard SAP Notes for every for every supported database system.
<b>Standard Database Connection</b>
Every work process has a standard database connection to the R/3 standard database. It is communally used by all internal sessions. You can also explicitly access this database connection using the name DEFAULT. The DEFAULT connection can also be specified dynamically using CONNECTION (name), where the name field must have the value 'DEFAULT'.
<b>Accessing Other Database Tables</b>
If you use a database connection to access database tables that are not in the R/3 standard database, there must also be a database table with the same name and identical type in the ABAP Dictionary of the local R/3 System. Open SQL assumes that the type information of these remote database tables corresponds exactly with that of the local database table. This prerequisite is essential for the correct interpretation of the database contents, for example, and, if necessary, their conversion with regards to the ABAP type of the target fields (see INTO Clause). If this prerequisite is not met, this can lead to wrong data or runtime errors when reading or writing, depending on the database system. Because the ABAP runtime system cannot ensure the consistency of the type descriptions in the local and remote databases, the consistency must be guaranteed by the relevant application program.
<b>Database Connections and Transactions</b>
Every database connection forms its own transaction context. This means that database changes on one connection can be saved (using COMMIT) or discarded (using ROLLBACK) independently of changes on other database connections. You can, for example, commit and store protocol data on a secondary database connection without affecting the running transaction on the standard R/3 database connection.
Secondary database connections are not known outside the limits of an internal session. So, if a program opens a database connection and then calls another program - with SUBMIT for example - that opens a connection to the same database, you have two different connections and therefore two different database transactions.
For the first Open SQL commandthat requests a specific database connection, the system opens a corresponding connection. All subsequent commands (in the same internal session) for the same remote database use the same database connection and all form a database transaction. The transaction is ended by:
A COMMIT CONNECTION or ROLLBACK CONNECTION on this
connection
<b>A COMMIT WORK or ROLLBACK WORK</b>
A database commit or database rollback on this database connection in Native SQL,
An implicit commit by a screen change, specifically the statements CALL SCREEN, CALL DIALOG, CALL TRANSACTION, MESSAGE
A Remote Function Call (RFC), specifically the statements CALL FUNCTION ... DESTINATION, CALL FUNCTION ... STARTING NEW TASK, CALL FUNCTION ... IN BACKGROUND TASK, and WAIT.
In summary, a database transaction is completed at the latest, when the application program reaches a state in which a change of work process could occur.
<b>Note:</b>
Working with parallel database connections, that is parallel transactions, can lead to lock situations that only one work process is involved in: A program changes a database row on the first connection and tries to change the same row on a second connection. This will result in the program waiting for the lock of the first program, without this first transaction ever being able to continue. You can only resolve this situation by ending the work process. This is done automatically for dialog processes, but must be done manually for background jobs. You should therefore not change the same table in one program on multiple database connections.
<b>Interaction with Native SQL Connections.</b>
In addition to the above, you can also explicitly open a connection using a CONNECT with Native SQL. Native SQL also allows you to explicitly close and disconnect a database connection using DISCONNECT. In this case, the database transaction in question is closed and corresponding database changes are discarded. You can use the Native SQL command GET CONNECTION to ascertain the current Native SQL connection. With Native SQL you can also access a connection that was opened with Open SQL. In this case it is sufficient to convert the active Native SQL connection using SET CONNECTION. It is not necessary to open it using CONNECT TO.
<b>Managing Database Connections</b>
The database connections are automatically managed by the runtime system. If a transaction is saved on a database connection (COMMIT) or rolled back (ROLLBACK), it can be reused by the runtime system. You can open a maximum of 10 database connections for each work process. On certain databases, you may not be able to reach this number.
Regards,
Subramanian V.