ORACLE DB-Verbindung ohne Client-Installation

[gunSoft]

Hallo zusammen,

ich habe bis jetzt BDE und dann ADO zur Verbindung mit ORACLE benutzt, suche
jetzt aber eine Möglichkeit die ohne jegliche Clientseitige Installation (Delphi-Client,Oracle-Client)
auskommt.

Ich bin da auf ODAC Net von der Firma CoreLab gestoßen, hab mir mal die Trial-Version
für Delphi 7 runtergeladen und getestet. Das scheint aber nicht die Net-Version ohne Oracle-Client
zu sein, oder ich mach was falsch.

Hat jemand gute/schlechte Erfahrungen mit ODAC bzw. kennt jemand
eine Alternative?

Danke
Grüße
~günther

[Bernhard Geyer]

Zitat:

Zitat von gunSoft

Ich bin da auf ODAC Net von der Firma CoreLab gestoßen, hab mir mal die Trial-Version
für Delphi 7 runtergeladen und getestet. Das scheint aber nicht die Net-Version ohne Oracle-Client
zu sein, oder ich mach was falsch.

Ich glaube du mußt noch in einem Property einstellen das der direkte Zugriff verwendet werden soll. Die CrLab-Komponenten können unterschiedliche Modi fahren.

[Elvis]

Zitat:

Zitat von gunSoft

kennt jemand
eine Alternative?

DOA ist eine, performancemäßig gesehen, sehr gute Alternative.
Extrem tight an den Client geknüpft, aber als Oracle'ler sollte einem der Instant client kein Fremdwort sein. Einfach ein paar Bibliotheken und eine tnsnames.ora in den App Ordner und schon hast du einen vollen Oracle Client (mit allem client seitigem Caching etc. )

Das dumme an DOA ist, dass bei ihnen seit D7 die Zeit stillzustehen scheint.
Kein .Net Provider... :wall:

[gunSoft]

Ich glaube du mußt noch in einem Property einstellen das der direkte Zugriff verwendet werden soll. Die CrLab-Komponenten können unterschiedliche Modi fahren.

Super, habs gefunden:
OraSession1.Options.Net := True
dann nur noch den Server und Instanz angeben und es klappt! :hello:

Ich mußte aber folgende Datein ins Programmverzeichnis kopieren
damit es geht:

dac70.bpl
odac70.bpl
rtl70.bpl
dbrtl70.bpl

Ist das Standard oder kann man das auch noch umgehen?

[Bernhard Geyer]

Zitat:

Zitat von gunSoft

Ist das Standard oder kann man das auch noch umgehen?

Dein Programm wird mit Runtime-Packages kompiliert. Einfach abschalten oder aus Liste herausnehmen.

[gunSoft]

Zitat:

Zitat von Bernhard Geyer

Dein Programm wird mit Runtime-Packages kompiliert. Einfach abschalten oder aus Liste herausnehmen.

Was meinst du mit einfach abschalten oder aus Liste herausnehmen? :?:
entschuldige meine Unwissenheit.. :oops:

[Bernhard Geyer]

Siehe Anhang

[gunSoft]

Zitat:

Zitat von Bernhard Geyer

Siehe Anhang

AHA, jetzt hab ichs kapiert.
Nur ich hab bei meinem Testprojekt die Option
"Mit Laufzeit-Packages aktualisiern" nicht aktiv, also
sollte ich keine .bpl's mitgeben müssen, oder ?

Kann es vielleicht sein, weil diese ODAC-Komponenten nur
eine Demoversion sind?

[Bernhard Geyer]

Zitat:

Zitat von gunSoft

AHA, jetzt hab ichs kapiert.
Nur ich hab bei meinem Testprojekt die Option
"Mit Laufzeit-Packages aktualisiern" nicht aktiv, also
sollte ich keine .bpl's mitgeben müssen, oder ?

Setzte mal den Schalter, Schließe den Dialog, gehe nochmal rein und setze ihn zurück.
Hier haben manche Delphi-Versionen einen Bug das trotzt nicht angewählter Option
Laufzeitpackages verwendet werden.

[gunSoft]

Zitat:

Zitat von Bernhard Geyer

Setzte mal den Schalter, Schließe den Dialog, gehe nochmal rein und setze ihn zurück.
Hier haben manche Delphi-Versionen einen Bug das trotzt nicht angewählter Option
Laufzeitpackages verwendet werden.

Hat leider nichts gebracht. Aber egal, für mich war jetzt erstmal wichtig
zu wissen dass es grundsätzlich möglich ist.

Danke für die Hilfe Bernhard!

[delphirocks]

Wenn du dich direkt verbinden willst, mußt du im Connectionstring die IP-Adresse, SID, Port, usw. mitangeben. Dann funktioniert's...

Und die "Net" Option muß irgendwo enabled werden.

[merlin17]

@Elvis

Zitat:

Das dumme an DOA ist, dass bei ihnen seit D7 die Zeit stillzustehen scheint.
kein .Net Provider...

Die V4 von DOA gibt es seit letzter Woche sogar schon für D2006, allerdings nur VCL32;
einen .net-provider von DOA wird es (meiner Meinung nach) NIE geben, dafür gibt es
doch den ODP.net und von Borland die BDP.net-Ora-Anbindung...


:-) thomas

[Elvis]

Zitat:

Zitat von merlin17

@Elvis

Zitat:

Das dumme an DOA ist, dass bei ihnen seit D7 die Zeit stillzustehen scheint.
kein .Net Provider...

Die V4 von DOA gibt es seit letzter Woche sogar schon für D2006, allerdings nur VCL32;
einen .net-provider von DOA wird es (meiner Meinung nach) NIE geben, dafür gibt es
doch den ODP.net und von Borland die BDP.net-Ora-Anbindung...

Der ODP ist buggy und kennt keine Objekttypen (bzw. ist extrem buggy bei den angebitenen Hack-Arounds).
Der BDP... ich tue lieber so als wäre da ein Witz gewesen... ;)
AllroundAutomations scheint einfach eingepennt zu sein... Man bedenke auch wielange es schon ein paar extrem nervige Bugs in deren anonsten genialen PL/SQL Developer gibt... :cry:

[merlin17]

Zitat:

AllroundAutomations scheint einfach eingepennt zu sein...

erinnert mich an QuSoft(QuickReport) und XMLRad etc.etc.

Zitat:

Der ODP ist buggy und kennt keine Objekttypen (bzw. ist extrem buggy bei den angebitenen Hack-Arounds).

ich kenne ihn und sicherlich ist er etwas "verbesserungswürdig"... things.take.time.

Zitat:

Der BDP... ich tue lieber so als wäre da ein Witz gewesen...

hatte ich hier den Smiley für "zwischen den Zeilen" vergessen :angel:
:-) thomas

[gunSoft]

Zitat:

Zitat von Elvis

DOA ist eine, performancemäßig gesehen, sehr gute Alternative.
Extrem tight an den Client geknüpft, aber als Oracle'ler sollte einem der Instant client kein Fremdwort sein. Einfach ein paar Bibliotheken und eine tnsnames.ora in den App Ordner und schon hast du einen vollen Oracle Client (mit allem client seitigem Caching etc. )

Danke für den Input!
Habe jetzt mal ADO mit Instant Client versucht und es funzt!
Damit währe mein Problem eigentlich gelöst, weil ich für die DB-Seite immer ein paar selbst geschriebene Klassen benutze
die auf ADO aufsetzen, wenn mir nicht folgendes aufgefallen währe:

Auf euren Ansporn an habe ich eben ODAC und ADO mit Instant Client getestet und gemerkt dass ODAC um Längen schneller
zu sein scheint. Ich hatte öfters schon den Verdacht das ADO etwas langsam ist...

Ist diese Erkenntnis neu? Und gibt es vielleicht irgendwo einen Vergleich zwischen den Verschiedenen Möglichkeiten
speziell mit Delphi Win32 auf Oracle zuzugreifen.

Und noch eine Frage zu DOA: hat das Vorteile gegenüber ODAC oder ADO?

[delphirocks]

Nachteil von DAO: keine "net" Option möglich, du brauchst also immer die Oracle Client-Software.
Vorteil von DAO: Package Wizard (generiert dir einen Delphi Wrapper für Oracle Packages, d.h. du hast ganz normales Intellisense für den Aufruf von Packages) - bin mir nicht sicher, ob Corelab da schon nachgezogen hat.
Du ersparst dir bei großen Packages viel Schreibarbeit.

Von der Performance glaube ich wird es sich ähnlich verhalten wie bei Java thin vs. Java/OCI ... je mehr Stored procedures desto performanter die OCI Lösung.

Ich verwende zur Zt. die DAO Komponenten und bin sehr zufrieden damit. Allerdings wußte beim Kauf vor ein paar Jahren noch nichts von der ODAC net Option...

Performanceprobleme wirst du wahrscheinlich mit keinem der beiden Komponentensets erfahren.

Den einzigen Vorteil, den ich bei ADO erkennen kann, ist die universelle Schnittstelle, dh. du kannst eventuell datenbankunabhängig programmieren, wenn du keine datenbankspezifischen Extras verwendest...
Ach ja, und natürlich der Preis.
Wobei sowohl DAO als auch ODAC den Preis wert sind.

[Bernhard Geyer]

Zitat:

Zitat von gunSoft

Auf euren Ansporn an habe ich eben ODAC und ADO mit Instant Client getestet und gemerkt dass ODAC um Längen schneller
zu sein scheint. Ich hatte öfters schon den Verdacht das ADO etwas langsam ist...

Meinst Du ADO oder den ADOExpress/dbGo-Aufsatz von Delphi. Dieser bremst natürlich auch da er nochmal eine Zwischenschicht darstellt.

Zitat:

Zitat von gunSoft

Und noch eine Frage zu DOA: hat das Vorteile gegenüber ODAC oder ADO?

Bei vielen Firmen die Oracle einsetzen ist ein passender Client fast immer installiert. Bei ADO wird das nicht der Falls ein so das Du extra-Installationsaufwand hast.

Zitat:

Zitat von delphirocks

Den einzigen Vorteil, den ich bei ADO erkennen kann, ist die universelle Schnittstelle, dh. du kannst eventuell datenbankunabhängig programmieren, wenn du keine datenbankspezifischen Extras verwendest...

Und jede halbwegs größere Anwendung wird DB-Spezialitäten verwenden bzw. aufgrund der unterschiedlichen SQL-Syntax hier eh die DB's unterscheiden müssen.

Zitat:

Zitat von delphirocks

Ach ja, und natürlich der Preis.
Wobei sowohl DAO als auch ODAC den Preis wert sind.

FULL ACK (ich habe im Moment DAO im Einsatz).

[gunSoft]

Erstmal danke für eure Stellungnahmen!

Zur Klärung:
mit ADO meine ich die ADO (ADODB) Komponenten von Delphi (aktuell benutze ich Delphi 7).

Bezüglich passender Oracle Client-Software:
wie ich hier gelernt habe gibt es folgende Möglichkeiten:
- "Normaler" Oracle-Client
- Oracle Instant Client
- direkter Zugriff über TCP/IP (ODAC Net)
gibt es da noch andere Möglichkeiten?

[Elvis]

Zitat:

Zitat von gunSoft

Habe jetzt mal ADO mit Instant Client versucht und es funzt!

DOA (DirectOracleAccess) nicht ADO! :shock:
Und ja, das läuft prima mit dem Instant client. Deren PL/SQL Developer kann man auf die Art als Portable App neben OpenOffice und FireFox immer mit sich auf einem USB Stick herumtragen.
Falls ich irgendwo mit Ora arbeiten muss, muss ich nur die dortige OraDB in die tnsnames.ora eintragen und los gates. :)

[Alfons_G]

Also ich kann aus meiner mehrjährigen Erfahrung mit ODAC D5, D7, D2005) nur sagen, dass ich wirklich zufrieden bin :).

Die Upgrade-Poltik ist sehr gut. Man kann sich mit dem einmal erhaltenen Download-Link immer wieder einloggen und die jeweils aktuellste Version downloaden. Mit dem Kauf erwirbt man die Versionen für alle Delphi-Versionen seit D3 und kann sich die jeweils benötigten Bibliotheken downloaden.

Der Support ist nach meiner Meinung hervorragend. In den (wenigen) Fällen, wo ich Hilfe gebraucht hatte, kam die Antwort per Mail innerhalb weniger Stunden.

:coder:

[gunSoft]

Zitat:

Zitat von Elvis

DOA (DirectOracleAccess) nicht ADO! :shock:

Nochmal, mit ADO meine ich ADO (ADODB) von Delphi.
Ist das so abwägig? bin ich der einzige der das benutzt? :gruebel:

[Elvis]

Zitat:

Zitat von gunSoft

Nochmal, mit ADO meine ich ADO (ADODB) von Delphi.
Ist das so abwägig? bin ich der einzige der das benutzt? :gruebel:

Eigentlich nicht. ADO hat eigentlich eine ziemlich nett gestaltete Architektur und ist auch sonst ganz schnucklig. Wenn es aber zu Oracle kommt dürftest du mit ADO in der totalen Minderheit sein. Ora kostet einfach zu viel und ist eigentlich auch viel zu cool um es durch OleDB zu beschneiden. ;)

[Bernhard Geyer]

Zitat:

Zitat von Elvis

Eigentlich nicht. ADO hat eigentlich eine ziemlich nett gestaltete Architektur und ist auch sonst ganz schnucklig.

Deshalb ist es ja auch von MS in .NET wieder auf Abstellgleis geschoben. Den ADO.NET hat mit ADO praktisch nur den Namen gemeinsam. Sonst ist es ganz Praktisch um auf MS-Datenbanken zuzugreifen

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Deshalb ist es ja auch von MS in .NET wieder auf Abstellgleis geschoben. Den ADO.NET hat mit ADO praktisch nur den Namen gemeinsam. Sonst ist es ganz Praktisch um auf MS-Datenbanken zuzugreifen

Sorry, Bernhard, aber könntest du dir bitte mal vorher durchlesen, was du manchmal für etwas zu verbitterte Beiträge schreibst?
ADO ist auf dem Abstellgleis weil es schnucklig ist? :gruebel:
ADO.Net hat nix mit ADO gemeinsam? :gruebel:
Wenn man ADO unabhängig von Delphis wrapper (dbGo) betrachtet, bekommt man fast die gleiche Hierarchie von Interfaces, die fast die gleichen Properties/Methoden haben, wie ihr ADO.Net-Gegenstück.
ADO.Net wurde wegen dieser Ähnlichkeit der Hierarchie so bennant. Hat ja nix mit ActiveX zu tun. :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von Elvis

Wenn man ADO unabhängig von Delphis wrapper (dbGo) betrachtet, bekommt man fast die gleiche Hierarchie von Interfaces, die fast die gleichen Properties/Methoden haben, wie ihr ADO.Net-Gegenstück.
ADO.Net wurde wegen dieser Ähnlichkeit der Hierarchie so bennant. Hat ja nix mit ActiveX zu tun. :zwinker:

1, ADO ist default-maßig Connected. ADO.NET arbeitet fast immer im Disconnected Modus.

2, In ADO gibt man im Connection-String an welche Provider ADO verwenden soll. In ADO.NET muß ich auf jedenfall einen passenden managed ADO.NET haben. D.h. in ADO kann ich durch ändern des Connection-Strings (wenn die Anwendung einfach gestrickt ist) unterschiedliche DBMS abfragen. In ADO.NET brauch ich (wenn ich nicht nach ADO "zurückfallen will" einen passenden ADO.NET-Provider wobei M$ hier nur den für den MS SQL-Server anbietet und eine (vermutlich kastrierten) für Oracle.

Das gewisse Ähnlichkeiten vorhanden sind ist zwangsweise gegeben. Diese sind aber auch zwischen DAO, ADO, TDataset vorhanden.
Und mit meiner meinung über die unterschiede bin ich nicht allein. Siehe: Eine Einführung in ADO.NET

Zitat:

Die Bezeichnung ADO.NET für die Datenbankzugriffs-Architektur von .NET suggeriert Kontinuität. So ein bisschen wie ADO 2.0 oder ADO 2002. .NET wäre aber nicht .NET wenn Microsoft nicht auch hier tiefgreifend Hand angelegt hätte, so dass am Ende doch fast kein Stein auf dem anderen geblieben ist.

[delphirocks]

Etwas offtopic, aber:

Microsoft übertreibt's mit den Datenbankzugriffstechnologien etwas, und das schon seit Jahren.
DAO, RDO, OLEDB, ADO, ADO.net 1 und 2, ODBC.

Wofür muß sich eine Basistechnologie alle 2 Jahre ändern? Um die Programmierer zu beschäftigen?

[Bernhard Geyer]

Zitat:

Zitat von delphirocks

Etwas offtopic, aber:

Microsoft übertreibt's mit den Datenbankzugriffstechnologien etwas, und das schon seit Jahren.
DAO, RDO, OLEDB, ADO, ADO.net 1 und 2, ODBC.

Wofür muß sich eine Basistechnologie alle 2 Jahre ändern? Um die Programmierer zu beschäftigen?

OLE DB und ADO kannst du zusammenfassen. ADO ist "nur" die Client-Programmierschnittstelle von OLE DB.
Aber sonst gebe ich dir recht. Alle 2 Jahre wird die revolutionierende Technologie vorgestellt und (meistens) die alte Verdammt. Da bin ich froh das Borland mit D3 TDataset von der BDE getrennt hat und ich auch in 2006 noch gute, performante Programme schreiben kann und mit 3th-Party Komponenten (z.B. von Core Labs) auch "direkt" an der Datenbank dran bin. Und das alles auch 100%ig X-Copy-Fähig.