(1) A transparent gateway
(2) A procedural gateway
(3) An open database connectivity (ODBC) connection.
(1) A transparent gateway provides the ability to access data in a non-Oracle system from an Oracle environment (i.e., the application developers have a unified frontend for potentially different databases, such as MS SQLServer, Sybase, Teradata, DB2... You will need an Oracle Server for a tranparent gateway.).
(2) A procedural gateway allows users to initiate transaction program execution on remote OLTPs through remote procedure calls. In other words, Oracle Applications can send messages to other non-Oracle applications and receive responses from them. You would not want to do this without an Oracle server, although with considerable difficulty you might be able to.
(3) An ODBC connection operates through a protocol and a definition of the connection. ODBC connections do not require an Oracle Server. For instance, you use an ODBC connection to connect data from an Excel spreadsheet to an MS Access database or from Access to Progress or Oracle to DB2.
Although TOAD is a great tool, I think that there are potentially better tools for what you want to do.
Since your requirement is a little unclear, you should map it out. What data will be retrieved from what server and what application? What is the volume of data? How often with these transactions occur? Do they repeat throughout the day, or once only, or once a month? What is the ultimate resting place of the data? Is it merged with data from multiple sources?
Since you indicate that you presently do not have data residing in Oracle, what is the nature of the oracle gateway? Is this part of an overall process to convert to Oracle?
By looking at both the near-term, and long-term goals you can optimize your effort -- and expenditures.
Dig Deeper on Oracle E-Business Suite
Related Q&A from Carol Francum
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.