none
Access Datenbank mit DAO nutzen? RRS feed

  • Frage

  • Hallo,

    bisher hab ich VB6 genutzt und kam mit dem DAO zugriff gut zurecht...

    Jetzt will ich erste Schritte in VB2010 probieren scheitere aber schon daran, daß ich nich weiß, wie ich DAO in VB benutze. Den Verweis DAO3.6 habe ich aktiviert... aber was passiert dann!? Den gewohnten weg über workspaces scheint je jedenfalls nich mehr zu geben!? Wie komme ich da weiter?

     

    Lieben Dank!

    Dienstag, 7. Juni 2011 07:59

Antworten

  • Hallo,

    prinzipiell kann man DAO auch mit VB.NET nutzen.
    Dazu musst Du eine DBEngine Instanz selbst erzeugen, was bei VB Classic noch im Hintergrund geschah.

    Ich würde Dir aber raten von DAO Abschied zu nehmen.
    Denn für DAO gibt es keine Unterstützung durch Visual Basic und das .NET Framework.
    Auch wirst Du dazu kaum Tutorials oder andere Lektüre finden.

    Wenn Du Dich mit Visual Basic 2010 vertraut machen willst,
    solltest Du Dich in den ADO.NET Datenzugriff einarbeiten.

    An unterster Stelle stände dort der Zugriff über die ADO.NET Provider, was bei Access / Jet
    der OleDbClient erledigt, siehe Abrufen und Ändern von Daten in ADO.NET
    Die dann mit DataSets zusammenarbeiten, siehe DataSets, DataTables und DataViews (ADO.NET)

    Aktuellste Technologie wäre das Entity Framework.
    Dafür gibt es jedoch keine Jet-Unterstützung mehr
    und Du solltest Dir dafür SQL Server 2008 R2 Express installieren
    oder auch Microsoft SQL Server 2008 R2 RTM – Express mit Verwaltungstools

    Gruß Elmar

     

    Dienstag, 7. Juni 2011 09:28
  • Hallo Martin,

    wenn Du "vorankommen" willst, so vergisst Du zuerst, alles was Du glaubst zu wissen.
    Und ohne einige Anstrengung wird das vermutlich auch nicht abgehen.

    Visual Basic .NET hat mit Visual Basic Classic (5/6) nur Teile der Syntax und zwei Worte im Namen gemein.
    DAO war bereits mit Visual Basic 6 veraltet und wird heute nur noch bei Microsoft Access genutzt.
    Die Microsoft Jet Engine wird mittlerweile von dem Office (Access) Team gepflegt
    und die breite Unterstützung anderer Entwicklungsumgebung ist (bedauerlicherweise) entfallen.
    ADO.NET hat mit dem älteren ADO (Ole Db) nur drei Buchstaben gemein und beim OleDb Client wird nur Ole Db genutzt.

    ADO.NET wurde (im Jahre 2001/2) bewusst einfach gehalten, um eine breite Unterstützung
    seitens anderer Anbieter zu erhalten (und war erfolgreich - etwas was ADO (OleDb) nie erfahren hat).

    Das Jonglieren mit Recordsets ist dort passé. Vom Konzept wird auf einen verbindungslosen Zugriff gesetzt,
    der über die bereits erwähnten DataSets läuft - die die Daten zwischenzeitlich im Speicher abbilden.
    Um SQL Befehle zu erzeugen verwendet man dann TableAdapter.

    Mittlerweile sind die DataSets auch in die (10) Jahre gekommen.
    Und neuere Entwicklungsumgebungen wie z. B. für Silverlight bieten dafür keine Unterstützung.
    Deswegen der Hinweis auf das Entity Framework, das auch in diesen Umgebungen unterstützt wird.
    (z. B. WCF RIA Services). Wo es aber keine Jet Unterstützung mehr gibt.

    Willst Du Dich mit diesen Dingen nicht herumschlagen und nur schnelle Ergebnisse vorweisen,
    so empfehle ich Dir den Blick auf Visual Studio Light Switch. Auch wenn derzeit noch Beta
    zielt sie auf Entwickler, die Oberflächen auf standardisierte Weise entwickeln wollen -
    und ist ein Ersatz für die klassische RAD Entwicklungsumgebung mit der Visual Basic (Classic) mal angetreten ist.

    Gruß Elmar

     

     

    Mittwoch, 8. Juni 2011 07:04

Alle Antworten

  • Hallo,

    prinzipiell kann man DAO auch mit VB.NET nutzen.
    Dazu musst Du eine DBEngine Instanz selbst erzeugen, was bei VB Classic noch im Hintergrund geschah.

    Ich würde Dir aber raten von DAO Abschied zu nehmen.
    Denn für DAO gibt es keine Unterstützung durch Visual Basic und das .NET Framework.
    Auch wirst Du dazu kaum Tutorials oder andere Lektüre finden.

    Wenn Du Dich mit Visual Basic 2010 vertraut machen willst,
    solltest Du Dich in den ADO.NET Datenzugriff einarbeiten.

    An unterster Stelle stände dort der Zugriff über die ADO.NET Provider, was bei Access / Jet
    der OleDbClient erledigt, siehe Abrufen und Ändern von Daten in ADO.NET
    Die dann mit DataSets zusammenarbeiten, siehe DataSets, DataTables und DataViews (ADO.NET)

    Aktuellste Technologie wäre das Entity Framework.
    Dafür gibt es jedoch keine Jet-Unterstützung mehr
    und Du solltest Dir dafür SQL Server 2008 R2 Express installieren
    oder auch Microsoft SQL Server 2008 R2 RTM – Express mit Verwaltungstools

    Gruß Elmar

     

    Dienstag, 7. Juni 2011 09:28
  • ADO hab ich mir schon mal angesehen, klappt auch recht einfach...

     

    Ich hab allerdings ein paar Sachen da vermisst bzw. nicht gefunden.

    So nette sachen wie "movelast", "movefirst" etc. hab ich auf die schnelle nich gefunden. das was ging war ein "oneway"

    auch kann man über DAO so schön mit rec.edit und dann rec.update arbeiten. Das SQL Update ist da auch etwas unschöner zu bedienen finde ich. so unleserlich...

     

    Neben vb2010 zu "lernen" noch dazu dann den sql server ist mir zu "anstrengend". ich muß ja auch vorankommen... daher würd ich schon gern mit access weitermachen erstmal.

    Dienstag, 7. Juni 2011 19:56
  • Hallo Martin,

    wenn Du "vorankommen" willst, so vergisst Du zuerst, alles was Du glaubst zu wissen.
    Und ohne einige Anstrengung wird das vermutlich auch nicht abgehen.

    Visual Basic .NET hat mit Visual Basic Classic (5/6) nur Teile der Syntax und zwei Worte im Namen gemein.
    DAO war bereits mit Visual Basic 6 veraltet und wird heute nur noch bei Microsoft Access genutzt.
    Die Microsoft Jet Engine wird mittlerweile von dem Office (Access) Team gepflegt
    und die breite Unterstützung anderer Entwicklungsumgebung ist (bedauerlicherweise) entfallen.
    ADO.NET hat mit dem älteren ADO (Ole Db) nur drei Buchstaben gemein und beim OleDb Client wird nur Ole Db genutzt.

    ADO.NET wurde (im Jahre 2001/2) bewusst einfach gehalten, um eine breite Unterstützung
    seitens anderer Anbieter zu erhalten (und war erfolgreich - etwas was ADO (OleDb) nie erfahren hat).

    Das Jonglieren mit Recordsets ist dort passé. Vom Konzept wird auf einen verbindungslosen Zugriff gesetzt,
    der über die bereits erwähnten DataSets läuft - die die Daten zwischenzeitlich im Speicher abbilden.
    Um SQL Befehle zu erzeugen verwendet man dann TableAdapter.

    Mittlerweile sind die DataSets auch in die (10) Jahre gekommen.
    Und neuere Entwicklungsumgebungen wie z. B. für Silverlight bieten dafür keine Unterstützung.
    Deswegen der Hinweis auf das Entity Framework, das auch in diesen Umgebungen unterstützt wird.
    (z. B. WCF RIA Services). Wo es aber keine Jet Unterstützung mehr gibt.

    Willst Du Dich mit diesen Dingen nicht herumschlagen und nur schnelle Ergebnisse vorweisen,
    so empfehle ich Dir den Blick auf Visual Studio Light Switch. Auch wenn derzeit noch Beta
    zielt sie auf Entwickler, die Oberflächen auf standardisierte Weise entwickeln wollen -
    und ist ein Ersatz für die klassische RAD Entwicklungsumgebung mit der Visual Basic (Classic) mal angetreten ist.

    Gruß Elmar

     

     

    Mittwoch, 8. Juni 2011 07:04
  • Hallo Elmar,

    lieben Dank schon mal für Deine Geduld;)

    Ich hab mir das Light Switch mal angesehen in dem Tutorial. Aber ich glaube, das passt nicht ganz für mich. Ich will kein Telefonbuch entwickeln oder eine Adressdatenbank. Das aktuelle Projekt geht mehr in Kassenbereich über Kassentastatur und Abrechnungserstellung. Da ist mir (wie die Formularseite in Access) das zu statisch.

    Ich hab mal gesucht und ein Beispiel adaptiert... Zuerst mit einem SELECT Statement. Das Vorwärtsgerichtete ist dabei auch - denk ich - gar nich das Problem. Somit müßte ich Abfragen gut erstellen können und die Daten in meinem Programm auswerten. Jetzt muß ich eben noch Daten ändern oder Neue Datensätze erstellen. Das ändern über UDATE scheint mit dem Reader zu gehen, ich gehe davon aus, daß das INSERT INTO genauso geht...

     

    Liege ich so gänzlich daneben?

     

    Imports System.Data.OleDb
    
    Public Class Form1
    
      Private con As New OleDbConnection
    
      Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim cmd As New OleDbCommand
        Dim reader As OleDbDataReader
    
        con.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\DB.mdb"
    
        Try
          cmd.Connection = con
          cmd.CommandText = "UPDATE tabProdukte SET tabProdukte.verkH = ""Test"" WHERE (((tabProdukte.verkID)=2));"
    
          con.Open()
          reader = cmd.ExecuteReader
    
          reader.Close()
          con.Close()
    
        Catch ex As Exception
          MessageBox.Show(ex.Message)
        End Try
    
      End Sub
    
    End Class
    

    Donnerstag, 9. Juni 2011 06:28
  • Hallo Martin,

    LightSwitch muss nicht statisch bleiben, und eignet sich für mehr als "Kinderkram"
    (wie im übrigen auch Microsoft Access -> ich war auch mal Access MVP ;-)
    Zu LightSwitch siehe z. B.:
    Contoso Construction - LightSwitch Advanced Development Sample
    Walkthrough of a Real-World LightSwitch Application used at Microsoft
    und Du solltest mehr als einen Blick darauf verschwenden.
    Aber die Entscheidung liegt letztendlich (wie immer) bei Dir.

    Willst Du als Real Programmer durchgehen ;-), und alles selbst machen,
    so steht einiges mehr auf dem Programm.

    Du fängst Du zwar die Ausnahme ab, der Reader und die Verbindung bleiben dabei aber offen.
    Auf Dauer gehen Dir dann u. U. die Verbindungen aus  - Access/Jet mag max. 255 davon.
    Wenn Du eine globale Verbindung verwendest, sollte diese nach einer Ausnahme als "unzuverlässig"
    geschlossen und freigegeben werden. Sinnvoller ist i. a. jedoch sich auf das Connection Pooling einzulassen.

    Für eine Aktualisierung verwendet man üblicherweise ExecuteNonQuery, da (hier) kein Ergebnis
    zurückgegeben wird. Und wertet dafür die Rückgabe der Zeilenzahl aus.

    Das könnte als Methode implementiert dann (mit einer lokalen Verbindung) so aussehen:

      Try
       Using con As New OleDbConnection(ConnectionString)
         cmd.Connection = con
         cmd.CommandText = "UPDATE tabProdukte SET tabProdukte.verkH = ""Test"" WHERE (((tabProdukte.verkID)=2));"
        
    	 con.Open()
    	 return cmd.ExecuteNonQuery()
        End Using
      Catch ex As Exception
       MessageBox.Show(ex.Message)
      End Try
    
    
    Damit das flexibel wird, würde man die statischen Spalten durch OleDbParameter zu ersetzen.
    Entsprechendes gälte für INSERT und DELETE wie auch DDL Anweisungen.

    Einfacher kannst Du Dir das Leben machen, in dem Du DataSets in Verbindung mit TableAdaptern einsetzt.
    Die kann man um Befehle erweitern, siehe Gewusst wie: Erstellen von parametrisierten TableAdapter-Abfragen
    Die fungieren damit als Datenzugriffschicht.

    Gruß Elmar

     

    Donnerstag, 9. Juni 2011 07:44
  • Hallo ihr 2,

     

    Elmar hat mit seinen Aussagen vollkommen recht was das ADO.NET angeht, ich kann dir nur empfehlen das du versuchst dich in ADO.NET einzuarbeiten wenn du mit .NET arbeiten möchtest.

    Ich bin auch gerade beim Umstieg von VBA auf .NET und manchmal finde ich das auch unschön :D

    Wenn ich Aufgaben erledigen muss die schnell gehen sollen ist es natürlich verlockend auf die alten Technologien zu setzen.

    Daher kannst du auch mit ADO (nicht ADO.NET) arbeiten, wovon ich dir aber abraten würde falls dies nicht dein einziges .NET-Projekt bleiben soll ;)

    Ist es jedoch nur was kleines und man weiß genau das man es nicht nochmal benötigt, dann ist der zu betreibende Lernaufwand viel zu hoch, denn da steckt schon einiges dahinter.

    Falls du eine gute Lektüre für Datenbankprogrammierung mit .NET suchst, kann ich dir das Buch hier empfehlen.

    Wenn .NET dann richtig, auch wenn es am Anfang n riesiger Berg Arbeit ist :D


    Cheers, Jörn Bosse
    Microsoft Student Partner
    Freitag, 10. Juni 2011 07:53
  • hey! ;)

     

    ich bin leicht verwirrt....

    Mit meinem Beispiel oben liege ich doch bei ADO.NET, oder!?????

    Samstag, 11. Juni 2011 07:53
  • ok...

    also....

    ich hab jetzt über "Daten-Neue Datenquelle hinzufügen" meine Access Datenbank hinzugefügt und dann das dataset zu der Form1 hinzugefügt...

     

    Will ich jetzt daten in einer tabelle als neue zeile hinzufügen hab ichs jetzt mal so probiert:


    Public Class Form1
    
      Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim newRegionRow As VerkaufsDBDataSet.tabProdukteRow
        Dim customersTableAdapter As New VerkaufsDBDataSetTableAdapters.tabProdukteTableAdapter()
    
        newRegionRow = VerkaufsDBDataSet1.tabProdukte.NewtabProdukteRow
    
        newRegionRow.verkKurzBez = "RolloB"
        newRegionRow.verkProdukt = "Rollo kleinB"
        newRegionRow.verkHersteller = "HariboB"
    
        VerkaufsDBDataSet1.tabProdukte.Rows.Add(newRegionRow)
    
        customersTableAdapter.Update(newRegionRow)
    
      End Sub
    
    End Class
    
    

    gleich mal die frage dazu. wenn ich da jetzt ne exe-datei draus mache liegt die datenbank ja ggf. nachher an einer anderen stelle als jetzt. wo stelle ich das dann individuell ein?
    Samstag, 11. Juni 2011 10:47
  • Hallo Martin,

    Du liegst schon richtig mit dem Beispiel.

    Die Aussage von Jörn ist im Hinblick auf meine zu sehen:
    ADO.NET hat mit dem älteren ADO (Ole Db) nur drei Buchstaben gemein und beim OleDb Client wird nur Ole Db genutzt.

    Und ihm geht es im Prinzip so wie Dir nur das es bei Dir von DAO -> ADO.NET geht.

    Gruß Elmar

     

    Samstag, 11. Juni 2011 14:40
  • Hallo Martin,

    wenn Du das DataSet über den Designer erstellt hast wie zu vermuten,
    so wird die Verbindungszeichenfolge in den Anwendungs-Einstellungen hinterlegt -
    die findest Du wenn Du in den Projekt-Eigenschaften unter Einstellungen guckst.

    Dort kannst Du die Verbindungszeichenfolge ändern.

    Da bei Visual Basic Express nur Click-Once direkt unterstützt wird:
    Dort wird das Verzeichnis über das |DataDirectory| variabel gestaltet:
    Zugreifen auf lokale und Remotedaten in einer ClickOnce-Anwendung

    Aber das wäre für später... die Möglichkeiten sind aber da.

    Gruß Elmar

     

    Samstag, 11. Juni 2011 14:47
  • könnt ich bitte mal ein kleines beispiel haben, wie ich ein sql-abfrage über dieses dataset mache!?
    Sonntag, 12. Juni 2011 08:22
  • Hallo Martin,

    eine genauere Beschreibung, was Du abfragen möchtest, wäre hilfreich.

    Beachte, dass die generierten Standard-Abfragen die gesamte Tabelle in das DataSet laden.
    Wenn Du das getan hast, kann Du auf die DAten über die DataTable Select-Methode filtern
    oder eine DataView  mit Filterung und Sortierung erstellen.

    Willst Du hingegen nur Teile der Tabelle in das DataSet laden, wäre der bereits gegebene Link:
    Gewusst wie: Erstellen von parametrisierten TableAdapter-Abfragen der Weg.

    Hilfreich fürs Verständnis könnte auch die Video Serie von Beth Massi sein:
    Forms over Data Video Series

    Gruß Elmar

     

    Sonntag, 12. Juni 2011 08:34
  • Ich benötige zumeist einzelne datensätze die anhand gewisser Kriterien ausgewählt werden.

    Beispiel:

    ich habe eine EAN und benötige zu dieser den Produktnamen und den Preis.


    Stell es Dir als einfache Kasse vor. Ich hole mir ein paar Daten, sammle diese und schreibe dann in eine andere Tabelle einen datensatz, der aus dem Ergebnis des Vorgangs entsteht.
    Sonntag, 12. Juni 2011 10:23
  • Also...

    ich hab mir das mit den DataSet noch mal in nem Buch angesehen.

    Ich habe den Eindruck, daß das an meinem Bedarf vorbei geht....

    Zum einen werde ich nie einen Datensatz oder Tabellen direkt in dem Programm von einem User bearbeiten lassen. Es werden einzelne Daten - mitunter wirklich nur ein einziges 'Datum' - über div. Parameter - und das geht wohl doch am besten über SQL (?) benötigt. Und Gespeichert werden im Allgemeinen einzelne neue Zeilen, die aber durch das Programm in die Datenbank geschrieben werden sollen, ein User hat keinerlei Zugriff auf die Datenbank....

    Ganze Tabellen in den Speicher laden halte ich auch für Übertrieben und ich will keine Tabellen in dem Programm abbilden oder Datenbankfunktionalitäten wie Datensatz vor und zurück oder so einbetten. Und teilweise MÜSSEN Daten auch ohne wartezeit oder zwischenspeicherung in die Datenbank eingetragen werden. Also Abbilden bearbeiten und nur "ab und an" auf Kommando speichern ist für meine Anwendung mindestens stellenweise schlecht, da es Vorgaben vertraglicher Natur gibt, die z.B. erst das Speichern in der Datenbank verlangen und dann das Erstellen des Ausdrucks vorsehen... Das Speichern könnte man dann zwar natürlich im Code jedesmal anstoßen, aber das würde ja - wenn ich das verstehe - dem Sinn dieser Architektur etwas wiedersprechen...

     

     

    Montag, 13. Juni 2011 18:48
  • Hallo Martin,

    denkst Du wirklich, es hätten die letzten 10 Jahren - in denen Du Dich an DAO geklammert hast -
    alle anderen Entwickler an ihrem Bedarf vorbei programmiert.

    Schau bitte mal über Deinen Tellerrand: Google liefert da reichlich.
    Fakt ist das eine direkte Kopplung mit der Datenbank vermeidet, siehe Schichtenarchitektur

    Das DataSet ist eine frühe Inkarnation, heute geht, wie bereits geschrieben, die Tendenz zum ORM (Entity Framework) -
    konzeptionell bleibt es aber auch dort: Direktes SQL ist tabu.
    Eine Erkenntnis, die man anderswo (u. a. Java) vor noch längerem gemacht hat.

    Zu Deinen Erkenntnissen:
    Niemand sagt das man "ganze Tabellen in den Speicher laden" sollte.
    Niemand fordert, dass Du nicht jede Änderung sofort speichern kannst (nachdem Du sie auf Gültigkeit geprüft hast, natürlich).

    Und wenn ich die Wahl habe zwischen:

    1. sp_executesql in Transaktion
    2. Datset, 2 Comboboxen, 1 Datagridview und alles miteinander verbinden
    3. Bitte um Hilfe bei LinQ

    nehme ich 3. und wenn nötig die 2.) - auch wenn ich das 1. (auch) kann -
    denn auf endlose SQL Bastelstunden habe ich keinen Bock mehr ;-)

    Gruß Elmar


    Montag, 13. Juni 2011 19:44
  • entschuldige bitte, daß das für mich neuland ist und ich mich damit halt etwas schwer tue.

     

    So, nun hab ich also den TableAdaptor-Konfigurationsassistenten benutzt und mir eine Abfrage gebastelt. Klappt in dem Asisstente auch gut...

     Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim tabDataSet As New KasseDataSet()
        Dim tabTableAdaptor As New KasseDataSetTableAdapters.TastefindenTableAdapter
    
    
        tabTableAdaptor.GetData(1214)
    
    
    
    
      End Sub

    wie kann ich jetzt auf die daten zugreifen? Wie kann ich einen einzelnen wert aus der tabelle abfragen?


    Dienstag, 14. Juni 2011 08:26