<\/p>\n
Wer einen Webserver sein Eigen nennt oder anderweitig Gelegenheit zum Ablegen von Daten in einer MySQL-Datenbank hat, kann dies für verschiedene Zwecke nutzen: Primär sollen Datenbanken auf Webservern natürlich Inhalte für Internetseiten liefern, aber Sie können diese natürlich auch einfach als zentrale Datenbasis verwenden und von überall auf diese zugreifen. Wenn dies auch noch in akzeptabler Zeit gelingen soll, müssen Sie jedoch einige Regeln beachten.<\/b><\/p>\n
Wenn Sie direkt auf eine Datenbank auf einem Webserver zugreifen können, ergeben sich eine ganze Menge Möglichkeiten.<\/p>\n
Sie können nicht nur, wie oben beschrieben, Daten zentral speichern und dann von überall darauf zugreifen, sondern natürlich auch mehreren Personen gleichzeitig Zugriff auf die Daten verschaffen.<\/p>\n
Außerdem sparen Sie sich damit unter Umständen die aufwendige Programmierung von Web-Backends für die Datenbanken Ihrer Webseiten: Sie können die Daten nämlich, eine geeignete Verbindung und Access-Anwendung vorausgesetzt, ganz einfach per Formular ändern oder per Bericht anzeigen lassen.<\/p>\n
Dies ändert natürlich nichts an der Tatsache, dass Sie für die Besucher der Webseite ein HTML-Frontend bauen müssen, aber in vielen Fällen stellt die Administration der auf der Webseite dargestellten Daten eine wesentlich höhere Herausforderung als die eigentliche Webseite dar.<\/p>\n
Was brauchen Sie, um vom vorliegenden Beitrag profitieren zu können Da wäre als Erstes eine MySQL-Datenbank irgendwo auf einem Webserver und zweitens die Möglichkeit, per ODBC darauf zuzugreifen – sei es direkt oder über den Umweg eines Tunnels, wie im Beitrag Access und MySQL <\/b>(Shortlink 240) beschrieben.<\/p>\n
Dies zieht nach sich, dass Sie auf Ihrem lokalen Rechner einen ODBC-Connector für die MySQL-Datenbank installieren müssen. Die aktuellste Version finden Sie unter dem Link http:\/\/dev.mysql.com\/downloads\/connector\/odbc\/5.1.html<\/b>. Als Nächstes müssen Sie die Verbindungsparameter für den Aufbau einer Verbindung zum MySQL-Server auf dem Webserver ermitteln. Eine gute Anlaufstelle finden Sie unter http:\/\/www.connectionstrings.com\/<\/b>.<\/p>\n
Der Standardweg<\/b><\/p>\n
Normalerweise würden Sie die Tabellen der MySQL-Datenbank mit dem Access-Frontend per ODBC verknüpfen. Dies funktioniert insbesondere deshalb sehr gut, weil Sie die Tabellen fast genau wie in der lokalen Access-Datenbank enthaltene Tabellen behandeln können – sie lassen sich in Abfragen zusammenführen, an Formulare, Berichte und die enthaltenen Steuerelemente binden und auch der Zugriff per ADO oder DAO geschieht problemlos.<\/p>\n
Dummerweise gibt es ein Problem: Wenn die Datenmenge wächst oder Abfragen über mehrere Tabellen abgefragt werden sollen, gerät etwa die Anzeige von Daten in einem Formular mitunter zum Geduldsspiel.<\/p>\n
Welche Alternativen gibt es hierzu Wenn es um das reine Anzeigen von Daten geht, diese also nicht bearbeitet werden sollen, können Sie PassThrough<\/b>-Abfragen verwenden.<\/p>\n
Diese unterscheiden sich dadurch von herkömmlichen Abfragen, dass sie erstens im nativen SQL-Dialekt des DBMS formuliert sein müssen, die Angabe einer entsprechenden ODBC-Verbindung erfordern und außerdem einen entscheidenden Nachteil haben: sie lassen keine Veränderungen an den gelieferten Daten zu.<\/p>\n
Und damit kommen wir zur Methode dieses Beitrags: Der Zugriff erfolgt ausschließlich über ADO-Recordsets und unterscheidet sich somit wesentlich von den üblicherweise verwendeten Möglichkeiten zum Binden von Formularen, Berichten und Steuerelementen an Datenherkünfte wie Tabellen oder Abfragen. <\/p>\n
Wie aber können wir ein Formular, einen Bericht oder auch ein Kombinationsfeld mit Daten füllen, auf die wir nur per ADO zugreifen ADO wird doch normalerweise ausschließlich in VBA-Prozeduren verwendet<\/p>\n
Per VBA, ADODB und ODBC auf eine Tabelle zugreifen<\/b><\/p>\n
Beginnen wir gleich dort, nämlich beim Einlesen von Daten via VBA, DAO und ODBC. Kern dieser Vorgehensweise sind wie üblich ein Connection<\/b>– und ein Recordset<\/b>-Objekt, die allerdings etwas anders als sonst üblich gefüllt werden. Als Beispieltabellen verwenden wir vier einfache Tabellen, deren Beziehungen wie in Bild 1 aufgebaut sind. Um die wichtigsten Fälle abzudecken, haben wir eine 1:n- und eine m:n-Beziehung eingebaut.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2010_01\/MySQLDirekt-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Datenmodell der Beispieldatenbank<\/span><\/b><\/p>\n Diese haben wir in Access erstellt und mit den im Beitrag Von Access nach MySQL <\/b>(Shortlink ****) beschriebenen Techniken in eine auf einem Webserver liegende MySQL-Datenbank migriert. Wenn wir mit ADO arbeiten, was in diesem Fall die schnellste Variante ist, benötigen wir zunächst einmal ein Connection<\/b>-Objekt. Da eine Anwendung meist über mehrere Formulare verfügt und diese alle schnell mit Daten gefüllt werden sollen, machen wir das Connection<\/b>-Objekt über eine globale Funktion verfügbar. Die folgenden Codezeilen liegen alle in einem Standardmodul namens mdlMySQL<\/b>. Den Start macht die Deklaration einer Connection<\/b>-Variablen zum Speichern eines Verweises auf die aktuelle Verbindung:<\/p>\n Damit wir den Connectionstring nicht an verschiedenen Stellen ändern müssen, wenn dies einmal notwendig ist, schreiben wir ihn in eine Konstante:<\/p>\n Die folgende Funktion liefert schließlich ein Connection<\/b>-Objekt. Dabei prüft sie, ob schon ein Connection-Objekt vorliegt, und gibt dieses zurück – falls nicht, erzeugt sie eine neue Verbindung:<\/p>\n Beachten Sie bitte, dass es einen serverseitigen Timeout gibt. Gegebenenfalls ist die Connection nach einer halben Tasse Kaffee nicht mehr verfügbar. Hier müssen Sie entweder serverseitig den Timeout erhöhen oder anderweitige Maßnahmen treffen.<\/p>\n Recordset erzeugen<\/p>\n Wie oben erwähnt, möchten wir ausschließlich auf der Basis von Recordsets arbeiten. Da bietet es sich an, genau wie bei den Connection<\/b>-Objekten eine Funktion zu bauen, welche die gewünschten Recordsets zurückliefert. Die Funktion GetRecordset <\/b>erwartet zwei Parameter:<\/p>\n Die Funktion stellt einige Parameter für das zu erzeugende Recordset<\/b>-Objekt ein, öffnet dieses und gibt einen Verweis darauf als Funktionswert zurück:<\/p>\n Formular mit Daten füllen<\/b><\/p>\n Kommen wir nun zum eigentlichen Thema: dem Füllen eines Formulars mit Daten einer MySQL-Datenbank auf einem Webserver. Den größten Teil der Arbeit haben wir bereits erledigt, fehlt nur noch das passende Formular. Dieses soll im ersten Beispiel die Daten der Tabelle tblKunden <\/b>als einzelne Datensätze anzeigen. Die Beispieldatenbank enthält noch die für das Erstellen der MySQL-Datenbank verwendeten Tabellen inklusive Daten, sodass Sie diese zunächst zum Füllen des Formulars mit den benötigten Feldern verwenden können. Erstellen Sie dazu ein neues, leeres Formular, stellen Sie die Eigenschaft Datenherkunft <\/b>auf die Tabelle tblKunden <\/b>ein und ziehen Sie alle Felder der Tabelle aus der Feldliste in den Entwurf des Formulars (siehe Bild 2). Leeren Sie nun unbedingt die Eigenschaft Datenherkunft <\/b>wieder – schließlich möchten wir nicht die Daten der lokalen Tabelle anzeigen, sondern die vom Webserver. Damit dies gelingt, legen Sie nun eine Ereignisprozedur für die Ereigniseigenschaft Beim Laden <\/b>des Formulars an. Füllen Sie diese wie folgt:<\/p>\n Bild 2: Entwurf des ersten Beispielformulars<\/span><\/b><\/p>\n Wenn Sie nun in die Formularansicht wechseln, erscheinen die gewünschten Datensätze. Sie können diese ändern und löschen und auch neue Datensätze anlegen.<\/p>\n 1:n-Beziehung abbilden<\/b><\/p>\n 1:n-Beziehungen lassen sich auf zwei Arten abbilden, und zwar aus der Sicht jeder einzelnen der beiden beteiligten Tabellen.<\/p>\n Im ersten Beispiel wollen wir einen Kunden zu einer Bestellung auswählen, was mit einem Kombinationsfeld geschieht. Im zweiten Beispiel sollen alle Bestellungen zu einem Kunden aufgelistet werden.<\/p>\n Kombinationsfelder füllen<\/b><\/p>\n Der interessante Teil beim Abbilden einer 1:n-Beziehung aus Sicht des Bestellungsdatensatzes ist das Kombinationsfeld zum Auswählen des Kunden.<\/p>\n Das Formular zu diesem Beispiel heißt frmBestellung<\/b> und zeigt alle Felder der Tabelle tblBestellungen <\/b>an. Die Felder fügen Sie am einfachsten wie oben beschrieben hinzu, indem Sie zunächst die lokale Tabelle tblBestellungen<\/b> als Datenherkunft einstellen, die Felder ins Formular ziehen und die Datenherkunft wieder leeren. Danach legen Sie die folgende Prozedur für das Ereignis Beim Laden <\/b>an:<\/p>\n Danach funktioniert das Formular gleich wie gewünscht – es zeigt sogar die Daten aus der Tabelle tblKunden <\/b>im Kombinationsfeld zur Auswahl des Kunden an (siehe Bild 3).<\/p>\n Bild 3: Das Kombinationsfeld ist bereits gefüllt, aber aus der falschen Quelle.<\/span><\/b><\/p>\n Allerdings stammen diese Daten natürlich nicht vom Webserver, sondern aus der lokalen Tabelle. Die notwendige Datensatzherkunft des Formulars wurde beim Hinzufügen der Felder auf Basis der lokalen Tabelle tblBestellungen<\/b> eingetragen.<\/p>\n Wir wollen aber alle Daten von der Datenbank auf dem Webserver beziehen. Wechseln Sie also in die Entwurfsansicht des Formulars, markieren Sie das Kombinationsfeld zur Auswahl des Kunden und leeren Sie dessen Eigenschaft Datensatzherkunft<\/b>.<\/p>\n Beim nächsten Wechseln in die Formularansicht ist das Kombinationsfeld leer, was auch logisch ist: Es enthält zwar den Wert des Feldes KundeID <\/b>der dem Formular als Recordset zugewiesenen Tabelle tblBestellungen<\/b>, diese wird jedoch nicht angezeigt, weil die Einstellungen der Eigenschaften Spaltenanzahl <\/b>und Spaltenbreiten <\/b>dafür ausgelegt sind, den Inhalt des zweiten Felds der Datensatzherkunft des Kombinationsfelds anzuzeigen – und da diese leer ist, zeigt das Formular eine leere Zeichenkette an. Da es nicht leer ist, können Sie durch das Einstellen der Eigenschaften Spaltenanzahl <\/b>und Spaltenbreiten <\/b>auf 1 <\/b>und 3cm <\/b>nachweisen.<\/p>\n <\/p>\n Damit das Kombinationsfeld die auf dem Webserver gespeicherten Kundennamen zur Auswahl anbietet, müssen wir auch dessen Recordset<\/b>-Eigenschaft mit einem Verweis auf das entsprechend Recordset füllen. Dazu erweitern Sie die Beim Laden<\/b>-Ereignisprozedur von oben um die folgende Zeile:<\/p>\n Dies zeigt nun die gewünschten Kunden an. Statt des Nachnamens sollen die Kundendaten in einem weiteren Schritt in der Form Nachname, Vorname <\/b>angezeigt werden. Normalerweise würden wir die SQL-Abfrage dazu wie folgt ändern:<\/p>\n Dies funktioniert jedoch nicht: Das Kombinationsfeld zeigt zwar die richtige Anzahl Datensätze an, allerdings ohne Angabe des Kundennamens.<\/p>\n Der Grund ist einfach: Wenn wir Abfragen wie hier per ADO direkt an den SQL-Server absetzen, müssen diese im SQL-Dialekt des jeweiligen SQL-Servers, hier MySQL, formuliert werden. Und MySQL verwendet zum Konkatenieren von Feldern die CONCAT<\/b>-Funktion. Die SQL-Abfrage muss also so aussehen:<\/p>\n Nun zeigt das Kombinationfeld die gewünschten Ausdrücke an und erlaubt auch deren änderung. Alternativ können Sie auch eine PassThrough-Abfrage als Datensatzherkunft verwenden.<\/p>\n 1:n-Beziehung mit Unterformular<\/b><\/p>\n Die umgekehrte Ansicht soll alle Bestellungen zu einem Kunden anzeigen. Dazu benötigen wir ein Listen-Steuerelement wie ein Listenfeld oder ein Unterformular in der Datenblatt- oder Endlosansicht. In diesem Fall verwenden wir ein Unterformular in der Datenblattansicht. Das Hauptformular soll alle Kunden-Daten anzeigen, weshalb Sie das Formular frmKunden <\/b>aus dem ersten Beispiel weiterverwenden können.<\/p>\n Das Unterformular zum Anzeigen der Bestellungen soll sfmKunden <\/b>heißen und erhält zunächst die Tabelle tblBestellungen <\/b>als Datenherkunft, damit Sie die gebundenen Felder schnell zum Entwurf hinzufügen können. Danach leeren Sie die Datenherkunft, schließen das Formular und fügen es dem Formular frmKunden <\/b>als Unterformular hinzu – am einfachsten gelingt dies, indem Sie frmKunden <\/b>im Entwurf öffnen und das Formular sfmKunden <\/b>aus dem Datenbankfenster in den Detailbereich ziehen. Das Ergebnis sieht dann wie in Bild 4 aus. ändern Sie den Steuerelementtyp des Felds KundeID <\/b>in Textfeld – es dient später nur der Prüfung, ob das Feld den richtigen Standardwert aufweist, und kann anschließend entfernt werden.<\/p>\n Bild 4: Kunden und ihre Bestellungen in Haupt- und Unterformular<\/span><\/b><\/p>\n Wenn Sie nun nur das Unterformularsteuerelement markieren und im Eigenschaftsfenster zur Registerseite Daten <\/b>wechseln, finden Sie die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>leer vor. Normalerweise sollte Access automatisch die Beziehung zwischen den beiden Tabellen tblKunden <\/b>und tblBestellungen <\/b>erkennen und das Feld KundeID <\/b>für beide Eigenschaften eintragen. Dies führt normalerweise dazu, dass das Unterformular automatisch nur die Bestellungen zu dem im Hauptformular angezeigten Kunden darstellt.<\/p>\n Hier geschieht das nicht, was leicht zu erklären ist: Beide Formulare besitzen schlicht und einfach keine Datenherkunft, da diese ja erst zur Laufzeit hinzugefügt wird. Somit kann Access auch keine Beziehung zwischen den im Haupt- und im Unterformular angezeigten Daten erkennen.<\/p>\n Damit wir überhaupt eine Chance haben, diese Synchronisierung zu erhalten, müssen wir zunächst das Unterformular mit Daten füllen. Dazu gibt es nun theoretisch zwei Möglichkeiten:<\/p>\n Der Versuch der ersten Variante zeigt, dass sich Theorie und Praxis unterscheiden: Bei per Recordset<\/b>-Eigenschaft zugewiesenen Datenherkünften wirken sich die Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>nicht aus. Widmen wir uns also gleich der zweiten Variante, die neben dem Füllen des Hauptformulars im Ereignis Beim Laden <\/b>des Formulars noch eine weitere Ereignisprozedur einsetzt: Damit das Unterformular jeweils die passenden Bestelldatensätze zum Kunden des Hauptformulars liefert, sollte dieses bei jedem Wechsel des Datensatzes im Hauptformular aktualisiert werden. Die passende Ereigniseigenschaft heißt Beim Anzeigen <\/b>und wird mit folgender Ereignisprozedur zum Leben erweckt:<\/p>\n Wir prüfen hier, ob das Feld KundeID <\/b>einen Nullwert enthält, und ersetzen diesen für die Formulierung der Abfrage durch 0<\/b>. Dies hat den Hintergrund, dass der Benutzer mit dem Formular auch neue Datensätze anlegen können soll.<\/p>\n Bei begrenzter Anzahl Datensätze im Unterformular kann man diese auch gleich komplett laden und beim Wechsel des Datensatzes im Hauptformular einen entsprechenden Filter setzen.<\/p>\n Ein neuer Datensatz besitzt allerdings zunächst keinen Wert für das Feld KundeID<\/b>. Wenn nun einfach der stattdessen vorhandene Nullwert an die WHERE<\/b>-Bedingung angehängt wird, erzeugt dies einen Fehler, weil MySQL (genauso wenig wie Access-SQL) die WHERE<\/b>-Klausel der Abfrage SELECT * FROM tblBestellungen WHERE KundeID = <\/b>nicht interpretieren kann und einen Fehler auslöst.<\/p>\n Es gibt noch ein weiteres kleines Problem, das durch die fehlende Synchronisierung über die Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>hervorgerufen wird: Das Fremdschlüsselfeld des Datensatzes im Unterformular (Verknüpfen von<\/b>) wird nicht automatisch mit dem Primärschlüsselfeld des Datensatzes im Hauptformular (Verknüpfen nach<\/b>) gefüllt. Sie müssen also auch noch dafür Sorge tragen, dass der Standardwert dieses Felds entsprechend vorbelegt wird. Da dieser Wert wiederum vom Datensatz im Hauptformular abhängt, muss er bei jedem Datensatzwechsel im Hauptformular aktualisiert werden. Dies erledigen wir durch Anhängen der folgenden Zeilen an die oben bereits beschriebene Prozedur Form_Current <\/b>des Hauptformulars:<\/p>\n Dies reicht aus, um den Standardwert von KundeID <\/b>für Bestellungen aller bereits vorhandenen Kunden einzustellen (siehe Bild 5). Leider geschieht dies scheinbar nicht, wenn Sie einen Kundendatensatz anlegen: Beim Form_Current<\/b>-Ereignis, das beim Wechseln zum neuen Datensatz ausgelöst wird, ist KundeID <\/b>im Hauptformular noch Null<\/b>. Das Fremdschlüsselfeld im Unterformular wird zwar richtigerweise auch auf Null <\/b>eingestellt, aber nach dem Erzeugen des Autowerts für KundeID <\/b>nach Eingabe des ersten Zeichens in einem Feld des neuen Datensatzes bleibt der Standardwert für KundeID <\/b>im Unterformular auf dem Wert Null <\/b>stehen. Wenn Sie nun im Hauptformular zum vorherigen Datensatz und wieder zurück wechseln, zeigt das Unterformular zwar den richtigen Standardwert an, aber das ist natürlich nicht besonders ergonomisch. Der Benutzer möchte möglicherweise gleich nach dem Anlegen eines Datensatzes im Hauptformular Daten im Unterformular anlegen (okay, vielleicht nicht in diesem Beispiel, aber es ist ja auch nur ein Beispiel).<\/p>\n Bild 5: Der Standardwert der Kunden-ID im Unterformular wird per Code eingestellt.<\/span><\/b><\/p>\n Also sorgen wir dafür, dass Access den Standardwert spätestens beim Eintritt in das Unterformular setzt, und zwar mit folgender Ereignisprozedur:<\/p>\n Beachten Sie an dieser Stelle, dass die DefaultValue<\/b>-Eigenschaft nur für Steuerelemente zur Verfügung steht und nicht für Feldverweise. In den meisten Fällen ändern Access-Entwickler die Steuerelementnamen von Feldern nach dem Hinzufügen über die Feldliste nicht explizit, was dazu führt, dass Steuerelement und Feld beziehungsweise Steuerelementinhalt die gleiche Bezeichnung tragen.<\/p>\n Wenn nun das Fremdschlüsselfeld, dessen Wert Sie per DefaultValue <\/b>vorbelegen möchten, nur in der Datenherkunft des Formulars enthalten ist, aber nicht als Steuerelementinhalt eines Steuerelements vorliegt, erzeugt dies einen Fehler. Sie müssen das Fremdschlüsselfeld also auf jeden Fall zum Formular hinzufügen, was in Bild 5 ja auch geschehen ist. Der Nachteil dabei ist, dass Sie dieses Feld eigentlich gar nicht benötigen – genau genommen soll es überhaupt nicht angezeigt werden, weil ja der Datensatz im Hauptformular bereits zeigt, wozu die Datensätze im Unterformular gehören.<\/p>\n Macht ja nichts, dann blenden wir es halt durch Einstellen der Eigenschaft Sichtbar <\/b>auf den Wert Nein <\/b>einfach aus. Nur: Dies wirkt sich zwar auf die Formular- und die Endlosansicht, nicht aber auf die Datenblattansicht im Unterformular aus. In der Datenblattansicht gelten andere Gesetze – es gibt nämlich einige weitere Eigenschaften für die dort angezeigten Steuerelemente. In diesem Fall erweitern wir die Beim Anzeigen<\/b>-Ereignisprozedur um folgende Zeile, um die Spalte mit dem Feld KundeID <\/b>auszublenden:<\/p>\n Dies können Sie übrigens nur wieder rückgängig machen, indem Sie ColumnHidden <\/b>für das entsprechende Steuerelement wieder auf False <\/b>einstellen. Mehr zu diesem Thema erfahren Sie im Beitrag Datenblattansicht aufgebohrt <\/b>(Shortlink 464).<\/p>\n m:n-Beziehung mit Unterformular<\/b><\/p>\n Ein typischer Fall für die Anzeige einer m:n-Beziehung im Unterformular sind die Bestellpositionen einer Bestellung. Das Hauptformular zeigt dabei die Bestelldetails wie Kunde, Bestelldatum et cetera an, das Unterformular steuert die bestellten Artikel sowie Informationen wie Anzahl und Preis bei. Im Unterformular muss dabei zwangsläufig die Verknüpfungstabelle (in unserem Datenmodell tblPositionen<\/b>) auftauchen.<\/p>\n Brauchen wir auch Daten aus der Tabelle tblArtikel<\/b> Nein, in diesem Fall nicht: Denn die zum Zeitpunkt der Bestellung wichtigen Artikelinformationen sollten in die Tabelle tblPositionen <\/b>übertragen und nicht einfach nur verknüpft werden. Dies betrifft vor allem den Einzelpreis, der sich ja durchaus mit der Zeit ändern kann, was sich nicht auf bereits durchgeführte Bestellungen auswirken darf. Außerdem kann es auch passieren, dass der Einzelpreis eines Artikels bei einer Bestellung geändert werden soll. Wir brauchen also nur die Tabelle tblPositionen<\/b> im Unterformular.<\/p>\n Fangen wir jedoch beim Hauptformular an: Hier können wir einfach mit dem bereits weiter oben erstellten Formular frmBestellungen <\/b>fortfahren.<\/p>\n Wir brauchen nun ein Unterformular, das wie in Bild 6 aussieht. Die Datenherkunft tblPositionen <\/b>werfen wir nach dem Hinzufügen der Steuerelemente aus der Feldliste wieder heraus. Gleiches gilt für die Datensatzherkünfte der beiden Kombinationsfelder BestellungID <\/b>und ArtikelID<\/b>.<\/p>\n Bild 6: Das Unterformular zur Anzeige der Positionen einer Bestellung<\/span><\/b><\/p>\n Außerdem können wir das Kombinationsfeld BestellungID <\/b>in ein Textfeld ändern, damit wir gleich den noch zu erstellenden DefaultValue <\/b>kontrollieren können – später wird dieses Feld natürlich ausgeblendet. Stellen Sie die Eigenschaft Standardansicht <\/b>des angehenden Unterformulars auf Datenblatt <\/b>ein und speichern Sie es unter dem Namen sfmBestellungen<\/b>.<\/p>\n Öffnen Sie dann frmBestellungen <\/b>in der Entwurfsansicht und fügen Sie sfmBestellungen <\/b>als Unterformular hinzu. Da weder Haupt- noch Unterformular eine Datenherkunft besitzen, werden auch die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformularsteuerelements automatisch gefüllt.<\/p>\n Schauen wir uns nun die notwendigen Prozeduren an, um Haupt- und Unterformular zu füllen. Den Start macht das Hauptformular mit mit der Ereignisprozedur aus Listing 1, die beim Laden des Formulars ausgelöst wird. Sie weist dem Recordset<\/b>-Objekt zuerst eine Datensatzgruppe mit allen Datensätzen der Tabelle tblBestellungen <\/b>zu und füllt das Kombinationsfeld KundeID <\/b>mit allen vorhandenen Kunden. Gleiches geschieht mit dem Kombinationsfeld ArtikelID <\/b>aus dem Unterformular: Dieses soll dem Benutzer alle vorhandenen Artikel zur Auswahl anbieten. Schließlich blendet die Prozedur die beiden Felder PositionID <\/b>und BestellungID <\/b>im Unterformular aus.<\/p>\n Listing 1: Füllen des Hauptformulars beim Laden<\/p>\n Die Prozedur aus Listing 2 wird jeweils beim Wechseln des Datensatzes im Hauptformular ausgelöst und sorgt dafür, dass die zur Bestellung passenden Positionen im Unterformular angezeigt werden. Dazu prüft die Prozedur zunächst die BestellungID <\/b>auf den Wert Null, <\/b>ersetzt diesen gegebenenfalls durch die Zahl 0<\/b> und schreibt das Ergebnis in die Long<\/b>-Variable lngBestellungID<\/b>.<\/p>\n Listing 2: Aktualisieren des Unterformulars beim Anzeigen eines neuen Datensatzes im Hauptformular<\/p>\n Diese dient als Vergleichswert für die WHERE<\/b>-Klausel der Abfrage, welche die Positionen zur aktuellen Bestellung ermittelt und das resultierende Recordset der gleichnamigen Eigenschaft des Unterformulars zuweist. Damit das Unterformular neue Datensätze gleich der richtigen Bestellung zuordnen kann, stellt die Prozedur noch den Standardwert des Felds BestellungID <\/b>auf den entsprechenden Wert der im Hauptformular angegebenen Bestellung ein.<\/p>\n Die Prozedur aus Listing 3 beugt dem Fall vor, dass der Benutzer eine neue Bestellung anlegt und dann die gewünschten Positionen hinzufügen möchte. Dafür gibt es zwei Varianten:<\/p>\n Listing 3: Einstellen des Fremdschlüsselfelds beim Eintreten ins Unterformular bei neuen Bestellungen<\/p>\n Schließlich müssen wir uns bei Verwendung von ADO-Recordsets in Haupt- und Unterformular noch darum kümmern, dass beim Löschen des Datensatzes im Hauptformular auch die damit verknüpften Daten im Unterformular gelöscht werden – es sei denn, Sie haben auf dem MySQL-Server Löschweitergabe aktiviert (was nur bei MySQL 5-Tabellen im InnoDB<\/b>-Format funktioniert). Falls nicht, erledigt die Prozedur aus Listing 4 dies für Sie.<\/p>\n Listing 4: Löschen der verknüpften Positionen beim Löschen einer Bestellung<\/p>\n Behandlung von Abfragen über mehr als eine Tabelle<\/b><\/p>\n Bislang konnten wir alle gewünschten Beziehungen in entsprechenden Formularen abbilden. Es gibt allerdings auch Fälle, denen nur mit größerem Aufwand beizukommen ist. Dabei handelt es sich grundsätzlich um Formulare, die Daten aus mehr als einer Tabelle anzeigen sollen und deren Datenherkunft entsprechend aus einer Abfrage mit mehreren per JOIN<\/b> verknüpften Tabellen besteht.<\/p>\n Das Problem ist, dass Access im Gegensatz zu anderen Datenbanksystemen sehr großzügig bezüglich der Aktualisierung von Daten aus verknüpften Tabellen ist. Beim Füllen des Recordsets eines Formulars mit zwei oder mehr verknüpften Tabellen aus einer MySQL-Datenbank via ADODB sieht das zum Beispiel anders aus: Die Daten werden dann zwar angezeigt, können allerdings nicht bearbeitet werden. Wenn man dies von vornherein weiß, kann man das Design seiner Benutzeroberfläche auch mit dieser Einschränkung in den meisten Fällen ausreichend gut umsetzen.<\/p>\n Beim Umstellen bestehender Datenbanken auf ADODB-\/Recordset-Technik kann es hier und da schon einmal zu Problemen kommen, beispielsweise wenn Felder aus verknüpften Tabellen als WHERE<\/b>-Bedingung oder als Sortierung per ORDER BY<\/b>-Klausel verwendet werden; noch schwieriger wird es, wenn Daten aus mehr als einer Tabelle in einem Formular bearbeitet werden sollen.<\/p>\n Sortier- und sonstige Kriterien aus verknüpften Tabellen<\/b><\/p>\n Wenn Sie Daten einer Tabelle anzeigen möchten und nach Feldern aus verknüpften Tabellen sortieren oder filtern möchten, dürfen diese nicht in der Ergebnismenge der Abfrage enthalten sein. Die folgende Abfrage würde beispielsweise ein Aktualisieren der angezeigten Daten verhindern:<\/p>\n Wenn Sie die Ergebnismenge wie folgt auf die Felder einer einzigen Tabelle beschränken, können Sie die Daten bearbeiten und löschen und auch neue Datensätze anlegen:<\/p>\n Sollten Daten ohnehin nur der Anzeige dienen wie etwa die in Recordsets von Kombinations- oder Listenfeldern, können Sie sich beim Zusammenstellen der zugrunde liegenden Abfragen austoben.<\/p>\n Wir beschränken uns an dieser Stelle darauf, auf potenzielle Probleme hinzuweisen. Theoretisch ist es immer möglich, Tabellen, Abfragen und Formulare so zu gestalten, dass Inhalte aus nicht mehr als einer Tabelle dargestellt beziehungsweise bearbeitet werden müssen.<\/p>\n ADODB-Recordsets in Berichten<\/b><\/p>\n Wer Formulare und Steuerelemente mit ADO-Recordsets befüllt, kommt früher oder später natürlich auf die Idee, dies mit einem Bericht durchzuführen. Leider können Berichte auch mit Access 2007 noch immer nicht mit benutzerdefinierten Recordsets gefüllt werden. Als Alternative empfiehlt es sich, eine PassThrough<\/b>-Abfrage zu verwenden, die bezüglich der Geschwindigkeit wohl eine ähnliche Leistung erwarten lässt.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Wenn Sie mit einem Access-Frontend auf eine Datenbank zugreifen möchten, die auf einem Webserver liegt (was aktuell meist ein MySQL-Server sein dürfte) und sich über die mäßige Geschwindigkeit bei der Verwendung verknüpfter ODBC-Tabellen ärgern, finden Sie in diesem Beitrag möglicherweise die Lösung: Am Beispiel einer im Einsatz befindlichen Anwendung konnte der Autor deutliche Performance-Steigerungen feststellen, welche die Umstellung der kompletten Anwendung auf die hier vorgestellte Technik nach sich zog. Gleichwohl muss klar sein, dass der Programmieraufwand etwas höher ist als bei der Verwendung eingebundener ODBC-Tabellen, was ja im Prinzip mit dem für den Einsatz lokaler Tabellen nötigen Aufwand vergleichbar ist. Außerdem sind hier und da Umstellungen erforderlich, da Datenherkünfte mit Daten aus mehreren verknüpften Tabellen unter Umständen nicht aktualisiert werden können.<\/p>\n Enthaltene Beispieldateien:<\/p>\n ADODB_MySQL.mdb<\/p>\nPrivate m_Connection As ADODB.Connection<\/pre>\n
Public Const strConnection As String = "Driver={MySQL ODBC 5.1 Driver};Server=<IP des Webservers>;Database=<Datenbankname>;User=<Benutzername>;Password=<Kennwort>;Option=3;"<\/pre>\nPublic Function GetConnection() As _\r\n ADODB.Connection\r\n If m_Connection Is Nothing Then\r\n Set m_Connection = New ADODB.Connection\r\n m_Connection.Open strConnection\r\n End If\r\n Set GetConnection = m_Connection\r\nEnd Function<\/pre>\n
\n
Public Function GetRecordset( _\r\n objConnection As ADODB.Connection, _\r\n strSQL As String) As ADODB.Recordset\r\n Dim rst As ADODB.Recordset\r\n Set rst = New ADODB.Recordset\r\n With rst\r\n .ActiveConnection = objConnection\r\n .CursorLocation = adUseClient\r\n .CursorType = adOpenDynamic\r\n .LockType = adLockBatchOptimistic\r\n .Source = strSQL\r\n .Open , , , , adCmdText\r\n Set GetRecordset = rst\r\n End With\r\nEnd Function<\/pre>\n
![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2010_01\/MySQLDirekt-web-images\/pic002_opt.jpeg\")
<\/p>\nPrivate Sub Form_Load()\r\n Set Me.Recordset = GetRecordset( _\r\n GetConnection, _\r\n "SELECT * FROM tblKunden")\r\nEnd Sub<\/pre>\n
Private Sub Form_Load()\r\n Set Me.Recordset = GetRecordset( _\r\n GetConnection, _\r\n "SELECT * FROM tblBestellungen")\r\nEnd Sub<\/pre>\n
![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2010_01\/MySQLDirekt-web-images\/pic003_opt.jpeg\")
<\/p>\nSet Me!KundeID.Recordset = _\r\nGetRecordset(GetConnection, _\r\n"SELECT KundeID, Nachname " _\r\n & "FROM tblKunden ORDER BY Nachname")<\/pre>\n
SELECT KundeID, Nachname & '', '' & Vorname AS Kunde FROM tblKunden ORDER BY Nachname<\/pre>\n
SELECT KundeID, CONCAT(Nachname, '', '', Vorname) AS Kunde FROM tblKunden ORDER BY Nachname<\/pre>\n
![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2010_01\/MySQLDirekt-web-images\/pic004_opt.jpeg\")
<\/p>\n\n
Private Sub Form_Current()\r\n Dim strSQL As String\r\n Dim lngKundeID As Long\r\n lngKundeID = Nz(Me!KundeID)\r\n strSQL = "SELECT * FROM tblBestellungen " _\r\n "WHERE KundeID = " & lngKundeID\r\n Set Me!sfmKunden.Form.Recordset = _\r\n GetRecordset(GetConnection, strSQL)\r\nEnd Sub<\/pre>\n
Me!sfmKunden.Form!KundeID.DefaultValue = lngKundeID<\/pre>\n
![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2010_01\/MySQLDirekt-web-images\/pic005_opt.jpeg\")
<\/p>\nPrivate Sub sfmKunden_Enter()\r\n Dim lngKundeID As Long\r\n lngKundeID = Nz(Me!KundeID)\r\n Me!sfmKunden.Form!KundeID.DefaultValue = lngKundeID\r\nEnd Sub<\/pre>\n
Me!sfmKunden.Form!KundeID.ColumnHidden = True<\/pre>\n
![\"pic006.png\"](\"..\/fileadmin\/_temp_\/2010_01\/MySQLDirekt-web-images\/pic006_opt.jpeg\")
<\/p>\nPrivate Sub Form_Load()\r\n Set Me.Recordset = GetRecordset(GetConnection, \"SELECT * FROM tblBestellungen\")\r\n Set Me!KundeID.Recordset = GetRecordset(GetConnection, _\r\n \"SELECT KundeID, CONCAT(Nachname, €, €, Vorname) AS Kunde FROM tblKunden ORDER BY Nachname\")\r\n With Me!sfmBestellungen.Form\r\n Set !ArtikelID.Recordset = GetRecordset(GetConnection, _\r\n \"SELECT ArtikelID, Artikelname, Artikelpreis FROM tblArtikel\")\r\n !PositionID.ColumnHidden = True\r\n !BestellungID.ColumnHidden = True\r\n End With\r\nEnd Sub<\/pre>\n
Private Sub Form_Current()\r\n Dim lngBestellungID As Long\r\n lngBestellungID = Nz(Me!BestellungID)\r\n With Me!sfmBestellungen.Form\r\n Set .Recordset = GetRecordset(GetConnection, _\r\n \"SELECT * FROM tblPositionen WHERE BestellungID = \" & lngBestellungID)\r\n !BestellungID.DefaultValue = lngBestellungID\r\n End With\r\nEnd Sub<\/pre>\n
\n
Private Sub sfmBestellungen_Enter()\r\n Dim lngBestellungID As Long\r\n lngBestellungID = Nz(Me!BestellungID)\r\n If Not lngBestellungID = 0 Then\r\n Me!sfmBestellungen.Form!BestellungID.DefaultValue = lngBestellungID\r\n Else\r\n MsgBox !Bitte geben Sie zunächst die Bestellinformationen wie Kunde und Bestelldatum an.\", _\r\n vbOKOnly + vbExclamation, \"Bestelldaten fehlen\"\r\n Me!Bestelldatum.SetFocus\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Form_Delete(Cancel As Integer)\r\n GetConnection.Execute \"DELETE FROM tblPositionen WHERE BestellungID = \" & Me!BestellungID\r\nEnd Sub<\/pre>\n
SELECT tblBestellungen.BestellungID,\r\ntblBestellungen.Bestelldatum, tblKunden.Vorname, tblKunden.Nachname\r\nFROM tblKunden\r\nINNER JOIN tblBestellungen\r\nON tblKunden.KundeID = tblBestellungen.KundeID\r\nWHERE tblKunden.Vorname LIKE ''Andre'';<\/pre>\n
SELECT tblBestellungen.BestellungID,\r\ntblBestellungen.Bestelldatum\r\nFROM tblKunden ...<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n