{"id":55000590,"date":"2008-06-01T00:00:00","date_gmt":"2021-02-11T21:20:36","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=590"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Access_MySQL_und_Datenzugriff","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Access_MySQL_und_Datenzugriff\/","title":{"rendered":"Access, MySQL und Datenzugriff"},"content":{"rendered":"

\"\"<\/p>\n

Sie haben Ihr Access-Backend auf einen MySQL-Server migriert, die notwendigen Anpassungen vorgenommen und die Tabellen über ODBC in Ihr Frontend verknüpft. Mit Unterstützung der beiden vorausgegangenen Beiträge dieser Serie (Shortlink 544 und 588) sollte das gelungen sein. Schauen wir nun, was es mit dem Zugriff auf die Tabellen auf sich hat und was es dabei zu beachten gilt.<\/b><\/p>\n

Ein Hemmschuh, wenn es an die Migration einer Access-Datenbank mit File-Backend auf einen SQL-Server gehen soll, ist der vermeintliche Aufwand, der durch Anpassungen des Frontends zu erwarten ist. Hier erwartet man größere Umbauarbeiten am VBA-Code oder etwa spezielle Zugriffsroutinen in einem ungewohnten SQL-Dialekt. <\/p>\n

Wie die beiden vorherigen Beiträge dieser Reihe gezeigt haben, ist es aber kein Hexenwerk, die Tabellen auf den Server zu kopieren und dann per ODBC-Datenquelle in das Frontend zu verlinken. Tatsächlich ist damit bereits der wesentliche Teil einer Migration erledigt. Im Normalfall sollte die Datenbank dann genau so funktionieren, wie vorher mit dem File-Backend – irgendwelche änderungen am Code oder an Formularen oder Berichten sind nicht erforderlich. <\/p>\n

ODBC-verknüpfte Tabellen<\/p>\n

Nun hört man gelegentlich Unkenrufe, dass mit verlinkten SQL-Servertabellen noch kein nennenswerter Performancegewinn zu erwarten sei, weil Access die Daten dann genauso en bloc auf die Client-Seite holen muss, um sie daraufhin lokal zu verarbeiten.<\/p>\n

Selbst wenn dies zuträfe, würde durch die wegfallenden Sperrmechanismen, die einen erheblichen negativen Einfluss auf die Performance in Mehrbenutzerumgebung bei Bindung an ein File-Backend haben, die Zugriffsgeschwindigkeit deutlich steigen.<\/p>\n

Aber die Annahme ist ohnehin völlig falsch: Access holt sich im Normalfall nur das Ergebnis einer Abfrage oder Indizes vom Server ab, nicht den kompletten Inhalt einer Tabelle. Dabei spielt es keine Rolle, ob eine Tabelle in der Datenblattansicht geöffnet oder eine Abfrage ausgeführt wird. In beiden Fällen wird JET ein SELECT-Statement an den Server absetzen.<\/p>\n

Es ist dabei intelligent genug, nicht den ganzen Inhalt zu holen, sondern nur den Teil, der wirklich erforderlich ist. Der Nachweis dafür kann mit verschiedenen Analysemethoden erbracht werden, die Sie später unter Zugriff loggen <\/b>kennenlernen werden.<\/p>\n

An dieser Stelle soll an einem Beispiel schon mal vorgegriffen werden, was abläuft, wenn Sie ein an die Tabelle tblKunden <\/b>gebundenes Formular (frmKunden2<\/b>) der Beispieldatenbank öffnen.<\/p>\n

JET fragt dann im ersten Schritt zunächst einmal ausschließlich nach den Primärschlüsseln der Tabelle:<\/p>\n

SELECT 'tblkunden'.'KundeID' FROM 'tblkunden'<\/pre>\n
Als Ergebnis ermittelt es eine 1<\/b> für die ID <\/b>des ersten Kundendatensatzes. Bis hierhin beschränkt sich also der Austausch mit dem Server auf wenige Bytes für die Indizes der Tabelle. Nach Kenntnis des ersten Primärschlüsselwerts fragt es die restlichen Felder des zur ID <\/b>passenden Datensatzes ab:<\/p>\n
SELECT 'KundeID', 'KundenCode', 'Firma',\r\n'Kontaktperson', 'Position', 'Strasse', 'Ort', 'Region', 'PLZ', 'Land', 'Telefon', 'Telefax', 'TS' FROM 'tblkunden'\r\nWHERE 'KundeID' = 1<\/pre>\n
Und mit dem Ergebnis dieser Abfrage füllt es dann auch schon die Felder des Formulars. Der Umfang des gesamten Traffics für diesen Vorgang dürfte nicht viel mehr als einige Hundert Bytes betragen. Erst dann, wenn Sie auf den nächsten Datensatz schalten, werden zusätzliche Daten geholt. Dabei denkt sich JET wohl: „Okay, da sollen wahrscheinlich noch mehr Datensätze angezeigt werden …“, und schickt dem Server eine Anfrage für gleich zehn weitere Datensätze:<\/p>\n
SELECT 'KundeID', 'KundenCode', 'Firma',\r\n'Kontaktperson', 'Position', 'Strasse', 'Ort', 'Region', 'PLZ', 'Land', 'Telefon', 'Telefax', 'TS' FROM 'tblkunden'\r\nWHERE 'KundeID' = 2 OR 'KundeID' = 3 OR 'KundeID' = 4 OR 'KundeID' = 5 OR 'KundeID' = 6 OR 'KundeID' = 7 OR 'KundeID' = 8 OR 'KundeID' = 9 OR 'KundeID' = 10 OR 'KundeID' = 11<\/pre>\n
Übrigens geschieht dasselbe auch, wenn Sie gar nichts tun und das Formular auf dem ersten Datensatz stehen lassen: Nach etwa einer Minute holt JET sich automatisch zehn neue Datensätze im Hintergrund, weil es offenbar gerade nichts Besseres zu tun hat.<\/p>\n
Das Spiel wiederholt sich regelmäßig, bis alle Kundendatensätze in den Cache der Client-Seite gezogen wurden, was im Beispielformular (90 Kundendatensätze) nach etwa neun Minuten der Fall ist. Wenn Sie dann durch alle Datensätze des Formulars steppen, muss JET gar keine Datensätze mehr beim Server anfragen, weil sie sich bereits im lokalen Cache befinden. <\/p>\n
Öffnen Sie die Tabelle tblKunden <\/b>in der Datenblattansicht, dann reicht ein Datensatz zur initialen Anzeige natürlich nicht aus. In diesem Fall fragt JET genau so viele Datensätze beim Server ab, wie zur Anzeige auf dem Bildschirm benötigt werden – nicht mehr und nicht weniger.<\/p>\n
Erst ein Scrollen nach unten holt tatsächlich weitere Daten. Dabei ergehen die Anfragen immer in Zehnerblöcken, wie im oben dargestellten SQL-Statement, über OR-verkettete Kriterien.<\/p>\n
Man sieht hier also, dass JET durchaus intelligent und resourcenschonend mit dem SQL-Server umgeht. ähnlich geht es auch bei Abfragen vor.<\/p>\n
JET versucht hier, einen möglichst großen Teil des SQL-Ausdrucks direkt an den Server zu schicken, wobei es das Statement teilweise umformuliert.<\/p>\n
Eine Abfrage der Artikel der Tabelle tblArtikel <\/b>könnte etwa so aussehen:<\/p>\n
SELECT "ART." & [Artikelname] AS Artikel,\r\ntblartikel.ArtikelID\r\nFROM tblartikel\r\nWHERE (((tblartikel.ArtikelID)>20))\r\nORDER BY "ART." & [Artikelname];<\/pre>\n
JET macht daraus zwei Schritte:<\/p>\n
SELECT 'Artikelname', 'tblartikel'. 'ArtikelID'\r\nFROM 'tblartikel' WHERE ('ArtikelID' > 20 )<\/pre>\n
Abgefragt wird hier also nicht nur der Primärschlüssel ArtikelID<\/b>, sondern auch das Textfeld Artikelname<\/b>. Der Grund ist die Sortierung nach dem Namen, die auf dieses Feld angewandt werden soll.<\/p>\n
Das erledigt JET erst anschließend und teilt sich die Arbeit in diesem Fall mit dem Server, obwohl auch dieser durchaus sortieren könnte. Dass die ORDER-Anweisung nicht mit an den Server geschickt wird, liegt an der VBA-Verknüpfung des Feldinhalts mit dem gewählten Präfix ART:<\/b>. Das Einschränkungskriterium ArtikelID>20 <\/b>hingegen darf der Server selbst verarbeiten.<\/p>\n
Im zweiten Schritt werden die ersten zehn Datensätze der nun von JET sortierten Artikel-IDs abgefragt:<\/p>\n
SELECT 'ArtikelID','Artikelname','TS' FROM 'tblartikel'\r\nWHERE 'ArtikelID' = 40 OR 'ArtikelID' = 60 OR 'ArtikelID' = 39 OR 'ArtikelID' = 48 OR\r\n'ArtikelID' = 38 OR 'ArtikelID' = 58 OR\r\n'ArtikelID' = 52 OR 'ArtikelID' = 71 OR\r\n'ArtikelID' = 33 OR 'ArtikelID' = 56<\/pre>\n
Damit können die ersten zehn Zeilen des Datenblatts gefüllt werden. Für die darauf folgenden Zeilen läuft dann ein analoges Prozedere ab.<\/p>\n
Ein Beispiel für eine Abfrage, die auf mehreren verknüpften Tabellen basiert, soll hier aus Platzgründen außen vor bleiben. Es sei aber verraten, dass JET auch dann den SQL-Ausdruck weitgehend an den Server übergibt und ihm das Joinen überlässt, statt selbst tätig zu werden.<\/p>\n
Pass-Through-Abfragen<\/b><\/p>\n
Es lässt sich also ableiten, dass allein verknüpfte ODBC-Tabellen und Abfragen auf diese einen erheblichen Performance-Zugewinn bringen.<\/p>\n
Das letzte Beispiel zeigt aber auch, dass JET immer dann einschreiten muss, wenn der SQL-Ausdruck eine Syntax aufweist, die der MySQL-Server so nicht verstehen würde. Das kommt in erster Linie dann zum Tragen, wenn VBA-Funktionen im SQL-String zum Einsatz kommen.<\/p>\n
Auch das Verknüpfungszeichen & <\/b>versteht MySQL nicht als String-Verknüpfungsoperator, weshalb JET diesen Part übernehmen muss. Die besprochene Abfrage hätte unter MySQL nämlich diese Syntax:<\/p>\n
SELECT CONCAT('ART.',Artikelname) AS Artikel,\r\ntblartikel.ArtikelID\r\nFROM tblartikel\r\nWHERE tblartikel.ArtikelID>20\r\nORDER BY CONCAT('ART.',Artikelname);<\/pre>\n
Für die String-Verknüpfung gibt es hier eine eigene Funktion CONCAT<\/b>, die eine beliebige Anzahl durch Kommata getrennter Strings als Parameter erwartet. Die Ausführung dieser Abfrage verläuft nochmal um Größenordnungen schneller als die vorherige Lösung.<\/p>\n
Diese SQL-Anweisung können Sie aber nicht einfach in die SQL-Ansicht des Abfrageeditors eingeben. Access würde versuchen, sie als JET-Ausdruck zu parsen, und einen Fehler wegen unbekannter Funktion CONCAT <\/b>melden.<\/p>\n
Es muss Access schon ausdrücklich gesagt werden, dass es den Ausdruck unbesehen an den Server senden soll, um dann auf das Ergebnis zu warten. Sie erzwingen das, indem der Typ der Abfrage auf Pass-Through <\/b>gestellt wird. Öffnen Sie dazu eine neue Abfrage, fügen keine Tabellen hinzu und betätigen den Menüpunkt Abfrage|SQL spezifisch|Pass-Through<\/b>. In diesem Modus ist dann keine visuelle Gestaltung mehr möglich, sondern ausschließlich die Eingabe von SQL-Statements. Damit Access weiß, wohin es dieses Statement unter Umgehung der verknüpften Tabellen senden soll, muss außerdem eine ODBC-Verbindungszeichenfolge angegeben werden, die analog zum Connect-String der Tabellen lautet und etwa so aussehen könnte:<\/p>\n
ODBC;Driver={MySQL ODBC 3.51 Driver};DATABASE=suedsturm;\r\nSERVER=localhost ;PORT=3306; UID=;PWD=;OPTION=43<\/pre>\n
Die Eigenschaft Liefert Datensätze <\/b>muss auf Ja <\/b>stehen, sonst geschieht gar nichts (siehe Bild 1). Ein Nein <\/b>ist hier nur angebracht, wenn es sich beim SQL-Ausdruck um eine Aktionsabfrage handelt.<\/p>\n
\"missing<\/p>\n
Bild 1: Pass-Through-Abfrage und ODBC-Verbindungsparameter<\/span><\/b><\/p>\n
Solche Pass-Through-Abfragen sind sehr schnell, haben aber drei Haken. Einmal nötigen sie Sie dazu, sich mit der speziellen MySQL-Syntax zu beschäftigen. Im MySQL-Handbuch [3] finden Sie diese erschöpfend beschrieben.<\/p>\n
Der Sprachumfang ist nicht so groß, wie etwa beim T-SQL des Microsoft-SQL-Servers, verlangt aber doch einige Wochen Beschäftigung mit der Materie, wenn er beherrscht werden will. Sie brauchen sich das aber nicht auf einen Schlag anzueignen, sondern kommen mit gelegentlichem Suchen in der Hilfe und Experimenten ebenfalls nach und nach zum Ziel.<\/p>\n
Ein anderer Punkt ist, dass Sie mit Pass-Through-Abfragen die Portierbarkeit der Datenbank zunichte machen. Während Sie bei einem Frontend mit ausschließlich verknüpften Tabellen ohne Weiteres etwa auf Oracle umstellen können, indem die Tabellen dorthin gezogen werden, steht bei Pass-Through-Abfragen immer erst eine Umstellung dieser Abfrage auf die spezifische Server-Syntax an.<\/p>\n
<\/p>\n
Und schließlich haben Pass-Through-Abfragen noch ein gewichtiges Manko: Sie sind lediglich zum Lesen von Daten gedacht.<\/p>\n
Das Ergebnis der Abfrage kann nicht editiert werden, auch wenn eine analoge JET-Abfrage aktualisierbar wäre. Sie können ein Formular zwar auf Grundlage einer PT-Abfrage erstellen, die Datensätze werden aber schreibgeschützt sein. <\/p>\n
Datenzugriff per ADO<\/b><\/p>\n
Man könnte alternativ auf die Idee kommen, auf eine ODBC-Tabelle ein ADO-Recordset zu öffnen und dieses einem Formular als Datenquelle zuzuweisen. Allerdings nur dann, wenn ein client-seitiger Cursor verwendet wird (CursorLocation<\/b>-Eigenschaft), denn ein ADO-Recordset auf Basis einer Connection mit serverseitigem Cursor wird nicht als Formular-Recordset akzeptiert. <\/p>\n
Als Provider ist dabei der Microsoft OLE DB-Provider for ODBC Drivers <\/b>zu benutzen und der ConnectionString <\/b>sieht ähnlich aus, wie der für Tabellen und Pass-Through-Abfragen:<\/p>\n
Dim oCon As New ADODB.Connection\r\nDim rst As New ADODB.Recordset\r\noCon.Provider = "MSDASQL.1" 'ODBC-Provider\r\noCon.ConnectionString = _\r\n& "Extended Properties=\" _\r\n& "'Driver={MySQL ODBC 3.51 Driver};" _\r\n& "DATABASE=suedsturm;SERVER=localhost;" _\r\n& "PORT=4040;" _\r\n& "UID=root;PWD=adminpasswort;OPTION=43'"\r\noCon.CursorLocation = adUseClient\r\noCon.Open\r\nrst.Open "SELECT * FROM tblkunden", oCon, _\r\nadOpenDynamic, adLockOptimistic\r\nSet Me.Recordset = rst<\/pre>\n
Bei der Inspektion der Anweisungen, die dann als Anfragen beim Server ankommen, wenn durch die Datensätze des Formulars gesteppt wird, tritt allerdings Ernüchterung ein: Für jeden Datensatz wird wiederholt das Statement SELECT * FROM tblkunden<\/b> abgesetzt. Das ist performancetechnisch natürlich außerordentlich suboptimal. Da ist die Methode mit Bindung des Formulars an eine verknüpfte Tabelle schon wesentlich effizienter. Ein Code wie in Listing 1 sollte also nicht zur Anwendung kommen.<\/p>\n
Aber auch abseits von Formularen ist ein ADO-Recordset nicht die erste Wahl, wenn es um den Datenzugriff auf einen MySQL-Server geht. Ohne hier ins Detail zu gehen, lässt sich sagen, dass der Zugriff dabei intern recht umständlich vonstatten geht. Das gilt für lesende wie schreibende Zugriffe gleichermaßen. Offenbar hat Microsoft ADO nur für Zugriffe auf den MS SQL Server und dessen Provider optimiert, was etwa bei Access-Projekten (ADP) zum Tragen kommt.<\/p>\n
Für ODBC-Verbindungen bringt ADO eher Nachteile und sollte vermieden werden, falls nicht ausgewählte Gründe dafür sprechen.<\/p>\n
Datenzugriff per DAO<\/b><\/p>\n
Wenn Operationen auf die Daten über DAO-Recordsets auf die eingebundenen Tabellen ausgeführt werden, dann greifen weitgehend die gleichen optimierenden Mechanismen, wie bei gebundenen Formularen. Es kann daher identischer Code eingesetzt werden, wie bei einem Access-Backend. Anpassungen sind dabei nicht erforderlich.<\/p>\n
Es gelten allerdings auch die gleichen Beschränkungen für SQL-Statements, wie für normale Abfragen: Sobald etwa VBA-Ausdrücke enthalten sind, dann wird JET genötigt, teilweise selbst Hand anzulegen und Berechnungen durchzuführen.<\/p>\n
Umgehen können Sie das, indem ähnlich wie bei den Pass-Through-Abfragen direkt die Syntax des SQL-Servers verwendet wird. Wie aber kann man DAO sagen, dass es ein SQL-Statement nicht parsen, sondern direkt abschicken soll<\/p>\n
Mit einem Database<\/b>-Objekt und einem Recordset geht das nämlich nicht, weil ein Database<\/b>-Objekt im Kontext der verknüpften Tabellen steht, die ja gerade umgangen werden sollen.<\/p>\n
Für diesen Zweck gibt es in DAO statt einem Database<\/b>-Objekt ein Connection<\/b>-Objekt. Operationen über eine solche DAO.Connection <\/b>laufen in den ominösen ODBCDirect<\/b>-Arbeitsbereichen ab, die leider so selten in freier Wildbahn anzutreffen sind, dass Microsoft sich offenbar veranlasst sah, sie in Access 2007 nicht mehr zu unterstützen. Das ist meiner Meinung nach ein wichtiger Punkt, der leider gegen den Einsatz von Access 2007 bei ODBC-Anbindung spricht.<\/p>\n
Ein ODBCDirect<\/b>-Arbeitsbereich wird über ein Workspace<\/b>-Objekt erstellt, dem ausdrücklich die Verwendung von ODBC über die Optionskonstante dbUseODBC <\/b>mitgeteilt wird:<\/p>\n
Dim wrk As Workspace\r\nSet wrk = DBEngine.CreateWorkspace("", "", "", _\r\n& dbUseODBC)<\/pre>\n
Auf dieses Workspace kann nun eine ODBC-Connection geöffnet werden:<\/p>\n
Dim oCon As DAO.Connection\r\nDim strConnect As String\r\nstrConnect = "<ODBC-Verbindungszeichenfolge>"\r\nSet oCon = wrk.OpenConnection("", , , strConnect)<\/pre>\n
Die Verbindungszeichenfolge ist wieder die gleiche, die auch zum Verknüpfen der Server-Tabellen verwendet wird. Das Connection<\/b>-Objekt kennt ähnliche Methoden wie ein Database<\/b>-Objekt, also etwa auch solche zum Öffnen einer Datensatzgruppe:<\/p>\n
Dim rst As DAO.Recordset\r\nSet rst = oCon.OpenRecordset( _\r\n"SELECT * FROM tblKunden WHERE " _\r\n& "Kundencode='ALFKI'", _\r\ndbOpenDynamic)\r\nDebug.Print rst!Kontaktperson<\/pre>\n
Was aber so ein Recordset von einem üblichen Dynaset unterscheidet: Es ist wieder nicht aktualisierbar, also schreibgeschützt, und eignet sich daher nur für lesenden Zugriff.<\/p>\n
Methoden wie .AddNew <\/b>oder .Edit <\/b>werden demnach entsprechende Fehlermeldungen nach sich ziehen. Der Beweis dafür ist, dass die Eigenschaft rst.Updatable <\/b>den Wert False <\/b>zurückliefert.<\/p>\n
Dafür haben ODBCDirect<\/b>-Recordsets einen anderen Vorzug: Wenn als Öffnungsparameter für die Optionen der Connection die Konstante dbRunAsync <\/b>abgegeben wird, dann wartet VBA mit der Ausführung weiterer Codezeilen erst gar nicht, bis das Ergebnis vom Server vorliegt. Die Vorgänge geschehen also asynchron, was Zeit durch Parallelverarbeitungen sparen kann.<\/p>\n
Liegt das Resultat schließlich vor, dann zeigt das Connection<\/b>-Objekt dies an seiner Eigenschaft StillExecuting<\/b>, die auf False <\/b>gesetzt wird. Ein Beispiel für solche asynchrone Verarbeitung wäre etwa folgendes:<\/p>\n
Set oCon = wrk.OpenConnection("", _\r\ndbRunAsync , , strConnect)\r\nSet rst = oCon.OpenRecordset( _\r\n"SELECT * FROM tblKunden WHERE " _\r\n& "Kundencode='ALFKI'", _\r\ndbOpenDynamic)\r\nDo\r\n    DoEvents\r\n        'Mache ggfls. noch andere Sachen...\r\n    Loop Until oCon.StillExecuting = False\r\n    Debug.Print rst!Kontaktperson<\/pre>\n
Der Nachteil fehlender Aktualisierbarkeit des Recordsets ist allerdings nicht so tragisch und führt lediglich zu ein paar Zeilen mehr Code. Die Connection kann nämlich weiter verwendet werden, um etwa UPDATE<\/b>– oder INSERT<\/b>-Anweisungen zum Aktualisieren der Daten abzusetzen:<\/p>\n
    oCon.Execute "UPDATE tblkunden " _\r\n    & "SET Kontaktperson='Maria Andersen' " _\r\n    & "WHERE Kundencode='ALFKI'"<\/pre>\n
Hier ist also etwas mehr SQL notwendig als bei den üblichen Recordset<\/b>-Routinen. Dafür kann der komplette Sprachumfang des Servers genutzt werden. Sie können über ein Execute<\/b>-Statement zum Beispiel auch Funktionen und Stored Procedures anstoßen.<\/p>\n
Bleibt noch ein Wort zu Access 2007, das diese Features nicht mehr unterstützt: Entweder, Sie setzen hier Pass-Through-Abfragen ein, die aus VBA heraus über QueryDef<\/b>-Objekte aufgerufen werden, oder Sie verwenden eben doch ADO. Denn dabei wird der Dialekt des Servers im Gegensatz zu DAO ebenfalls unterstützt:<\/p>\n
    Dim oCon As New ADODB.Connection\r\n    Dim rst As New ADODB.Recordset\r\n    oCon.ConnectionString = "Provider=MSDASQL.1;....\"\r\n    oCon.Open\r\n    rst.Open _\r\n    "SELECT CONCAT('Frau ', Kontaktperson) " & _\r\n    "FROM tblKunden WHERE Kundencode='ALFKI'", _\r\n    oCon, adOpenDynamic, adLockOptimistic, _\r\n    adCmdText\r\n    Debug.Print rst(0)<\/pre>\n
Alle Beispiele zu diesem Beitrag finden Sie in der begleitenden Datenbankdatei suedsturm_mysql3.mdb<\/b>.<\/p>\n
Zugriff loggen<\/b><\/p>\n
Vielleicht haben Sie sich gefragt, woher der Autor denn weiß, was JET beim simplen Öffnen einer Tabelle in Datenblattansicht macht Dokumentationen seitens Microsoft gibt es dazu nicht und JET hält auch sonst ziemlich geheim, was es genau anstellt.<\/p>\n
SQL-Server haben aber im Gegensatz zum File-Backend den Vorteil, dass sie Zugriffe und die empfangenen Statements protokollieren können. Häufig existieren auch Zusatz-Tools wie Query Analyzer, die diese Protokollierung bequem anzeigen und filtern können. Solche Möglichkeiten existieren ebenfalls für MySQL, wenn auch nicht ganz so komfortabel wie beim Microsoft SQL-Server. Im Folgenden werden vier gebräuchliche Methoden vorgestellt.<\/p>\n
Das Server-Log<\/b><\/p>\n
Der MySQL-Server kann angewiesen werden, ob, wie und wo er Zugriffsprotokolle erstellen soll. Die dazu erforderlichen Einstellungsparameter liest er beim Start aus der Konfigurationsdatei my.cnf <\/b>aus. Diese braucht nicht, wie früher, von Hand mit einem Texteditor modifiziert zu werden, sondern kann über den MySQL Administrator <\/b>gesteuert werden. Starten Sie diesen und nehmen Sie einige änderungen an den Startvariablen (gleichnamiger Menüpunkt) vor:<\/p>\n