<\/p>\n
WordPress ist das gängigste System für die Erstellung und Pflege eines Blogs. Mittlerweile gibt es so viele Erweiterungen, dass ein Blog nur noch eine von vielen Möglichkeiten ist, eine Webseite über die WordPress-Plattform zu bauen. Da für Access im Unternehmen der Umzug auf ein moderneres System anstand, haben wir uns für WordPress entschieden. Es bietet gleichzeitig viele Möglichkeiten und ist dennoch recht einfach zu bedienen. Das gilt allerdings auch nur, wenn Sie keine besonderen Anforderungen haben – was in unserem Fall anders aussieht: Immerhin sollen mehr als 1.000 Beiträge samt Bildern und Downloads übertragen werden. Und es darf auch nicht jeder alle Beiträge vollständig betrachten, sondern nur über eine Benutzerverwaltung erfasste Abonnenten. Wie wir das realisiert haben, zeigen wir in diesem Beitrag.<\/b><\/p>\n
Aus Alt mach Neu<\/b><\/p>\n
Am Anfang stand die Erkenntnis, dass das im Jahre 2003 aufgesetzte Typo3-System zwar noch klaglos seinen Dienst tut, aber leider nicht der Server, auf dem das Content-Management-System läuft. Bei einem 16 Jahre alten Gerät muss man sich freuen, dass es überhaupt noch läuft. Leider wurden keine regelmäßigen Updates gemacht, sodass es nur mit erheblichem Aufwand möglich gewesen wäre, das System nochmal auf eine aktuellere Version zu übertragen. Also musste ein neues System her, und zwar WordPress.<\/p>\n
Zwei WordPress-Varianten<\/b><\/p>\n
Es gibt zwei WordPress-Varianten: WordPress.com <\/b>bietet die Software inklusive Hosting an. Sie melden dort eine neue WordPress-Seite an und bekommen die komplette Infrastruktur gestellt. Dafür gibt es allerdings auch Einschränkungen: Sie können nicht nach Lust und Laune auf Datenbank, Dateien und sonstige Elemente zugreifen, was unseren Spieltrieb und auch die Flexibilität erheblich einschränkte. <\/p>\n
Die zweite WordPress-Variante findet sich auf WordPress.org <\/b>zum Download und kann auf Ihrem eigenen oder gemieteten Webserver installiert werden. Einige Anbieter bieten auch Pakete an, auf denen alle Voraussetzungen für den Einsatz von WordPress vorliegen. Hier können Sie je nach den durch den Hoster angebotenen Möglichkeiten auf alle notwendigen Bereiche zugreifen, also auf die Datenbank, das Dateisystem und mehr. Diese Variante haben wir gewählt. Als Hoster nutzen wir aixpro.de<\/b>.<\/p>\n
Voraussetzungen<\/b><\/p>\n
Schon unter Verwendung des in die Jahre gekommen Typo3-Systems sah der Workflow für die Veröffentlichung der Beiträge wie folgt aus: Die Beiträge wurden in InDesign geschrieben und gesetzt.<\/p>\n
Von dort haben wir die PDFs für den Drucker erstellt und auch die für den Downloadbereich für registrierte Abonnenten. Außerdem haben wir daraus per VBA eine HTML-Version erstellt, die wir in einer Access-Datenbank gespeichert haben.<\/p>\n
Es gibt eine Tabelle für die Beiträge namens tblBeitraege<\/b>, eine Tabelle für die Kategorien (tblKategorien<\/b>) sowie eine Verknüpfungstabelle, damit wir den Kategorien die Beiträge zuweisen konnten (tblBeitraegeKategorien<\/b>). Dies sind die wesentlichen Tabellen, die wir für die Übertragung der Inhalte in das WordPress-System benötigen. In der Beispieldatenbank haben wir diese Tabellen mit ein paar Beispielartikeln im HTML-Format untergebracht.<\/p>\n
Wichtig ist noch zu wissen, dass die HTML-Version mit Verweisen auf Bilder versehen sind, die sich in einem speziellen Unterverzeichnis befinden. Dieses kann man also so, wie es ist, auf den Webserver legen.<\/p>\n
Und auch die Beispieldatenbanken und sonstige Downloaddateien liegen in einer bestimmten Verzeichnisstruktur vor, die man problemlos so auf den Server übertragen kann. Hier sind nur die Verlinkungen in den Beiträgen noch anzupassen.<\/p>\n
Eine weitere Voraussetzung ist natürlich das Vorhandensein einer WordPress-Installation, auf deren SQL-Datenbank Sie auf irgendeinen Weg Zugriff haben – mehr dazu weiter unten.<\/p>\n
Ins HTML-Format<\/b><\/p>\n
Wenn Sie Beiträge aus einer Datenbank in eine WordPress-Anwendung übertragen wollen, ist es sinnvoll, wenn diese Daten bereits im HTML-Format in der Tabelle tblBeitraege <\/b>gespeichert sind. Aber woher überhaupt kommen die Beiträge, die Sie mit der Datenbank verwalten und nach WordPress überführen wollen In meinem Fall kommen diese, wie oben beschrieben, aus InDesign. InDesign bietet die Möglichkeit, Dateien in das HTML-Format zu exportieren. Das Ergebnis dieses Exports war jedoch für meine Zwecke nicht passend, sodass ich den Export selbst programmiert habe.<\/p>\n
Da vermutlich nicht viele Entwickler mit InDesign arbeiten werden, hier nur eine kurze Zusammenfassung: InDesign bietet eine VBA-Bibliothek für den VBA-gesteuerten Zugriff auf das Objektmodell. Auf dieser Basis habe ich einen Satz von Routinen geschrieben, die das InDesign-Dokument Absatz für Absatz durchlaufen und prüfen, welches Absatzformat vorliegt, und einen entsprechenden HTML-Absatz daraus erstellen. Aus einem Absatz mit dem Absatzformat Fliesstext wird dann etwa ein Text, der von den entsprechenden HTML-Tags eingefasst wird, beispielsweise <\/p>\n
…<\/p>\n
<\/b>.<\/p>\n
Die Programmierung geht jedoch über diese recht einfache Vorgehensweise hinaus, denn die Texte enthalten auch Verweise auf Bilder oder Listings in Kästen. Diese werden von den Routinen identifiziert und entsprechend behandelt. Bei einem Bild, das im InDesign-Satz unabhängig vom Fließtext in einem Kasten an beliebiger Stelle im Dokument platziert ist, landet etwa das <\/b>-Element direkt hinter dem <\/p>\n
…<\/p>\n
<\/b>-Absatz, der im Originaldokument auf das Bild verweist.<\/p>\n
Gleiches gilt für Kästen mit Listings. Die Bilder im InDesign-Dokument werden ähnlich wie in Word über Verknüpfungen angezeigt. Diese Verknüpfungen können wir auch über VBA auslesen und so den Pfad der angezeigten Bilder ermitteln.<\/p>\n
Die Bilder aus dem Originaldokument kopiere ich dann ebenfalls per VBA in ein Verzeichnis, das alle Bilddateien für das entsprechende Dokument enthält.<\/p>\n
Damit erhalte ich also für jeden Artikel einen Datensatz in der Tabelle tblBeitrage<\/b>, der den Titel des Artikels in einem Feld enthält, außerdem die Ausgabe, das Erscheinungsjahr und den HTML-Code in einem Memofeld.<\/p>\n
Die Kategorie des Artikels füge ich dann selbst über die Benutzeroberfläche hinzu. Und auch die Ausgabe und das Erscheinungsjahr wähle ich im Formular für die importierten Artikel aus. Damit ergibt sich dann das Datenmodell aus Bild 1.<\/p>\n
![\"Datenmodell](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_001.png\")
<\/p>\n
Bild 1: Datenmodell der Access-Anwendung<\/span><\/b><\/p>\n Formular zur Anzeige der Beiträge<\/b><\/p>\n Um die Prozeduren zum Erstellen der WordPress-Daten aufrufen zu können, erstellen wir uns noch ein Formular namens frmBeitraege<\/b>, mit dem wir die einzelnen Datensätze der Tabelle tblBeitraege <\/b>anzeigen (siehe Bild 2). Aus dieser Tabelle zeigen wir dabei die Werte der Felder BeitragID<\/b>, Titel<\/b>, Jahr<\/b>, Ausgabe<\/b>, Kurztext<\/b> und Inhalt <\/b>an.<\/p>\n Bild 2: Formular mit den Beiträgen und den Schaltflächen zum Übertragen nach WordPress<\/span><\/b><\/p>\n Außerdem liefert ein Unterformular namens sfmKategorien <\/b>die Daten der Verknüpfungstabelle tblBeitraegeKategorien<\/b>, genau genommen die des Feldes KategorieID<\/b>. Damit können wir die zugeordneten Kategorien auswählen.<\/p>\n Unten im Formular legen wir zwei Schaltflächen an. Die erste heißt cmdBeitragNachWordpress<\/b>. Sie soll den aktuell angezeigten Beitrag behandeln. Die zweite namens cmdAlleNachWordpress <\/b>soll sich um alle Beiträge kümmern, die sich in der Tabelle tblBeitraege <\/b>befinden.<\/p>\n Was aber heißt „behandeln“ oder „kümmern“ in diesem Fall Das müssen wir noch klären.<\/p>\n Übertragen der Artikel nach WordPress<\/b><\/p>\n Es gibt verschiedene Möglichkeiten, wie wir die HTML-Artikel nach WordPress übertragen. WordPress hat logischerweise ebenfalls eine Datenbank, welche die enthaltenen Artikel und weitere Daten speichert. Theoretisch könnten wir die Tabellen dieser meist unter MySQL verwalteten Datenbank in unsere Access-Datenbank einbinden und so direkt auf diese Tabellen zugreifen. Aus Sicherheitsgründen bieten die meisten Provider dies jedoch nicht an.<\/p>\n Das Übertragen von Daten aus den Tabellen einer lokalen Tabelle in die verknüpften Tabellen einer Datenbank auf einem Webserver ist aber auch nicht besonders herausfordernd.<\/p>\n Also gehen wir direkt den alternativen Weg, der von den meisten Providern angeboten werden sollte: die Möglichkeit, SQL-Skripte auszuführen. Das können Sie, wenn Sie kompletten Zugriff auf den Server etwa über eine Konsole haben, erledigen, indem Sie die Datei mit den entsprechenden SQL-Anweisungen auf den Server kopieren und diese dort in der Konsole aufrufen.<\/p>\n Unser Provider Aixpro <\/b>stellt uns eine komfortable Benutzeroberfläche für die Verwaltung unserer Webseiten zur Verfügung stellt.<\/p>\n Die Benutzeroberfläche heißt Plesk <\/b>und bietet die Möglichkeit, die Webseiten zu administrieren, Dateien zu verwalten und ein Tool für den Zugriff auf die SQL-Datenbanken zu öffnen, nämlich phpMyAdmin<\/b>.<\/p>\n Diese Tools sind wirklich sehr hilfreich, wenn es um die Verwaltung von Webanwendungen geht. phpMyAdmin bietet die Möglichkeit, SQL-Skripte als Datei hochzuladen und diese direkt in der aktuell angezeigten Datenbank auszuführen.<\/p>\n Unser Ziel ist es also auf jeden Fall, eine Datei mit den auszuführenden SQL-Anweisungen zu erstellen, die wir dann auf dem Webserver laden und dort ausführen können. Dies ist dann auch der kleinste gemeinsame Nenner für die verschiedenen Konfigurationsmöglichkeiten für eine WordPress-Installation.<\/p>\n Die relevanten Tabellen von WordPress<\/b><\/p>\n WordPress hat in der Basisinstallation, also ohne zusätzliche Plugins, ein recht überschaubares Datenmodell. Die für uns interessanten Tabellen befinden sich auf der Übersicht des Datenmodells, die wir der Webseite https:\/\/codex.wordpress.org <\/b>entnommen haben, im markierten Bereich (siehe Bild 3).<\/p>\n Bild 3: Datenmodell von WordPress<\/span><\/b><\/p>\n Die Tabelle wp_posts <\/b>enthält die einzelnen Artikel. Das Feld postTitle <\/b>nimmt dabei den Titel auf, das Feld post_content <\/b>(im Screenshot post_content_filtered <\/b>benannt) nimmt den Artikel selbst auf. Die Kategorien können wir in der Tabelle wp_Terms <\/b>hinterlegen. Die Tabelle wp_term_taxonomy <\/b>weist den Kategorien aus wp_terms <\/b>eine Funktion zu, nämlich Kategorie, Link oder Tag, und definiert die Hierarchie der Einträge der Tabelle wp_Terms <\/b>– das ist für die Erschaffung einer Kategorien-Hierarchie wichtig.<\/p>\n Die Hierarchie wird über das Feld parent <\/b>erzeugt, das auf das Primärschlüsselfeld term_taxonomy_id <\/b>der gleichen Tabelle verweist. Die Tabelle wp_term_relationsships <\/b>verknüpft wiederum die Einträge der Tabelle wp_term_taxonomy <\/b>und die Artikel aus der Tabelle wp_posts <\/b>miteinander. Für uns ist diese Tabelle also wichtig, weil wir über diese die Artikel den Kategorien zuweisen können, die wir in der Tabelle wp_terms <\/b>definiert haben.<\/p>\n Zu beachten<\/b><\/p>\n Bevor wir die Daten einfach von Access in die WordPress-Tabellen übertragen, ist etwas unter Umständen sehr wichtiges zu beachten – zumindest war das bei meinem Projekt der Fall. Die Artikel existierten ja zuvor bereits auf einer anderen Webseite, in diesem Fall einer auf Basis des CMS-Systems Typo3. Hier sind die Links auf die Artikel wie folgt aufgebaut:<\/p>\n Dabei war die einzige Variable die Zahl für den Parameter BeitragID<\/b>. Wenn man eine Webseite neu aufbaut, die bei Google bereits ein gutes Ranking erreicht hat, sollte man sicherstellen, dass die Adresse, unter welcher die gerankten Artikel erreichbar sind, gleich bleibt. Natürlich gibt es technische Möglichkeiten, dafür zu sorgen, dass wenn der Benutzer einen Google-Link auf die Seite anklickt, auch die auf dem neuen Server unter einer anderen Adresse gespeicherte Seite angezeigt wird. Unter WordPress sehen die Links normalerweise wie folgt aus:<\/p>\n Man kann nun auf dem Server bestimmte Regeln einrichten, nach denen etwa der obige, alte Link in den neuen Link umbenannt wird – das ist allerdings ein Thema, das wir in diesem Beitrag nicht mehr anreißen wollen.<\/p>\n Für uns ist nur interessant, dass es zum Definieren einer solchen Regel einfach ist, wenn wir den dynamischen Teil der alten Adresse, hier also den Parameter BeitragID<\/b>, auslesen und diesen dann in Form des Parameters p <\/b>für den Link zur neuen Webseite nutzen können.<\/p>\n Mein Plan war also zunächst, die Artikel in der Tabelle wp_posts <\/b>genauso zu nummerieren wie in der Tabelle tblBeitraege<\/b>. So wäre es dann am einfachsten, per URL auf die Artikel zuzugreifen.<\/p>\n Das hat auch zu Beginn gut geklappt, nämlich als die WordPress-Datenbank und speziell die Tabelle wp_posts <\/b>noch komplett leer war. Dann allerdings habe ich zum Beispiel einen Beitrag bearbeitet oder Menüeinträge hinzugefügt.<\/p>\n Und sowohl für die Bearbeitungsstände von WordPress-Artikeln als auch für Menüeinträge werden neue Datensätze in der Tabelle wp_posts <\/b>angelegt. Ich hatte zwar nun die Datensätze mit den Primärschlüsselwerten bis etwa 1.200 mit Beiträgen gefüllt und jeder dieser Artikel hatte den seiner ID entsprechenden Primärschlüsselwert.<\/p>\n Die angelegten Menüs und die Bearbeitungsstände der editierten Artikel haben dann allerdings die Primärschlüsselwerte ab 1.200 in Beschlag genommen – die nächsten Werte wie 1.201, 1.202 und so weiter waren also belegt. Neue Beiträge hätte ich dann also mit Lücken in den ID-Werten hinzufügen müssen. Das war erstens ein Problem, weil ich die Beitrag-IDs zumindest einigermaßen lückenlos halten wollte und zweitens die Beiträge ja bereits weit vor der Veröffentlichung in der Artikeldatenbank angelegt wurden und somit bereits feste ID-Werte erhalten haben. Also sollten diese dann auch unter den vergebenen ID-Werten in der Tabelle wp_posts <\/b>landen.<\/p>\n Es musste also eine alternative Lösung her, die zukunftssicher war und gleichzeitig die IDs der Beiträge im Primärschlüsselfeld enthielt. Also habe ich mich entschieden, einfach eine recht große Zahl zu den IDs hinzuzuaddieren – in diesem Fall 55.000.000 – und somit für alle Zeiten genügend freie IDs für alle sonstigen Zwecke vorzuhalten. Der Beitrag mit der ID 1.201 <\/b>würde also in der Tabelle wp_posts <\/b>unter dem Primärschlüsselwert 55.001.201 <\/b>abgespeichert werden.<\/p>\n Sie mögen jetzt einwerfen, dass man dann nicht mehr so einfach über einer URL wie www.access-im-unternehmen.de\/1201 <\/b>auf den Beitrag zugreifen kann. Das hätte natürlich gravierende Folgen, denn wir haben diese Nummern in jedem Beitrag in den gedruckten Heften angegeben, damit die Leser darunter die Downloads mit den Beispieldatenbanken zu dem jeweiligen Beitrag beziehen können.<\/p>\n Das ist aber auch kein Problem: Wir haben ja bereits beschrieben, dass wir auf dem Server definieren können, dass URLs geändert werden können. Und so lässt sich auch aus www.access-im-unternehmen.de\/1201 <\/b>relativ leicht www.access-im-unternehmen.de\/p=1201 <\/b>erzeugen. Der Leser soll dann also sowohl über den im Heft angegebenen Link www.access-im-unternehmen.de\/1201 <\/b>als auch über die bei Google gespeicherten URLs wie www.access-im-unternehmen.de\/index1.phpid=300&BeitragID=1201 <\/b>auf die Beiträge zugreifen können. Und das können wir durch entsprechende Regeln auch erreichen, wenn die ID eigentlich 55001201 <\/b>lautet.<\/p>\n Löschen und neu anlegen<\/b><\/p>\n Gerade in der Testphase wird es oft vorkommen, dass Sie die Datensätze in der WordPress-Datenbank löschen und neu anlegen wollen. Wir haben dies in den folgenden Prozeduren berücksichtigt.<\/p>\n Da wir nicht nur für die Beiträge Primärschlüsselwerte in einem bestimmten Bereich verwenden wollen (ab 55.000.001), sondern auch für die Kategorien in der Tabelle wp_terms <\/b>(ab 88.000.001) und für die ebenfalls dort definierten Jahre (ab 99.001) und die untergeordneten Ausgaben (ab 99.000.001), können wir die Datensätze jeweils auch wieder entfernen, damit wir sie anschließend jederzeit wieder reproduzieren können.<\/p>\n Das ist aber nicht der alleinige Grund dafür, dass wir auch Kategorien, Ausgaben und Jahre mit solch hohen Werten gefüllt werden sollen. Der nächste Grund ist, dass wir später noch eine Menüstruktur auf Basis der Kategorien, Ausgaben und Jahre aufbauen wollen. Und damit wir diese nicht immer wieder neu erstellen müssen, wenn wir die Kategorien, Ausgaben und Jahre neu hinzugefügt haben, verwenden wir für diese genau wie für die Beiträge immer die gleichen ID-Werte.<\/p>\n Beiträge und Kategorien nur per Access<\/b><\/p>\n Damit dies funktioniert, dürfen Sie Änderungen an Beiträgen und Kategorien natürlich nur über die Datenbank durchführen. Jede Änderung, die Sie über den Editor von WordPress durchgeführt haben, wird ja sonst bei einem erneuten Einspielen der Daten der Access-Datenbank wieder überschrieben.<\/p>\n Prozedur zum Übertragen der Beiträge<\/b><\/p>\n Beginnen wir mit der Prozedur, die durch die beiden Ereignisprozeduren des Formulars aufgerufen wird. Diese beiden Ereignisprozeduren sehen wie folgt aus:<\/p>\n Die Prozeduren rufen beide die Routine WordPressExport <\/b>auf (siehe Listing 1). Diese erwartet als optionalen Parameter eine Beitrag-ID. Wird kein Wert übergeben, nimmt der Parameter lngBeitragID <\/b>den Standardwert 0 <\/b>an.<\/p>\n <\/p>\n Listing 1: Prozedur zum Erstellen des SQL-Skripts für die Beiträge<\/span><\/b><\/p>\n Die Prozedur legt zunächst einen Dateinamen fest – und zwar für die Datei, in der wir die SQL-Anweisungen speichern wollen, die wir zum Übertragen der Daten benötigen. Bei der in unserem Fall anfallenden Datenmenge reicht das Kopieren in die Zwischenablage zum direkten Eingeben in MySQL nicht mehr aus, daher legen wir gleich eine Datei mit dem Namen SQLBeitraege.sql <\/b>im Verzeichnis der aktuellen Datenbank an. Danach löschen wir die Datei, falls diese schon vorhanden ist. Dann erstellen wir für die Variable db <\/b>einen Verweis auf das aktuelle Database<\/b>-Objekt.<\/p>\n Die folgende If…Then<\/b>-Bedingung stellt eine WHERE<\/b>-Klausel für die zu berücksichtigenden Beiträge zusammen. Diese legt auf jeden Fall fest, dass das Feld, dessen Namen wir in der Konstanten cstrFeldInhalt <\/b>festlegen, nicht Null sein darf und welche Beiträge abhängig vom übergebenen Wert für den Parameter lngBeitragID <\/b>berücksichtigt werden sollen. Die Konstante cstrFeldInhalt <\/b>haben wir festgelegt, damit wir das Feld, das den Inhalt liefert, flexibel an einer Stelle ändern können.<\/p>\n Danach füllen wir eine Recordset-Variable namens rst <\/b>mit einer Abfrage, die Daten der Tabelle tblBeitraege <\/b>liefert – abhängig davon, ob einer oder alle Beiträge berücksichtigt werden sollen. Danach legt die Prozedur mit der Open<\/b>-Anweisung die zu füllende Textdatei an.<\/p>\n In einer Do While<\/b>-Schleife über alle Datensätze des Recordsets stellt die Prozedur in der Variablen strSQLDelete <\/b>eine Anweisung zusammen, welche den Eintrag aus der Tabelle wp_posts <\/b>löscht, dessen ID-Wert der Zahl 55.000.000 <\/b>plus dem Primärschlüsselwert aus der Tabelle tblBeitraege <\/b>entspricht. Der Inhalt der Variablen strSQLDelete <\/b>wird dann mit der Print<\/b>-Anweisung in die Textdatei geschrieben. Diese Anweisungen sehen dann beispielsweise wie folgt aus:<\/p>\n Nachdem so alle DELETE<\/b>-Anweisungen in die Textdatei geschrieben wurden, springen wir mit der MoveFirst<\/b>-Methode wieder zum ersten Datensatz des Recordsets zurück und durchlaufen die Schleife erneut. Diesmal stellen wir in einigen String-Variablen die Werte aus dem Feldern der Tabelle tblBeitraege <\/b>zusammen, die in der Tabelle wp_posts <\/b>landen sollen.<\/p>\n Hier nutzen wir dann beispielsweise noch eine Funktion namens Ersetzen<\/b>, die noch vorhandene Umlaute et cetera durch die entsprechenden HTML-Entitäten ersetzt. Diese Funktion stellen wir weiter unten vor.<\/p>\n Dann stellen wir die INSERT INTO<\/b>-Anweisung in der Variablen strSQL <\/b>zusammen. Diese Abfragen sind natürlich etwas umfangreicher, da sie unter anderem den kompletten HTML-Code enthalten:<\/p>\n Für viele der Felder der Tabelle wp_posts <\/b>haben wir Standardwerte verwendet. Einige haben wir jedoch mit den Inhalten aus der Quelltabelle tblBeitraege <\/b>versehen. Dazu gehören natürlich die drei Felder post_content<\/b>, post_title <\/b>und post_excerpt<\/b>. Das Feld post_date <\/b>haben wir mit einem Datum gefüllt, das wir aus den Feldern Ausgabe <\/b>und Jahr <\/b>des jeweiligen Beitrags zusammengestellt haben.<\/p>\n Somit kann der Benutzer direkt erkennen, wann der Beitrag ursprünglich geschrieben wurde. Das Feld post_type <\/b>erhält den Wert post<\/b>. Und natürlich weisen wir dem Feld ID <\/b>den Wert des Primärschlüsselfeldes BeitragID <\/b>plus 55.000.000 <\/b>zu.<\/p>\n Auch diese Anweisung schreiben wir wieder in die Textdatei. Zwischendurch ist Ihnen sicher die Anweisung DoEvents <\/b>aufgefallen. Diese bauen wir immer ein, wenn Schleifen sehr oft durchlaufen werden, da es sonst passieren kann, dass der VBA-Editor zwischendurch nicht mehr ansprechbar ist.<\/p>\n Dem wirken Sie entgegen, indem Sie in Schleifen die DoEvents<\/b>-Anweisung einbauen. Dann können Sie solche Schleifen immer mit der Tastenkombination Strg + Rollen\/Unterbrechen<\/b> unterbrechen.<\/p>\n Danach rufen wir noch zwei weitere Routinen namens KategorienArtikel <\/b>und KategorienAusgaben <\/b>auf und schließen die geöffnete Textdatei mit der Close<\/b>-Methode.<\/p>\n Mit der ersten Prozedur allein haben wir jedoch schon erreicht, dass all unsere Beiträge aus der Tabelle tblBeitraege <\/b>in der WordPress-Tabelle wp_posts <\/b>gelandet sind.<\/p>\n Kategorien in WordPress<\/b><\/p>\n Weiter oben haben wir bereits erwähnt, dass wir zusätzlich zu den Beiträgen auch noch Kategorien in WordPress importieren wollen. Aber ist das überhaupt nötig Je nach Einsatzzweck nicht unbedingt. Es gibt in Blog-Systemen wie WordPress so viele Möglichkeiten, auf die Beiträge zuzugreifen.<\/p>\n Zunächst einmal werden die aktuellsten Beiträge standardmäßig auf der Startseite angezeigt. Dann gibt es Archive, die meist in der Seitenleiste („Sidebar“) aufgeführt werden und über die man die Beiträge eines Monats oder eines anderen Zeitraums anzeigen kann.<\/p>\n Ein weiteres beliebtes Mittel zur Anzeige von Artikeln ist die Schlagwortwolke oder Wordwolke, welche die beliebtesten Begriffe auf verschiedene, mehr oder weniger verspielte Art darstellt.<\/p>\n Und schließlich wäre da noch die Suchfunktion, die alle Beiträge liefert, welche die gewünschten Suchbegriffe enthält.<\/p>\n Aber wir wollen ja ein für den Benutzer ähnliches oder besseres Erlebnis bieten, wie es mit der vorherigen Webseite der Fall war. Diese hat eine Übersicht mit allen Artikeln angeboten. Eine solche Übersicht gibt es, wenn auch nicht auf einer Seite, sondern mit vielen Seiten zum Durchblättern, bereits standardmäßig über die Startseite.<\/p>\n Aber damit der Benutzer schnell einen Beitrag einer bestimmten Ausgabe findet, soll er sowohl die Jahre als auch die Ausgaben angezeigt bekommen. Außerdem wollen wir die bereits mit den Beiträgen verknüpften Kategorien anzeigen, damit der Benutzer sich beispielsweise alle Beiträge zu einem bestimmten Thema ansehen kann.<\/p>\n Kategorien übertragen und mit Beiträgen verknüpfen<\/b><\/p>\n Wie dem Datenmodell von WordPress von weiter oben zu entnehmen ist, benötigen wir für die Kategorien jeweils die folgenden Elemente (unter Bild 4 nochmal der relevante Ausschnitt des Datenmodells):<\/p>\n Bild 4: Datenmodell von WordPress mit den für die Kategorien relevanten Tabellen<\/span><\/b><\/p>\n Genau wie bei den Beiträgen wollen wir auch bei den IDs für die Kategorien in wp_terms <\/b>und in wp_term_taxonomy <\/b>sicherstellen, dass wir einen freien Bereich haben.<\/p>\n Dementsprechend wollen wir für die IDs für die Einträge in wp_terms <\/b>zu 88.000.000 hinzuaddieren, wenn wir die IDs aus der Tabelle tblKategorien <\/b>unserer lokalen Access-Datenbank beziehen.<\/p>\n Diese Aufgabe erledigen wir mit der Funktion KategorienArtikel<\/b>, die von der weiter oben beschriebenen Prozedur WordPressExport <\/b>aufgerufen wird, nachdem die Beiträge in die Tabelle wp_posts <\/b>geschrieben worden sind (siehe Listing 2).<\/p>\n Listing 2: Prozedur zum Erstellen des SQL-Codes für die Kategorien<\/span><\/b><\/p>\n Die Kategorien liegen in der Tabelle tblKategorien <\/b>etwa wie in Bild 5 vor. Die Funktion KategorienArtikel <\/b>erwartet einen Parameter namens strWhere<\/b>, den wir bereits in der aufrufenden Prozedur zusammenstellen und der die zu berücksichtigenden Artikel einschränkt, für die wir eine Beziehung zu einer oder mehreren Kategorien herstellen wollen.<\/p>\n Bild 5: Kategorien-Tabelle in Access<\/span><\/b><\/p>\n Um alle relevanten Kategorien zu ermitteln, verwenden wir die Abfrage qryAlleBenutztenKategorien<\/b> aus Bild 6. Diese liefert alle Kategorien der Tabelle tblKategorien<\/b>, die über die Verknüpfungstabelle tblBeitraegeKategorien <\/b>mit einem Beitrag aus der Tabelle tblBeitraege <\/b>verknüpft sind. In der folgenden OpenRecordset<\/b>-Methode verwenden wir diese Abfrage und fügen das mit strWhere <\/b>gelieferte Kriterium noch zur Abfrage hinzu.<\/p>\n Bild 6: Abfrage mit allen benutzten Tabellen<\/span><\/b><\/p>\n Dann durchlaufen wir alle Datensätze dieser Abfrage in einer Do While<\/b>-Schleife. Im Gegensatz zur aufrufenden Prozedur schreiben wir die hier zusammengestellten Anweisungen nicht direkt in die Textdatei, sondern stellen diese in zwei String<\/b>-Variablen namens strSQLDelete <\/b>und strSQL <\/b>zusammen. Die erste Anweisung in strSQLDelete <\/b>soll den Eintrag in der Tabelle wp_terms <\/b>löschen und sieht für die Kategorie mit der ID 25 <\/b>in der Access-Tabelle wie folgt aus: <\/p>\n Dann folgt die Anweisung, mit der wir die SQL-Anweisung zum Löschen des entsprechenden Eintrags der Tabelle wp_term_taxonomy <\/b>hinzufügen, der hier so aussieht:<\/p>\n Dann fügen wir die beiden INSERT INTO<\/b>-Anweisungen zur Variablen strSQLINSERT <\/b>hinzu, mit denen die entsprechenden Einträge neu hinzugefügt werden. Diese sehen so aus:<\/p>\n Ein solcher Aufruf für nur einen Beitrag, der nur einer Kategorie zugeordnet ist, wäre also zum Beispiel schon sinnvoll, wenn Sie in der Access-Datenbank den Namen dieser Kategorie geändert hätten.<\/p>\n Aber wir erneuern ja auch noch die Daten in der Tabelle wp_term_relationships<\/b>, um die Daten der Tabelle wp_term_taxonomy <\/b>mit den Daten der Tabelle wp_posts <\/b>zu verknüpfen. Das erledigen wir in einer weiteren Schleife, diesmal über alle Einträge der Tabelle tblBeitraege<\/b>, die mit der aktuellen Kategorie des übergeordneten Recordsets verknüpft sind – zusätzlich selektiert nach der mit strWhere <\/b>übergebenen Bedingung.<\/p>\n In dieser Schleife fügen wir sowohl strSQLDelete <\/b>als auch strSQLInsert <\/b>je eine Anweisung für jede Kombination aus Beitrag und Kategorie hinzu. Als Erstes die DELETE<\/b>-Anweisung, die den Eintrag für die aktuelle Kombination aus Beitrag und Kategorie aus der Tabelle wp_term_relationsships <\/b>entfernt:<\/p>\n Und die INSERT INTO<\/b>-Anweisung fügt jeweils einen Eintrag für die Kombination aus Beitrag und Kategorie zur Tabelle wp_term_relationships <\/b>hinzu:<\/p>\n Wenn wir beim Aufruf der Prozedur WordPressExport <\/b>einen Parameter für den gegebenenfalls zu löschenden und neu hinzuzufügenden Beitrag übergeben, liefert die Funktion KategorienArtikel<\/b> die beschriebenen sechs Anweisungen – vorausgesetzt, der Beitrag ist nur einer Kategorie zugeordnet. Sonst werden es entsprechend mehr Anweisungen.<\/p>\n Wenn kein Parameter übergeben wird, stellt die Funktion KategorienArtikel <\/b>die Anweisungen für alle Kombinationen aus Beiträgen und Kategorien zusammen und gibt die SQL-Anweisungen als Funktionswert an die aufrufende Prozedur zurück, die diese dann ebenfalls in die Textdatei mit dem SQL-Skript einfügt.<\/p>\n Kategorien für Jahre und Ausgaben<\/b><\/p>\n Neben den eigentlichen Kategorien wollen wir auch für die Jahre und Ausgaben noch Menüeinträge erschaffen, wofür vorher noch die entsprechenden Kategorien angelegt werden müssen. Das Ergebnis soll später wie in Bild 7 aussehen.<\/p>\n Bild 7: Kategorien für Jahre und Ausgaben<\/span><\/b><\/p>\n Die für die Erstellung der Kategorien für die Jahre und Ausgaben verantwortliche Funktion heißt KategorienAusgaben <\/b>und sieht wie in Listing 3 aus. Genau wie die vorherige Funktion erwartet sie einen Parameter, der festlegt, für welche Beiträge die Datensätze hinzugefügt werden sollen.<\/p>\n Listing 3: Prozedur zum Erstellen des SQL-Codes für die Kategorien für die Jahre und Ausgaben<\/span><\/b><\/p>\n Diese Funktion erstellt zunächst ein Recordset, das alle Einträge des Feldes Jahr<\/b> der Tabelle tblBeitraege <\/b>enthält. Dabei kommt zum ersten Mal die Bedingung aus dem Parameter strWhere <\/b>zum Tragen. Außerdem sortieren wir die Einträge aufsteigend nach dem Jahr. Die DISTINCT<\/b>-Klausel sorgt dafür, dass jeder Wert des Feldes Jahr nur einmal zurückgeliefert wird.<\/p>\n Dieses Recordset durchlaufen wir dann in einer Do While<\/b>-Schleife. Die ersten beiden Anweisungen fügen der Variablen strSQLDelete <\/b>die folgenden beiden Anweisungen hinzu:<\/p>\n Wir löschen also Einträge aus der Tabelle wp_terms<\/b>, die der Jahreszahl plus 990.000 entsprechen, und die passenden Einträge aus der Tabelle wp_term_taxonomy<\/b>.<\/p>\n Die nächsten beiden Anweisungen fügen genau diese Einträge wieder (oder erstmalig) zu diesen beiden Tabellen hinzu:<\/p>\n Danach erstellt die Prozedur ein weiteres Recordset namens rstAusgaben<\/b>. Dieses erfasst alle Werte des Feldes Ausgabe <\/b>der Tabelle tblBeitraege<\/b>, die zu dem Jahr gehören, das wir in der übergeordneten Schleife durchlaufen und welche die Bedingungen aus strWhere <\/b>erfüllen. Auch hier verwenden wir die DISTINCT<\/b>-Klausel, damit jede Ausgabe nur einmal zurückgegeben wird, und sortieren aufsteigend nach dem Feld Ausgabe<\/b>.<\/p>\n Dieses Recordset durchlaufen wir nun in einer untergeordneten Do While<\/b>-Schleife. In dieser kommen zwei weitere DELETE<\/b>-Anweisungen zu strSQLDelete <\/b>hinzu:<\/p>\n Hier löschen wir also Einträge aus den Tabellen wp_terms <\/b>und wp_term_taxonomy<\/b>, welche aus der Ausgabe (01<\/b>), und dem Jahr (2000<\/b>) zusammengesetzt und zu denen der Wert 99.000.000 <\/b>addiert wurde.<\/p>\n Und natürlich fehlen nicht die INSERT INTO<\/b>-Anweisungen, um die gewünschten Datensätze in die Tabellen wp_terms <\/b>und wp_term_taxonomy <\/b>einzutragen:<\/p>\n Schließlich fehlt noch ein drittes Recordset und damit verbunden eine dritte Schleife, in der wir die Beiträge der jeweiligen Ausgabe zur Kategorie hinzufügen.<\/p>\n Dieses Recordset verwendet wieder eine Abfrage auf Basis der Tabelle tblBeitraege<\/b>, die diesmal nach strWhere<\/b>, dem Jahr <\/b>und der Ausgabe <\/b>gefiltert wird. Die Do While<\/b>-Schleife auf Basis dieses Recordsets fügt zunächst eine Anweisung zum Löschen des Eintrags der Tabelle wp_term_relationsships <\/b>hinzu, welcher den Beitrag mit dem Eintrag der Tabelle wp_term_taxonomy <\/b>verknüpft:<\/p>\n Die letzte Anweisung der Schleife fügt den INSERT INTO<\/b>-Befehl zum Hinzufügen des benötigten Datensatzes hinzu:<\/p>\n Schließlich gibt die Funktion die so erstellten SQL-Anweisungen als Funktionswert an die aufrufende Prozedur zurück.<\/p>\n Von der Kategorie zum Menüeintrag<\/b><\/p>\n Nun haben wir zwar die Kategorien zur Tabelle wp_terms <\/b>hinzugefügt, zu jeder Kategorie einen Eintrag in wp_term_taxonomy <\/b>angelegt und die Beziehung zwischen den Beiträgen aus wp_posts <\/b>mit den Einträgen aus wp_term_taxonomy <\/b>über die Tabelle wp_term_relationships <\/b>definiert.<\/p>\n Allerdings erscheinen die Kategorien noch immer nicht als Menüeinträge. Und an dieser Stelle hat der Forschungsdrang nicht mehr ausgereicht und wir haben die Menü-Einträge manuell über die Benutzeroberfläche von WordPress erstellt. Das gelingt, wenn Sie den Menüeintrag Design|Menüs <\/b>auswählen. Es erscheint dann der Bereich aus Bild 8, wo Sie links auf Kategorien <\/b>wechseln und alle Kategorien anzeigen lassen. Sie fügen dann erst einmal alle gewünschten Kategorien hinzu und können diese per Drag and Drop wie gewünscht anordnen.<\/p>\n Bild 8: Verwalten der Menüs in WordPress<\/span><\/b><\/p>\n Dies erzeugt unter anderem Einträge in der Tabelle wp_posts<\/b>, deren Feld post_type <\/b>den Wert nav_menu_item <\/b>aufnimmt. Da sich diese Einträge auf die von uns immer mit den gleichen IDs gespeicherten Kategorien beziehen, können Sie diese einmal anlegen. Wenn Sie dann später die Beiträge und Kategorien, Jahre und Ausgaben über die Access-Datenbank neu hochladen, greifen auch die Menüeinträge immer noch auf diese Kategorien zu.<\/p>\n Problem Autowert<\/b><\/p>\n Nachdem wir so gearbeitet haben, ist uns allerdings aufgefallen, dass WordPress uns durch die Autowert-Funktion beim Anlegen neuer Einträge etwa in der Tabelle wp_posts <\/b>immer noch einen Strich durch die Rechnung macht, was das Reservieren bestimmter Bereiche für unsere Beiträge und Kategorien angeht.<\/p>\n Wenn wir also etwa Beiträge bis zur ID 55.001.200 <\/b>angelegt haben, was 55.000.000 <\/b>plus Beitrags-ID 1.200 <\/b>entspricht, dann wird ein über die Benutzeroberfläche angelegter Menüeintrag die ID 55.001.201 <\/b>erhalten.<\/p>\n Wenn wir dann beim Anlegen neuer Beiträge einen Beitrag mit der ID 55.001.201 <\/b>anlegen, wird der Menüeintrag überschrieben. Was wir aber machen können, ist das Hinzufügen von Dummy-Datensätzen. Für die Tabelle wp_posts <\/b>legen wir also etwa einen Datensatz mit der ID 60.000.000 <\/b>an.<\/p>\n Dann reichen die ID noch für eine knappe Million Beiträge, was auch bei sehr hoher Produktivität ausreichend sein sollte. Und die folgenden, automatisch von WordPress beim Anlegen neuer Einträge in der Tabelle wp_posts <\/b>vergebenen Primärschlüsselwerte sind dann größer als 60.000.000.<\/p>\n Die Funktion Ersetzen<\/b><\/p>\n Weiter oben haben wir noch die Funktion Ersetzen <\/b>angesprochen, die in der Prozedur WordPressExport <\/b>an zwei Stellen eingesetzt wird – einmal für den in strTitel <\/b>gespeicherten Text und einmal für strKurztext<\/b>.<\/p>\n Die Funktion hat den Zweck, Vorkommen von Texten oder Zeichen, die unter HTML nicht angezeigt werden können, durch entsprechende HTML-Entitäten zu ersetzen. Dazu gehören etwa die Umlaute oder Sonderzeichen.<\/p>\n In dieser Funktion haben wir auch noch Bereiche untergebracht, die HTML-Tags von Absätzen untersuchen und ersetzen können.<\/p>\n Das ist wichtig, wenn Ihnen zwar Beiträge bereits im HTML-Format vorliegen, aber dort noch Änderungen durchgeführt werden müssen, damit der Inhalt des Dokuments in WordPress korrekt dargestellt wird.<\/p>\n Wie diese Funktion funktioniert, zeigen wir im Beitrag HTML-Code optimieren per VBA <\/b>(www.access-im-unternehmen.de\/1218<\/b>) in der kommenden Ausgabe.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Wenn Sie eine WordPress-Seite haben und diese mit Beiträgen füttern wollen, die bereits in einer Access-Tabelle vorliegen, hat dieser Beitrag alle notwendigen Informationen geliefert.<\/p>\n Sie lernen die relevanten Teile des Datenmodells von WordPress kennen und erfahren, wie Sie die Daten aus einer einfachen, aus den Tabellen tblBeitraege<\/b>, tblKategorien <\/b>und tblBeitraegeKategorien <\/b>bestehendem Datenmodell nach WordPress übertragen können.<\/p>\n Sollten die Daten bei Ihnen in einem anderen Format vorliegen wie etwa nur in den Tabellen tblBeitraege <\/b>und tblKategorien<\/b>, können Sie den Code leicht anpassen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n WordPress.accdb<\/p>\n![\"Formular](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_002.png\")
<\/p>\n![\"Datenmodell](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_004.png\")
<\/p>\nhttp:\/\/www.access-im-unternehmen.de\/index1.phpid=300&BeitragID=1<\/pre>\n
http:\/\/www.access-im-unternehmen.de\/p=1<\/pre>\n
Private Sub <\/span>cmdAlleNachWordpress_Click()\r\n WordPressExport\r\nEnd Sub<\/span>\r\nPrivate Sub <\/span>cmdBeitragNachWordpress_Click()\r\n WordPressExport Me!BeitragID\r\nEnd Sub<\/span><\/pre>\nPublic Sub <\/span>WordPressExport(Optional<\/span> lngBeitragID As Long<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>strSQL As String<\/span>, strSQLDelete As String<\/span>, strDateiname As String<\/span>\r\n Dim <\/span>strInhalt As String<\/span>, strTitel As String<\/span>\r\n Dim <\/span>strKurztext As String<\/span>, strWhere As String<\/span>\r\n strDateiname = CurrentProject.Path & \"SQLBeitraege.sql\"\r\n On Error Resume Next<\/span>\r\n Kill strDateiname\r\n On Error GoTo<\/span> 0\r\n Set<\/span> db = CurrentDb\r\n If <\/span>Not<\/span> lngBeitragID = 0 Then<\/span>\r\n strWhere = \"tblBeitraege.BeitragID = \" & lngBeitragID & \" AND NOT \" & cstrFeldInhalt & \" IS NULL\"\r\n Else<\/span>\r\n strWhere = \"NOT \" & cstrFeldInhalt & \" IS NULL\"\r\n End If<\/span>\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM tblBeitraege WHERE \" & strWhere, dbOpenDynaset)\r\n Open strDateiname For Append As <\/span>#1\r\n Do While<\/span> Not<\/span> rst.EOF\r\n strSQLDelete = \"DELETE FROM wp_posts WHERE ID = \" & 55000000 + rst!BeitragID & \";\" & vbCrLf<\/span>\r\n DoEvents\r\n Print #1, strSQLDelete\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\n rst.MoveFirst\r\n Do While<\/span> Not<\/span> rst.EOF\r\n strInhalt = rst(cstrFeldInhalt)\r\n strTitel = rst!Titel\r\n strTitel = Ersetzen(strTitel)\r\n strKurztext = rst!Kurztext\r\n strKurztext = Ersetzen(strKurztext)\r\n strSQL = \"INSERT INTO wp_posts(ID, post_author, post_date, post_date_gmt, post_content, post_title, \" _\r\n & \"post_excerpt, post_status, comment_status, ping_status, post_name, post_parent, guid, menu_order, \" _\r\n & \"post_type, comment_count) VALUES(\" & 55000000 + rst!BeitragID & \", 1, '\" _\r\n & format(DateSerial(rst!Jahr, rst!Ausgabe * 2, 1), \"yyyy-mm-dd hh:nn:ss\") & \"', '\" & format(Now, _\r\n \"yyyy-mm-dd hh:nn:ss\") & \"', '\" & strInhalt & \"', '\" & strTitel & \"', '\" & strKurztext _\r\n & \"', 'publish', 'open', 'open', '\" & Replace<\/span>(Replace<\/span>(rst!Titel, \" \", \"_\"), \"'\", \"''\") & \"', \" _\r\n & \"0, 'http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/p=\" & rst!BeitragID & \"', 0, 'post', 0);\" & vbCrLf<\/span>\r\n Print #1, strSQL\r\n DoEvents\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\n Print #1, KategorienArtikel(strWhere)\r\n Print #1, KategorienAusgaben(strWhere)\r\n Close #1\r\nEnd Sub<\/span><\/pre>\nDELETE FROM wp_posts WHERE ID = 55000001;<\/pre>\n
INSERT INTO wp_posts(ID, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt, post_status, comment_status, ping_status, post_name, post_parent, guid, menu_order, post_type, comment_count) VALUES(55000001, 1, '2000-02-01 00:00:00', '2019-09-17 13:10:32', '<p><b>Wenn Sie bereits einmal Datenbankanwendungen mit VBA-Funktionen und -Prozeduren entwickelt haben, kennen Sie bereits das Vergnügen, sich mit dem Auffinden und Beheben der unterschiedlichsten Fehler herumzuschlagen - es sei denn, Sie programmieren so gut, dass nie Fehler auftreten. Im vorliegenden Beitrag erfahren Sie, welche Fehlerarten bei der Arbeit mit VBA auftreten können, wie man die Fehler findet und sie schließlich behebt. Dabei lernen Sie auch die unterschiedlichen Möglichkeiten der Fehlersuche kennen.<\/b><\/p>\r\n<h2>Fehlerarten in VBA<\/h2>\r\n<p>Die Fehlerarten, die bei der Programmierung mit VBA auftreten, können in drei unterschiedliche Gruppen eingeteilt werden.<\/p>...', 'Fehlersuche und -behandlung mit Access', 'Wenn Sie bereits einmal Datenbankanwendungen mit VBA-Funktionen und -Prozeduren entwickelt haben, kennen Sie bereits ....', 'publish', 'open', 'open', 'Fehlersuche_und_-behandlung_mit_Access', 0, 'http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/p=1', 0, 'post', 0);<\/pre>\n
![\"Datenmodell](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_003.png\")
<\/p>\n\n
Public Function <\/span>KategorienArtikel(strWhere As String<\/span>) As String<\/span>\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>rstBeitraege As <\/span>DAO.Recordset\r\n Dim <\/span>strSQL As String<\/span>\r\n Dim <\/span>strSQLDelete As String<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM qryAlleBenutztenKategorien WHERE \" & strWhere, dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rst.EOF\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_terms WHERE term_id = \" & 88000000 + rst!KategorieID & \";\" & vbCrLf<\/span>\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_term_taxonomy WHERE term_id = \" & 88000000 + rst!KategorieID _\r\n & \";\" & vbCrLf<\/span>\r\n strSQLINSERT = strSQLINSERT & \"INSERT INTO wp_terms(term_id, name, slug, term_group) VALUES(\" & 88000000 _\r\n + rst!KategorieID & \", '\" & rst!Kategorie & \"', '\" & Replace<\/span>(rst!Kategorie, \" \", \"_\") & \"', 0);\" & vbCrLf<\/span>\r\n strSQLINSERT = strSQLINSERT & \"INSERT INTO wp_term_taxonomy(term_taxonomy_id, term_id, taxonomy, \" _\r\n & \"description, parent, count) VALUES(\" & 88000000 + rst!KategorieID & \", \" & 88000000 + rst!KategorieID _\r\n & \", 'category', '', 0, 0);\" & vbCrLf<\/span>\r\n Set<\/span> rstBeitraege = db.OpenRecordset(\"SELECT tblBeitraege.* FROM tblBeitraege INNER JOIN \" _\r\n & \"tblBeitraegeKategorien ON tblBeitraege.BeitragID = tblBeitraegeKategorien.BeitragID WHERE \" & strWhere _\r\n & \" AND KategorieID = \" & rst!KategorieID & \";\", dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rstBeitraege.EOF\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_term_relationships WHERE object_id = \" & 55000000 + _\r\n & rstBeitraege!BeitragID & \" AND term_taxonomy_id = \" & 88000000 + rst!KategorieID & \";\" & vbCrLf<\/span>\r\n strSQLINSERT = strSQLINSERT & \"INSERT INTO wp_term_relationships(object_id, term_taxonomy_id, \" _\r\n & \"term_order) VALUES(\" & 55000000 + rstBeitraege!BeitragID & \", \" & 88000000 + CLng(rst!KategorieID) _\r\n & \", 0);\" & vbCrLf<\/span>\r\n rstBeitraege.MoveNext<\/span>\r\n Loop<\/span>\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\n KategorienArtikel = strSQLDelete & strSQLINSERT\r\nEnd Function<\/span><\/pre>\n![\"Kategorien-Tabelle](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_005.png\")
<\/p>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_006.png\")
<\/p>\nDELETE FROM wp_terms WHERE term_id = 88000025;<\/pre>\n
DELETE FROM wp_term_taxonomy WHERE term_id = 88000025;<\/pre>\n
INSERT INTO wp_terms(term_id, name, slug, term_group) VALUES(88000025, 'VBA und Programmiertechniken', 'VBA_und_Programmiertechniken', 0);\r\nINSERT INTO wp_term_taxonomy(term_taxonomy_id, term_id, taxonomy, description, parent, count) VALUES(88000025, 88000025, 'category', '', 0, 0);<\/pre>\n
DELETE FROM wp_term_relationships WHERE object_id = 55000001 AND term_taxonomy_id = 88000025;<\/pre>\n
INSERT INTO wp_term_relationships(object_id, term_taxonomy_id, term_order) VALUES(55000001, 88000025, 0);<\/pre>\n
![\"Kategorien](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_007.png\")
<\/p>\nPublic Function <\/span>KategorienAusgaben(strWhere As String<\/span>) As String<\/span>\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>rstAusgaben As <\/span>DAO.Recordset, rstBeitraege As <\/span>DAO.Recordset\r\n Dim <\/span>strSQLDelete As String<\/span>, strSQLInsert As String<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT DISTINCT Jahr FROM tblBeitraege WHERE \" & strWhere _\r\n & \" AND NOT Jahr = 0 ORDER BY Jahr DESC\", dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rst.EOF\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_terms WHERE term_id = \" & 990000 + rst!Jahr & \";\" & vbCrLf<\/span>\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_term_taxonomy WHERE term_taxonomy_id = \" & 990000 + rst!Jahr _\r\n & \";\" & vbCrLf<\/span>\r\n strSQLInsert = strSQLInsert & \"INSERT INTO wp_terms(term_id, name, slug, term_group) VALUES(\" & 990000 _\r\n + rst!Jahr & \", '\" & rst!Jahr & \"', '\" & rst!Jahr & \"', 0);\" & vbCrLf<\/span>\r\n strSQLInsert = strSQLInsert & \"INSERT INTO wp_term_taxonomy(term_taxonomy_id, term_id, taxonomy, \" _\r\n & \"description, parent, count) VALUES(\" & 990000 + rst!Jahr & \", \" & 990000 + rst!Jahr _\r\n & \", 'category', '', 0, 0);\" & vbCrLf<\/span>\r\n Set<\/span> rstAusgaben = db.OpenRecordset(\"SELECT DISTINCT Ausgabe FROM tblBeitraege WHERE \" & strWhere _\r\n & \" AND Jahr = \" & rst!Jahr & \" ORDER BY Ausgabe ASC\", dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rstAusgaben.EOF\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_terms WHERE term_id = \" & 99000000 _\r\n + CLng(rstAusgaben!Ausgabe & rst!Jahr) & \";\" & vbCrLf<\/span>\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_term_taxonomy WHERE term_taxonomy_id = \" & 99000000 _\r\n + CLng(rstAusgaben!Ausgabe & rst!Jahr) & \";\" & vbCrLf<\/span>\r\n strSQLInsert = strSQLInsert & \"INSERT INTO wp_terms(term_id, name, slug, term_group) VALUES(\" & 99000000 _\r\n + Lng(rstAusgaben!Ausgabe & rst!Jahr) & \", '\" & rstAusgaben!Ausgabe & \"\/\" & rst!Jahr & \"', '\" _\r\n & rstAusgaben!Ausgabe & \"\/\" & rst!Jahr & \"', 0);\" & vbCrLf<\/span>\r\n strSQLInsert = strSQLInsert & \"INSERT INTO wp_term_taxonomy(term_taxonomy_id, term_id, taxonomy, \" _\r\n & \"description, parent, count) VALUES(\" & 99000000 + CLng(rstAusgaben!Ausgabe & rst!Jahr) & \", \" _\r\n & 99000000 + CLng(rstAusgaben!Ausgabe & rst!Jahr) & \", 'category', '', \" & 990000 + rst!Jahr _\r\n & \", 0);\" & vbCrLf<\/span>\r\n Set<\/span> rstBeitraege = db.OpenRecordset(\"SELECT * FROM tblBeitraege WHERE \" & strWhere & \" AND Jahr = \" _\r\n & rst!Jahr & \" AND Ausgabe = \" & rstAusgaben!Ausgabe, dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rstBeitraege.EOF\r\n strSQLDelete = strSQLDelete & \"DELETE FROM wp_term_relationships WHERE object_id = \" & 55000000 _\r\n + rstBeitraege!BeitragID & \" AND term_taxonomy_id = \" & 99000000 + CLng(rstAusgaben!Ausgabe _\r\n & rst!Jahr) & \";\" & vbCrLf<\/span>\r\n strSQLInsert = strSQLInsert & \"INSERT INTO wp_term_relationships(object_id, term_taxonomy_id, \" _\r\n & \"term_order) VALUES(\" & 55000000 + rstBeitraege!BeitragID & \", \" & 99000000 _\r\n + CLng(rstAusgaben!Ausgabe & rst!Jahr) & \", 0);\" & vbCrLf<\/span>\r\n rstBeitraege.MoveNext<\/span>\r\n Loop<\/span>\r\n rstAusgaben.MoveNext<\/span>\r\n Loop<\/span>\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\n KategorienAusgaben = strSQLDelete & strSQLInsert\r\nEnd Function<\/span><\/pre>\nDELETE FROM wp_terms WHERE term_id = 992000;\r\nDELETE FROM wp_term_taxonomy WHERE term_taxonomy_id = 992000;<\/pre>\n
INSERT INTO wp_terms(term_id, name, slug, term_group) VALUES(992000, '2000', '2000', 0);\r\nINSERT INTO wp_term_taxonomy(term_taxonomy_id, term_id, taxonomy, description, parent, count) VALUES(992000, 992000, 'category', '', 0, 0);<\/pre>\n
DELETE FROM wp_terms WHERE term_id = 99012000;\r\nDELETE FROM wp_term_taxonomy WHERE term_taxonomy_id = 99012000;<\/pre>\n
INSERT INTO wp_terms(term_id, name, slug, term_group) VALUES(99012000, '1\/2000', '1\/2000', 0);\r\nINSERT INTO wp_term_taxonomy(term_taxonomy_id, term_id, taxonomy, description, parent, count) VALUES(99012000, 99012000, 'category', '', 992000, 0);<\/pre>\n
DELETE FROM wp_term_relationships WHERE object_id = 55000001 AND term_taxonomy_id = 99012000;<\/pre>\n
INSERT INTO wp_term_relationships(object_id, term_taxonomy_id, term_order) VALUES(55000001, 99012000, 0);<\/pre>\n
![\"Verwalten](\"..\/fileadmin\/_temp_\/2019_06\/pic_1215_008.png\")
<\/p>\nDownloads zu diesem Beitrag<\/h3>\n