i am looking for an Delphi component to connect to an ORACLE database server in an direct way without install the oracle client.
i knew the Oracle Data Access (ODAC) from DevArt. there are any other component with this capability?
ODAC offers two connection modes to
the Oracle server: connection through
the Oracle Call Interface in Client
mode and direct connection over TCP/IP
in Direct mode. ODAC-based database
applications are easy to deploy, do
not require installation of other data
provider layers.
Thanks in advance.
No, there is no other Delphi Win32 libraries allowing to connect to Oracle without the installed Oracle Client. And, IMHO, that is correct, because:
OCI (Oracle Call Interface) is quite complex piece of software. I will say, it is most complex closed sourced DBMS Call Level Interface in the World. And it is changing from version to version. Oracle has official rule - the Oracle Client v X supports Oracle Server v X-1 ... X+1. Because even such company as Oracle, dont want to spend resources to support and test all the protocol nuances across all possible versions. So, I dont think, that DevArt ever will implement 99.9% stable Oracle SQL*Net protocol implementation. And the INet posts proof that ...
AFAIK, the ODAC Net mode does not support some of the Oracle Client important features and has some important limitations. Although it works well for simple data access scenarious.
If you will purchase Oracle support, then it will decline all your support requests, if they will know, that you are not using official client software. That is just Oracle rule.
If you dislike to install and tune the full scale Oracle Client, then you can just use Oracle Instant Client. Which does not require install or setup procedure. And you will be in safety in case of the different data access scenarious and Oracle Server versions.
PS: Although I may be considered as a biased person :)
There is also Allround Automations Direct Oracle Access, it do require Oracle SQL*Net or Net8. but is a brilliant component suite.
The only solution I found is ODAC, and it's working very nice, I have been using it since years without getting any problem with the direct mode.
there's some limitation with the direct mode, but most of users will not get these limitations with their application.
Related
I'm actually working in a situation where a .NET stack is managing an Oracle Database. Now, because the legacy code is consistently based on PL SQL stored procedures that deal with the majority of the work, the correct choice of driver to connect to the database is of primary importance.
For this reason, knowing that Oracle provides a large number of driver for the most known programming languages, I was trying to find a documented benchmark (even with all the problem and the influence of the context in which the tests are made) that could compare the different Oracle drivers for the different programming languages, just to support the hypothesis that the best choice in terms of performance for an isolated test microservice would be to use the Java driver in combination with Scala (Java is now property of Oracle now, after all).
Are there any on the internet that could support (or not) this hypothesis?
EDIT
I didn’t provide all the information. What I’m trying to achieve is develop a series of microservices focused on fetching data from the database and convert them into json to be consumed by the front end. .NET driver behaves seamlessly until the numbers become really overwhelming (> 1000 rows).
That’s why I was wondering if it could make any sense using JDBC to increase performance, having heard that, for instance, .NET driver for SQL server, both made by the same Company, performs 5 times better than the oracle one when it comes to gathering data from a cursor.
Your choice of drives may not give you the milage if most of the work is in PL/SQL or stored procedures. Having said that, jdbc is a good choice. However do not fight if developers are more familiar with other drivers like Oracle ODBC, oracle provider for .NET, ADO,etc.. all protocols have a Oracle drive to access Oracle DB.
You don’t have to convert to json. Oracle DB can convert it. Your network latency is more impacted by how big the pipe is ,array size,and packet size than protocols.
I have an idea to write an application to work with SAP Sybase IQ16 server using Go language. Platform windows/nix does not matter yet. I had workewd with this database using C# later, and I remember, that there was no ADO.NET driver, so I used ODBC + iAnywhere.Data.SQLAnywhere.v4.0.dll to establish connection. Also, I know, that drivers for IQ, ASE, etc... are not compatible. I looked here https://github.com/golang/go/wiki/SQLDrivers, but neither оf drivers seems to be compatible. Thus, I can not understand at all is there solution for my problem.
I saw some presentations about a very promising product "Oracle Instant Client".
Could you tell me what is the status of this product?
Is it really used?
How is the support from Oracle?
It seems to be kind of equivalent to the thin driver for Java. Is it really something as simple as unzip, modify 1 or 2 environment variables and run your client application?
http://www.oracle.com/technetwork/database/features/instant-client/index-100365.html
http://www.dbatoolz.com/t/installing-oracle-instantclient-basic-and-instantclient-sqlplus-on-win32.html
Thanks & regards
Alexandre
Oracle Instant Client is still an Product needed to be installed, it just comes with less features i.e. SQL Plus.
You can add individual components per demand.
The Instant Client is about 60 MB in size, compare to an Full client about 600 MB up to 1 GB depends on features you add there on top.
For simple db connection of an Client App, Instant Client is fully capable to fulfil this. The Idea is / was to add some security, since advanced users could do an connection threat to your DB.
It seems to be kind of equivalent to the thin driver for Java. Is it really something as simple as unzip, modify 1 or 2 environment variables and run your client application?
Pretty much, though it depends what your client application is. And which bits you download. If you install all of the packages then it includes the JDBC drivers (thin and OCI), libraries for OCCI apps, SQL*Plus... well, you can see all that from the downloads list. It's a smaller, simpler version of the full client, and doesn't need to be installed, just unzipped, which makes it easier to distribute too.
If you have the full Server or Client software installed then there's not much benefit in having the instant client as well; unless you need different driver versions, or you want to remove execute permissions from the full Oracle binaries for some reason. But if you have a new box that needs to access a remote DB then it gives you everything you need, simply. (Not quite instantly, but not far off).
It's been around since 10g and is fully supported, but like everything else, only if you have a support contract. It's certinly still supported in the sense that there is a new version to go with Oracle 12c.
In some respects it's very much just for client use though. For example, we develop Pro*C modules that we have to compile with the full version, but then we can happily execute them on a server that only has the instant client, to access a remote DB. That's not an issue for Java though.
I am developing some integration software for a client using amongst other things, C#, NServiceBus and Oracle 10g (client and server). The requirement is that I need to develop a new plugin for NServiceBus to create an implementation of ITransport which is the queuing mechanism for the messages. So Oracle Advanced Queuing is used for this. I have done quite a bit of work writing code for advanced queuing in Oracle 11g (client and server), but looking at ODP.Net 10g it seems that the queuing support is lacking or non-existent so that may prove to be problematic.
My question is this:
I know that you can use the 11g client against a 10g database server, but is it a good idea for Oracle Advanced Queuing and are there any gotchas I need to know about?
Many thanks.
Is it a good idea for Advanced Queueing? Well, I don't see why not, since 11g client connecting to 10g server is supported.
I don't imagine that AQ would pose any unique problem, specific to AQ. If you think about it, AQ is just PL/SQL calls that interact with tables under the covers. There's really nothing different at the client side, than there is with any other Oracle code.
So, I say go for it. But, as always: Test, test test. And then test some more.
But, in principle, I don't see a problem.
You may want to check out the NServiceBus-Contrib project, as there is an AQS transport there for 2.x.
can anyone tell me How does jdbc work? How it manages to communicate with a DBMS? since DBMS may be written with some other programming language.
Communication with the database is handled by JDBC drivers that can use various strategies to "talk" to a database (from "translation" to the use of "native" language). Depending on the strategy used, drivers are categorized into 4 types. Types of JDBC technology drivers provide a good description of each of them:
A JDBC-ODBC bridge provides JDBC API access via one or more ODBC
drivers. Note that some ODBC native
code and in many cases native database
client code must be loaded on each
client machine that uses this type of
driver. Hence, this kind of driver is
generally most appropriate when
automatic installation and downloading
of a Java technology application is
not important. For information on the
JDBC-ODBC bridge driver provided by
Sun, see JDBC-ODBC Bridge Driver.
A native-API partly Java technology-enabled driver converts
JDBC calls into calls on the client
API for Oracle, Sybase, Informix, DB2,
or other DBMS. Note that, like the
bridge driver, this style of driver
requires that some binary code be
loaded on each client machine.
A net-protocol fully Java technology-enabled driver translates
JDBC API calls into a DBMS-independent
net protocol which is then translated
to a DBMS protocol by a server. This
net server middleware is able to
connect all of its Java
technology-based clients to many
different databases. The specific
protocol used depends on the vendor.
In general, this is the most flexible
JDBC API alternative. It is likely
that all vendors of this solution will
provide products suitable for Intranet
use. In order for these products to
also support Internet access they must
handle the additional requirements for
security, access through firewalls,
etc., that the Web imposes. Several
vendors are adding JDBC
technology-based drivers to their
existing database middleware products.
A native-protocol fully Java technology-enabled driver converts
JDBC technology calls into the network
protocol used by DBMSs directly. This
allows a direct call from the client
machine to the DBMS server and is a
practical solution for Intranet
access. Since many of these protocols
are proprietary the database vendors
themselves will be the primary source
for this style of driver. Several
database vendors have these in
progress.
As we can see, there are various strategies to make interoperability possible, including implementing the network protocol used by a given database in Java (type 4). And because of their ease of use (no extra stuff to install, no JNI) and their good performances (they perform as well as type 2 drivers now), type 4 are actually the most frequently used nowadays.
From Wikipedia:
JDBC drivers are client-side adapters (installed on the client
machine, not on the server) that convert requests from Java programs
to a protocol that the DBMS can understand. [edit] Types
There are commercial and free drivers available for most relational
database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Most database systems support ODBC (Open Database Connectivity or whatever). This is meant to allow applications (e.g., Access) to work with multiple RDBMS implementations at the cost of some performance hit. When JDBC was first released, there was a driver that allowed you to connect to an ODBC provider. Later on, some vendors provided JDBC drivers specific to their RDMS.
From a developer's perspective, JDBC is used as a set of interfaces. All the actual details are hidden in loading the driver. The driver is a Java class that can use any trick of the book, including native code or just sending network traffic to the RDBMS.
From Wikipedia:
JDBC is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.
JDBC was first introduced in the Java 2 Platform, Standard Edition, version 1.1 (J2SE), together with a reference implementation JDBC-to-ODBC bridge, enabling connections to any ODBC-accessible data source in the JVM host environment.
Without going into too much detail, you can think of JDBC as an abstraction layer that lets you talk to different databases. The implementation-specific details are hidden from you, but the interface for querying a database (be it MySQL or Oracle or whatever) is the same.
What this means is that in future, if there was a new database, someone only needs to use the existing interface. The method names would be the same, but the methods would contain implementation-specific code for that particular database. This is a common software-engineering pattern.
The entity that contains the implementation-specific code is called the JDBC driver. The JDBC driver provides a connection to the database and it also implements the specific protocol for sending the query to the database and the result-set back to the client.
Can't say I know the exact answer to your question, but here is some information to help.
Here's a great place to start:
http://java.sun.com/products/jdbc/overview.html
The JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is the lower-level JDBC driver API for driver writers.
Information for JDBC Driver Developers. Basically there are a set of interfaces that a developer implements to create a JDBC driver for a particular DBMS.
http://java.sun.com/products/jdbc/driverdevs.html
As far as a DBMS being written in a different language. That DBMS most likely exposes some API (in various languages and/or formats) that allow for drivers, such as JDBC, to communicate with the DBMS.
From the wikipedia page:
Types
There are commercial and free drivers available for most relational database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Reading a bit about the four types of JDBC drivers might enlighten you.