Ich stand vor kurzem genau vor dem gleichen Thema ... OleDB oder OCDB.

Nach einigen Recherchen habe ich mich entschieden bei der OCDB-Connection zu bleiben. Und die Entscheidung habe ich bisher auch nicht bereut.

Ich denke der relevanteste Unterschied dürften die Themen Binding an Formular in NET sein und typisierte DataSets.

Letztere finde ich nett wenn es mal um kleinere Jobs geht wie z.B. eine embbeded DB zu schaffen die in ein paar wenigen Tables Informationen abspeichert, aber mit größeren DB's klappt das nicht mehr weil nach einigen Infos im INet typsierte DataSets anfangen Probleme zu bekommen wenn es mal die Grenze von rd. 700 Fields/Attribute gesamt gesehen überschreitet. Damit war der Punkt für mich eh obsolet.

Binding an Formulare ... nun ja, ich bin eher ein Freund davon das Thema händisch mit einer paar Routinen abzuhandeln damit ich auch genau weiss was wann und wo passiert. MS-Automatismen habe ja bekanntlich oftmals die ein oder andere Tücke und sind nun auch nicht wirklich die flottesten.

Aber ich glaube der Hauptgrund für mich ist die Gewöhnung an den Umgang mit ADODB.Recordsets und das das sonst easy und schnell zu erledigen ist echt ein gröberen Aufwand nach sich zieht.

Für mich persönlich ist das OleDB für NET das was DAO für MC-Access ist, bloss viel umständlicher und mMn problembehafteter wenn man wirklich komplexere Dinge machen will als mal schnell ein Table an ein Formular zu binden. Einfach mal so ein SQL-Statement auf Grund User-Eingaben dynamisch zu erstellen und das Ergebnis in ein ADODB-Recordset zu übernehmen und zu bearbeiten ist nicht mit OleDB.

Rein gefühlt kann ich nur sagen das die OCDB-Connection für mich um Welten schneller ist als die OleDB-Connection (nach allgemeinen Aussagen im Internet soll der Geschwindkeitsvorteil sogar bei bis zu 70% liegen) und bei vielen Problemen hier im Forum ala "Wie mach ich das" mit einer OleDB-Connection denke ich mir immer wieder "Mein Gott, wie einfach, schnell und unkompliziert ist das alles mit einer ODCB-Connection und einem ADODB.Recordset ... wieso tut man sich nur freiwillig den Umgang mit dem OleDB-Objektmodell an".

Aber natürlich ... meine persönliche Meinung und faktisch kann ich Dir das auch nicht belegen, hat mich nicht wirklich interessiert da mir bis jetzt noch nichts aufgefallen wäre (ausser Formular-Binding und typisierte DataSets) was das OleDB-Objekt-Modell besser kann.

Eher im Gegenteil ... z.B. das Reader Objekt-Modell das das Ergebnis eines SELECT-Statements aufnimmt ist read- und forward-only. Will man nicht nur DS abfragen um diese in einer Loop auszulesen, sondern auch die Möglichkeiten eines ADODB.Recordsets haben (z.B. Navigation innerhalb der DS) muss man schon wieder über den deutlich langsameren DataAdapter gehen oder gleich über den TableAdapter. Wie ein recht aktueller Thread hier zeigt gibt es offensichtlich auch einige Schwierigkeiten mit Einträgen die die DB automatisch erzeugt (Autowerte, Trigger-Aktionen), dass die eben nicht wie mit einem ADODB.Recordset zur Verfügung stehen sondern erst ein erneute Abfrage auf die DB voraussetzen ... und zwar des kompletten DS-Bestandes. Es sieht so aus als wenn das ganze OleDB-Objekt-Modell darauf ausgelegt ist das die einmal abgeholten Daten im Memory vorgehalten werden, Änderungen an die DB kann man dann mit einem Befehl vornehmen bekommt aber die ganzen Autoeinträge dann nicht zurück übermittelt.

Irgendwie erscheint mir das Konzept der OleDB's noch nicht wirklich richtig durchdacht zu sein, bzw. im Vergleich zu dem Objektmodell der OCDB-Connection viel zuviel aufgebläht worden zu sein um so eine Art Access-DAO-Objektmodell auch in NET zu realisieren.

Gruß

Rainer

ich kannich ganz folgen, wg der Begriffe: Connector/ODBC, Connector/NET und OCDB-Connection.
Sind das 3 verschiedene Dinge, oder ist Connector/NET = OCDB-Connection?

Also ich kenn ja nur OleDB und SqlClient, und die sind vonne Funktionalität identisch. Dann gibts da noch ODBC - ich dachte das wäre Oracle-Unterstützung?

Jedenfalls sind alle diese Technologien identisch insofern, dasse u.a. auch DataAdapter anbieten, und DataAdapter ist das Dingsbums, mit dem man Datasetse befüllt und rückspeichert, wenn man das will.
Und typisiertes Dataset wiederum ist ein strukturelles Abbild der DB-Struktur, bei der die DB-Tabellen als DataTables gespiegelt werden, und die DB-Datensätze als DataRows, und die Attribute als ordentlich typisierten Properties der DataRows.
Gewissermaßen die Übertragung des MengenOrientierten Paradigmas der DB in den OOP-Kontext von VB.
Ja, und mit typisierten Datasets kann man mittels Databinding auf sehr elegante Weise sehr anspruchsvolle Guis zusammenstellen.

Jdfs. binnich verwirrt: Wenn man auf OCDB setzt, ist einem die Option DataAdapter zu verwenden verwehrt?

ADO setzt auf ODBC auf. Oder OleDB. oder ...
ADO braucht eine Dataprovider. ODBC ist einer von mehreren Dataprovidern.

Letzlich ist ADO also nur ein zusätzlicher Abstractionslayer.

msdn.microsoft.com/en-us/library/h43ks021.aspx

ADO.NET provides consistent access to data sources such as SQL Server and XML, and to data sources exposed through OLE DB and ODBC.

picoflop schrieb:

Letzlich ist ADO also nur ein zusätzlicher Abstractionslayer.

...an dem es aber keinen Weg vorbei gibt. Auch der DataReader ist Element von ADO - so verstehe ich msdn.microsoft.com/de-de/library/27y4ybxw.aspx wenigstens.

ErfinderDesRades schrieb:

Jdfs. binnich verwirrt: Wenn man auf OCDB setzt, ist einem die Option DataAdapter zu verwenden verwehrt?

So würde ich es nicht formulieren.

Eine OCDB-Connections (DBMS ist dabei völlig egal, geht auf alle Datenbanken die einen Provider für ODBC anbieten) ermöglichen die Arbeit mit ADODB.Recordsets und wenn man die nutzt bleibt man von dem ganzen Unfug (meine persönliche Meinung) wie DataAdapter, TableAdapter, Reader und sonstigem verschont.

Ein ADODB-Recordset ist nämlich alles in Einem und dazu noch sehr schnell, sehr komfortabel und extrem flexibel. Was das Recordset an Daten beinhaltet bestimmst Du schlicht über ein SQL-Statement das Du beim Öffnen des Recordsets übergibst.

Aber auch der ODBC-Provider bietet DataAdapter u.ä. an.

...an dem es aber keinen Weg vorbei gibt. Auch der DataReader ist Element von ADO ...

Richtig, ADO ist die Datenbankzugriffstechnik die MS anbietet.

Aber es gibt hier mehrere Provider die angeboten werden. Eben der neue OleDB-Provider, der ältere Universal-Provider ODBC oder eben der spezielle MsSQL-Provider SQLClient.

Alle drei beinhalten relativ identische Objekt-Modelle als gemeinsame Grundlage. Aber zusätzlich können die Provider auch spezielle nur bei Ihnen verfügbare Object-Modelle beinhalten, wie z.B. das ADODB-Objekt-Modell des ODBC-Providers.

Gruß

Rainer

Mit ADO/ODBC habe ich ja bereits unter VB6 gearbeitet,

Ich hab echtn Problem mit diese Kürzel. Ich dachte immer, ADO gebe es erst ab .Net, und unter VB6 habe es DAO geheißen.
Oder gabs zuvor schon ADO, und mit .Net ist ADO.Net rausgekommen?

LaMa5 schrieb:

So viel anders wird das in der neuen Version dann auch nicht sein (von der Syntax mal abgesehen).

Es ist total anders - jedenfalls DAO und ADO.Net.

ErfinderDesRades schrieb:

Ich hab echtn Problem mit diese Kürzel. Ich dachte immer, ADO gebe es erst ab .Net, und unter VB6 habe es DAO geheißen.
Oder gabs zuvor schon ADO, und mit .Net ist ADO.Net rausgekommen?

DAO ist das Hausmodell von MS-Access und funktioniert auch nur mit MS-Access. Daher war früher die ODBC (ich hasse diese Abkürzung, da ich sie immer falsch schreibe ... was vermutlich an den Plättchen aus meiner Jugend liegt, das hat sich zu sehr eingebrannt *lach*) des ADO-Objektmodells die Datenbankzugriffs-Funktion für alles was nicht MS-Access war. Daher auch die universelle Einsatzfähigkeit mit allen üblichen Datenbanken. Den MS-SQLClient gabe es zuvor auch schon wenn ich mich nicht täusche.

Mit .NET hat MS alle Datenzugriffobjekte in unter dem Begriff ADO.NET zusammen gefügt und das neue OleDB-Objektmodell hinzugefügt. Dazu dann aber auch die Objektmodelle in ODBC und SQLClient um die Basismodelle von OleDB erweitert. Deswegen hat eben jeder der drei Provider unter ADO.NET auch die gleichen Grundklassen wie eben TableAdapter etc. . Du kannst daher theoretisch Objekte die Du unter Verwendung der Klassen die alle 3 gemeinsam haben erstellst völlig unabhängig von der Verbindungsart machen und dann zur Laufzeit entscheiden welchen Verbindungsprovider Du dann für die Ausführung benutzt. Aber dummerweise steht dem Option Strict On und restriktive Typisierung im Weg ... man kann halt nicht wirklich eine Variable vom Typ MySQLConnection so mir nix Dir nichts in eine Variable vom Typ SQLConnection umwandeln.

[/quote]Es ist total anders - jedenfalls DAO und ADO.Net.[/quote]

Natürlich. DAO ist ja auch nur eine reines MS-Access Objekt-Modell und ADO.NET beinhaltet gleich drei Objekt-Modelle. Daher ist die hier oftmals zu lesenden Aussage "Ich greife per ADO.NET auf die Datenbank zu" ... ja klar, aber mit welchem Objektmodell denn nun?

@ LaMa5

wenn ich das jetzt richtig verstehe, ist für mich ADO via ODBC die richtige Wahl. Dort könnte ich später beliebige andere Datenbanken anbinden (sofern ein ODBC Datenbankprovider zur Verfügung steht).

Ja richtig, denn bei OleDB und MySQL brauchst Du ja das spezielle Objekt-Modell für MySQL. Was aber irgendwie dem ganzen Grundkonzept das eigentlich dahinter stecken sollte ... alle Provider bieten die gleichen Klassen an, damit die Provider beliebig ausgetauscht werden können irgendwie wieder ad absurdum führt.

Ich meine ...

Dim con As New MySQLConnection
Dim con As New SQLConnection
Dim con As New ODBCConnection

oder

Dim reader As New MySQLReader
Dim reader As New SQLReader
Dim reader As New ODBCReader

Was soll das wenn doch die Idee das alle Provider die gleichen Objekt-Modelle anbieten um sie eben flexibel austauschbar zu machen dahinter stecken soll? Um das flexibel zu halten haste dann wirklich viel Arbeit mit Objekt-Modell-Kapselung, Interfacenutzung und Decissions zur Bestimmung welcher Provider.

Aber letztendlich wird zB. beim Binding eben nur irgendein TableAdapter erwartet, völlig latte ob MySQLTableAdapter, SQLTableAdapter oder OCDBTableAdapter.

Wenn Du Dir den Aufwand antun willst dann wäre das aber vermutlich die optimale Lösung das es Dich letztendlich völlig unabhängig macht vom Provider.

Mit ADO/ODBC habe ich ja bereits unter VB6 gearbeitet, und kenne zumindest schon mal die grundsätzliche Arbeitsweise. So viel anders wird das in der neuen Version dann auch nicht sein (von der Syntax mal abgesehen).

Die Arbeitsweise beim Datenbankzugriff ist ja irgendwo eh immer identisch ... Verbindung erstellen, einen Datenbehälter mit Daten aus der DB über ein SQL-Statement befüllen und dann damit im Programm arbeiten.

Wenn in VB6 bereits mit ADODB gearbeitet hast, dann ändert sich quasi gar nichts falls Du nicht unbedingt die neuen Objektmodelle brauchst.

Gruß

Rainer

raist10 schrieb:

Ich meine ...

Dim con As New MySQLConnection
Dim con As New SQLConnection
Dim con As New ODBCConnection

oder

Dim reader As New MySQLReader
Dim reader As New SQLReader
Dim reader As New ODBCReader

Was soll das wenn doch die Idee das alle Provider die gleichen Objekt-Modelle anbieten um sie eben flexibel austauschbar zu machen dahinter stecken soll? Um das flexibel zu halten haste dann wirklich viel Arbeit mit Objekt-Modell-Kapselung, Interfacenutzung und Decissions zur Bestimmung welcher Provider.

Ich glaub da unterschätzt du das Konzept. Alle diese Dinger beerben dieselben abstrakten Basisklassen, und von daher kann man durchaus nach dem Strategy-Pattern proggen, und einer bereits lauffähigen Anwendung unterm Hintern einen anneren DBProvider unterjubeln:
Theoretisch ists möglich, nur mit den Klassen aus Data.Common zu proggen.
Praktisch habich da eher keine Verwendung für. Zunächstmal wüsste ich nicht, warum ich dieselbe DB in verschiedenen DBMS zurechtbasteln sollte. Und dann - und das ist die Crux - sind die Sql-Dialekte unterschiedlich, und bieten die verschiedenen Provider Features an, die der annere Provider nicht unterstützt.

ErfinderDesRades schrieb:

Ich glaub da unterschätzt du das Konzept. Alle diese Dinger beerben dieselben abstrakten Basisklassen, und von daher kann man durchaus nach dem Strategy-Pattern proggen, und einer bereits lauffähigen Anwendung unterm Hintern einen anneren DBProvider unterjubeln:

VB.NET-Quellcode

1. Dim con As System.Data.Common.DbConnection = New MySQLConnection
2. Dim con As System.Data.Common.DbConnection = New SQLConnection
3. Dim con As System.Data.Common.DbConnection = New ODBCConnection
5. oder
7. Dim reader As System.Data.Common.DbDataReader = New MySQLReader
8. Dim reader As System.Data.Common.DbDataReader = New SQLReader
9. Dim reader As System.Data.Common.DbDataReader = New ODBCReader

Theoretisch ists möglich, nur mit den Klassen aus Data.Common zu proggen.
Praktisch habich da eher keine Verwendung für. Zunächstmal wüsste ich nicht, warum ich dieselbe DB in verschiedenen DBMS zurechtbasteln sollte. Und dann - und das ist die Crux - sind die Sql-Dialekte unterschiedlich, und bieten die verschiedenen Provider Features an, die der annere Provider nicht unterstützt.

Denke da hast Du mich falsch verstanden, bzw. ich habe mich vermutlich mißverständlich ausgedrückt.

Wenn ich mit dem ADODB-Recordet-Modell arbeite, kann ich das durch die Bank weg überall verwenden und einsetzen. Ich muss genau Null beachten in Bezug drauf welches DBMS dahinter hängt (okay ... schon, man sollte halt mit DB-Typen arbeiten die in allen möglichen DBMS auch vorkommen und sollte auch keine speziellen Dialekte oder Functionen nutzen ... aber das macht man eh selten und bedient sich lieber der klassischen Syntax die eh jedes DBMS beherrscht).

Will ich das DBMS dahinter wechseln, dann übergebe ich einfach nur einen anderen Connection-String und Feierabend und alles funzt wie gehabt, egal ob MSSQL, MYSQL, Oracle, Access or whatever. Ich habe dann halt in der App eine einzige Datenbank-Connection-Klasse geproggt, die beinhaltet die Auswahl-Logik auf welches DBMS zu gegriffen wird und setzt dann passend den richtigen Connection-String ein und Feierabend. Damit wäre ich sogar in der Lage in einer einzigen App mit mehreren verschiedene DBMS zu arbeiten ohne das vorher bei der Erstellung zu berücksichtigen.

Ich muss mich nicht an allen anderen Stellen in der App mit dem Thema rumschlagen und völlig anders proggen nur um die Flexibilität zu besitzen später mal das DBMS wechseln zu können.

D.h. keinen Umweg gehen über die System.Data.Common-Klassen und dann für jedes DBMS eine eigene Zugriffsklasse proggen die dann nur per Interface angesprochen werden kann und dazu dann eine Zugriffsverwaltung proggen die entscheidet welche der Zugriffsklassen nun als Interface-Objekt genutzt wird. Und desweiteren muss ich mich nicht mit kleinen aber doch entscheidenden Unterschieden in der Syntax rumschlagen, denn wenn ich das richtig verstanden haben nutzen die verschiedenen Provider bei OleDB direkt die eigen DBMS-Syntax und verstehen daher teilweise nicht mehr die Standard-SQL-Syntax.

Aber gut, vielleicht bin ich da auch nur zu eingefahren.

Zunächstmal wüsste ich nicht, warum ich dieselbe DB in verschiedenen DBMS zurechtbasteln sollte.

Gibt vielerlei Gründe die Sinn machen flexibeles DBMS-Management dahinter zu knallen:

- Man erstellt eine Entwicklung die man verkaufen will, muss/will aber berücksichtigen das man vielleicht auch schon Kunden hat die bestehende SQL-Server-Installationen haben. Da wäre es ungeschickt dem Kunden nun erklären zu müssen wieso er dann noch eine zweiten SQL-Server braucht um Dein Programm zu nutzen, von der Kostenseite die ja auch vielfach den Ausschlag gibt eine Software zu kaufen oder nicht mal ganz zu schweigen
- Flexibele Applications-Gestaltung, man möchte sich halt bei Entwicklung frei halten ob die App später mit einer lokalen Server-Installation arbeitet oder mit einem im Internet gehosteten Server oder auch als Single-User-Installation mit einer simplen File-DB dahinter arbeitet
- Unabhängigkeit der aktuellen Entwicklung von einem DB-Anbieter, ist halt immer blöd wenn man von einem Anbieter abhängig ist und der tut nun Dinge die einem nicht so passen (Preiserhöhungen etc.) und man kann dann nicht wechseln

Das wären mal so ein paar Gründe die mir auf die Schnelle einfallen würden.

Gruß

Rainer

LaMa5 schrieb:

Falsch. Auch mit DAO ist es möglich ODBC Datenquellen anzusprechen.

Sorry, da hast Du natürlich Recht. Für mich ist und bleibt halt gedanklich DAO eine reines MS-Access Objektmodell.

(Ich bereite gerade die Portierung meines Gigaprojektes (bis jetzt 8 Jahre Entwicklungsarbeit) von VB6 mit DAO via MyODBC 3.51 auf .Net Technologien vor und bin auch dafür auf der Suche nach den richtigen Mitteln. Zunächst wird aber erst mal ein Kundenprojekt auf .Net Basis erstellt. An diese konsequente OOP-Programmierung muss ich mich erst mal gewöhnen.)

Auweia ... na dann viel Spaß, da wirste aber auch sehr lange beschäftigt sein.

Bin auch gerade dabei ein Entwicklung nach und nach auf VB.NET zu portieren (waren bis jetzt "nur" 3 Entwicklungsjahre, aber ist auch noch lange nicht fertig ^^).

Habe mich allerdings für einen Zwischenstep über COM-Dll's entschieden. Protiere nach und nach Funktionalitäten von Klassen und Module nach VB.NET in eine NET-Klassenbibliothek, auf die setze ich dann eine COM-Wrapper-Klasse auf die quasi nur als Schnittstelle zu den NET-Klassen fungiert. Und diese COM-Klassen binde ich in mein Projekt ein um die Klassen und Module deren Funktionalität ich nach NET protiert habe zu ersetzen.

Der Vorteil für mich dabei ist das die Portierung nach und nach geschieht, ich bei den Bausteine die bereits portiert sind nach jedem User-Update gleich mitbekomme ob alles wie gewünscht läuft und ich für neue Funktionalitäten bereits direkt auf die NET-Technologie zurück greifen kann.

Stelle mir dabei im Endeffekt vor, dass am Ende eine riesen Sammlung an NET-Klassenbibliotheken besteht und ich nur noch die Formulare und Programmlogiken für die endügltige Umstellung coden muss. Na ja ... man wird sehen. Vielleicht erweist es sich auch als gute/tragbare Lösung die Kombination Formulare /Programmlogik zu belassen und ansonsten alles mit Klassenbibliotheken zu regeln. Selbst Formulare kann man ja mit einer Klassenbibliothek mittlerweilen zur Verfügung stellen.

LNX ist da besonders schlimm, zumindest in der Version die beim Kunden vorlag

Jetzt wird mir auch klar wieso DAO-Objektmodell für OCDB.

Gruß

Rainer

LaMa5 schrieb:

(So der Plan, ob's auch hinhaut werde ich sehen )

Ich drück Dir die Daumen das alles so klappt wie Du es Dir vorstellst.

Das momentan größte Problem wird aber die Umstellung von DAO (verteilt über den gesamten Quellcode (teilweise noch Spaghetticode)) ...

Jau ... das kenne ich.

Über Deine Methode, mit der COM Wrapper Klasse und dem ansprechen im alten Programm, habe ich auch schon nachgedacht, ich Moment finde ich aber die Lösung, so wenig wie möglich in der alten Umgebung zu machen, irgendwie interessanter. Ich denke das es weniger Arbeit macht, weil im alten Code nicht "rumgefuscht" wird.

Vermutlich hast Du Recht, aber bei mir stellt sich schlicht das Thema das ich noch nebenbei neue Funktionalitäten anbauen muss und derzeit nicht die Zeit vorhanden ist, erstmal das Bestehende nach NET zu transportieren um dann nur noch über NET zu agieren. Das dadurch dann letztendlich doppelte Arbeit entsteht ist mir auch bewusst, aber so ist das halt ... das Ding war niemals so groß angedacht. Sollte eine kleine, sehr einfache CRM werden die nur ein paar Spezialitäten beherrscht und gut sollte es sein.

Wie so oft kam es dann anders als ich dachte ... Mensch, das würde doch noch gut passen oder das und das wäre auch toll und wenn es das könnte wäre es der Hit und wenn es dann noch kann wäre es genial ... etc., etc. ... . Irgendwann bemerkt man dann ... Verdammt, so war das nie geplant und überhaupt, aber gut bevor man jetzt alles umproggt baut man das halt doch noch mal schnell so ein.

Und jetzt hänge ich drinnen neue Funktionen nachzuliefern und aber auch die bestehende Basis nach und nach in NET zu portieren. Also langweilig wird es mir die nächsten 12 Monate mit absoluter Sicherheit nicht.

Gruß

Rainer