ORACLE DB-Verbindung ohne Client-Installation

[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.