Suchen&Ersetzen mit phyMyAdmin

RalfJ

Benutzer
Beiträge
6
Hallo,
ich habe ein Problem mit dem Suchen und Ersetzen mittels phpMyAdmin einer Maria-Datenbank , die mit WordPress genutzt wird, und bitte um Hilfe.
Folgende SQL-Abfrage klappt wunderbar und ich bekomme alle entsprechende Datensätze angezeigt:
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '%[[1]]\r%' ORDER BY `ID` ASC
Was nicht klappt, das ist das Übertragen in eine über den Reiter "Suche" gestartete Abfrage (als Voraussetzung zum Ersetzen). Dort gebe ich in der Spalkte "wp_content" mit dem Operator "LIKE" den Wert "[[1]]\r" (ohne Anführungszeichen) ein.
Das Resultat sind 0 Datensätze und phpMyAdmin meldet als Abfrageterm:
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '[[1]]\\r' ORDER BY `ID` ASC
Die Verdoppelung des Backslashes scheint OK zu sein, um ein Escape zu verhindern, scheint also nicht der Grund zu sein.
Auch wenn ich als Operator "LIKE %...%" wähle, sind das Ergebnis 0 Datensätze.
Was mache ich falsch?
Vielen Dank für eure Hilfe
 
Werbung:
Die Frage ist, wie die Zeichenkette aussieht, die du suchst, und die einen Treffer liefern sollte.
  • Die %-Zeichen machen i.d.R. schon Sinn, sonst darf nichts davor bzw. dahinter stehen.
  • Wenn \ mit \\ escaped wird, dann kann LIKE 'r\r' nicht das gleiche liefern wie LIKE 'r\\r'. Als Vergleich in MSSQL LIKE wird allerdings \ nicht escaped.
  • [Ziffer] hat unter Umständen auch eine Bedeutung. [0-9] wäre z.B. eine Ziffer zwischen 0 und 9.
 
Hallo Ukulele,
danke für deine Antwort. Den zweiten Punkt verstehe ich allerdings nicht, weiß auch nicht, ob mir das helfen würde, denn ich möchte ja nichts vergleichen.
Noch mal:
Ich habe einen Term [[1]], der am Ende einer Zeile steht, wobei der Zeilenumbruch offenbar von WP mit \r erzeugt wurde.
Die Suche mittels des Reiters SQL führt bei diesem Ausdruck
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '%[[1]]\r%' ORDER BY `ID` ASC
zu 3065 gefundenen Datensätzen.
Da ich mit der SQL-Abfrage nur suchen kann, ich den Ausdruck [[1]] aber ändern will, muss ich ihn in den Reiter Suchen&Ersetzen bekommen. Wenn ich in post_content mit dem Operator LIKE %...% als Wert [[1]]\r eingebe, werden jedoch 0 Datensätze gefunden und phpMyAdmin zeigt dann an, er habe gesucht nach
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '%[[1]]\\r%'
Der zweite Backslash wird dabei von phpMyAdmin gesetzt - nach dem was ich ergoogelt habe, um ein Escape zu verhindern. Das ist ja auch gut und schön, nur wird dann trotzdem kein einziger Datensatz gefunden.
MaW: Der Ausdruck [[1]]\r scheint irgendwie im Reiter Suchen&Ersetzen anders eingegeben zu werden müssen als im Reiter SQL.
Nur wie???
 
Zu phpMyAdmin kann ich leider nichts sagen, da ich das nicht verwende. Klingt nach einem sonderbaren Verhalten, vielleicht gewollt vielleicht nicht.

Du kannst Suchen und Ersetzen ja auch selbst mit SQL durchführen, z.B.
Code:
UPDATE `wp_posts` SET `post_content` = replace(`post_content`,'[[1]]\r','[[2]]\r') WHERE `post_content` LIKE '%[[1]]\r%'
Damit sollte sich das Verhalten umgehen lassen.
 
[0-9] repräsentiert eine Ziffer zwischen 0 und 9, das müsste auch mit replace() gehen. Du könntest mit zwei Befehlen den ganzen Bereich abdecken.

replace(`post_content`,'[1-9]\r','<Platzhalter>') müsste 1-9 machen, replace(`post_content`,'[[1-7][0-9]\r','<Platzhalter>') den Rest.
 
Okay das ist schade, kann aber sein. Was geht und was nicht hängt vom verwendeten DMBS, von der Version und auch von der Funktion ab. Für MySQL finde ich nur % und _ (für ein beliebiges, numerisches oder nicht numerisches Zeichen). Damit kommst du nicht weit.

Jetzt kann man sich natürlich was bauen, das wird aber nicht einfacher sein als 100 Updates ;-) Mach dir eine Excel-Formel für das Statement mit Bezug auf eine Zahl in einer eigenen Spalte. Ziehe Zahl und Formel nach unten. Kopiere alle Formeln aund erhalte alle Statepents.
 
Werbung:
So gemacht, und es hat alles bestens geklappt. Vielen Dank ;-) !
Das Einzige etwas Störende war, dass phpMyAdmin zwar brav 1641 Fußnoten in 497 Datensätzen in einem Rutsch geändert hat, dies aber mit "MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze)" quittierte. Da kam dann erstmal Panik auf ... Aber: Ende gut, alles gut
 
Zurück
Oben