Benutzer mit den meisten Antworten
Access Datenbank mit DAO nutzen?

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!
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 VerwaltungstoolsGruß Elmar
- Als Antwort vorgeschlagen Thorsten Dörfler Mittwoch, 8. Juni 2011 19:46
- Als Antwort markiert Robert Breitenhofer Mittwoch, 13. Juli 2011 11:15
-
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
- Als Antwort vorgeschlagen Thorsten Dörfler Mittwoch, 8. Juni 2011 19:46
- Als Antwort markiert Robert Breitenhofer Mittwoch, 13. Juli 2011 11:15
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 VerwaltungstoolsGruß Elmar
- Als Antwort vorgeschlagen Thorsten Dörfler Mittwoch, 8. Juni 2011 19:46
- Als Antwort markiert Robert Breitenhofer Mittwoch, 13. Juli 2011 11:15
-
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.
-
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
- Als Antwort vorgeschlagen Thorsten Dörfler Mittwoch, 8. Juni 2011 19:46
- Als Antwort markiert Robert Breitenhofer Mittwoch, 13. Juli 2011 11:15
-
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
-
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:
Damit das flexibel wird, würde man die statischen Spalten durch OleDbParameter zu ersetzen.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
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
-
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 -
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? -
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
-
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-AnwendungAber das wäre für später... die Möglichkeiten sind aber da.
Gruß Elmar
-
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 SeriesGruß Elmar
-
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. -
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...
-
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 SchichtenarchitekturDas 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:
- sp_executesql in Transaktion
- Datset, 2 Comboboxen, 1 Datagridview und alles miteinander verbinden
- 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
-
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?