Warning bei der Ausgabe von Datensätze

[gottlieb]

Hallo Forum,
habe mir soeben eine Query zusammengebastelt und hätte Fragen dazu.

1. Die Query funktioniert, ich erhalte die benötigten Datensätze, es fehlen aber bei der Auflistung der Datensätze die Zeilennummern. Hinzu komtm noch folgende Meldung:
Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 65 in C:\Server\xampp\phpMyAdmin\libraries\display_tbl.lib.php on line 756

2. Die Query hat 3 Selects. Sieht das ganze grob Perfomancelastig aus?

  
SELECT  
 DATE_FORMAT(A.date, '%d.%m.%Y'), --- Hole das Datum von einem Blogeintrag  
 DATE_FORMAT(A.date,'%k.%i'),  
 A.blogeintrag,  
 A.thema,  
 A.blogingid,  
 A.blogerid,  
 B.mitglidsname, --- Und weitere Daten von einem Blogeintrag  
 count(C.blogingid), --- Hole die Anzahl der vorhandenen Kommentare von C zu den jeweiligen Blogeinträgen  
 (SELECT count(*) FROM Blogeintraege AS A INNER JOIN Mitglieder AS B ON A.blogerid=B.mitgliedsid WHERE B.Bedingung=1 AND B.priatvsphaere&1<<5!=32) AS Bloggers --- Hole die Anzahl der Blogeinträge, die von den Mitgliedern für alle Lesbar sind. Wenn das 5'te Bit nicht gesetzt ist, ist es dementsprechend Öffentlich.  
  
  
 FROM (Blogeintraege AS A INNER JOIN Mitglieder AS B ON A.blogerid=B.mitgliedsid)  
  
 LEFT JOIN Blogkommentare AS C ON A.blogingid=C.blogingid  
  
 WHERE (B.priatvsphaere&1<<5!=32 OR (B.priatvsphaere&1<<4!=16 AND B.priatvsphaere&1<<5=32 AND (SELECT count(*) FROM MeineBudies AS D WHERE A.blogerid=D.meineid AND D.freundid=12345)=1) ) AND B.Bedingung=1 --- Jetzt holt er alle Blogeinträge die öffentlich geschaltet sind oder er holt die Blogeinträge die vom Mitglied nur für Freunde freigeschalter worden sind. Sprich, wenn das 4'te Bit nicht gesetzt ist und das 5'te Bit gesetzt ist und ich zugeleich auch der Freund bin. Count von Freunde = 1.  
  
 GROUP BY A.blogingid ORDER BY A.date DESC LIMIT 50;  

Ilja, ich weiß, ich gewöhne mit das "AS" noch ab :-)

DBMS mySQL > 5.0.x

[Gonzo]

Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 65 in C:\Server\xampp\phpMyAdmin\libraries\display_tbl.lib.php on line 756

Und wo finden wir jetzt Zeile 756 bzw. das dort befindliche fehlerhafte Muster?

[gottlieb]

Hi,

Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 65 in C:\Server\xampp\phpMyAdmin\libraries\display_tbl.lib.php on line 756

Und wo finden wir jetzt Zeile 756 bzw. das dort befindliche fehlerhafte Muster?

Asoo, ich dachte, mit meiner Query stimmt etwas nicht, welches den Fehler auslöst.

Ab Zeile 755 sieht es in display_tbl.lib.php so aus:

  
  
            if (($is_join  
                && !preg_match('~([^[:space:],]|`[^`]`)[[:space:]]+(as[[:space:]]+)?' . $fields_meta[$i]->name . '~i', $select_expr, $parts = array()))  
               || ( isset($analyzed_sql[0]['select_expr'][$i]['expr'])  
                   && isset($analyzed_sql[0]['select_expr'][$i]['column'])  
                   && $analyzed_sql[0]['select_expr'][$i]['expr'] !=  
                   $analyzed_sql[0]['select_expr'][$i]['column']  
                  && !empty($fields_meta[$i]->table)) ) {  
                $sort_tbl = PMA_backquote($fields_meta[$i]->table) . ' . ';  
            } else {  
                $sort_tbl = '';  
            }  

[MudGuard]

Hi,

preg_match('~([^[1],]|[^]`)[[:space:]]+(as[[:space:]]+)?' . $fields_meta[$i]->name . '~i', $select_expr, $parts = array()))

Das erste ~ sagt, daß Dein Regex zwischen 2 ~ steht. Es gibt aber nur eine Tilde.

cu,
Andreas

---

1. :space: ↩︎

[gottlieb]

Nabend,

preg_match('~([^[1],]|[^]`)[[:space:]]+(as[[:space:]]+)?' . $fields_meta[$i]->name . '~i', $select_expr, $parts = array()))

Das erste ~ sagt, daß Dein Regex zwischen 2 ~ steht. Es gibt aber nur eine Tilde.

Ohje, leider verstehe ich da jetzt Null. Kann ich die Query sorglos mit dem Warning weiternutzen oder muss ich bestimmte Dateien (PHP) von phpmyadmin umschreiben, anpassen?

Schuldigung, wenn ich gerade so verplant bin. Nimmt mir hoffentlich niemand übel.

Grüße

---

1. :space: ↩︎

[Gonzo]

'~([^[1],]|[^]`)[[:space:]]+(as[[:space:]]+)?' . $fields_meta[$i]->name . '~i'

Ohje, leider verstehe ich da jetzt Null. Kann ich die Query sorglos mit dem Warning weiternutzen

Dein Problem ist nicht die Abfrage der Datenbank, sondern die Erstellung des SQL-Befehls, denn für letzteres dient offenbar obiges Muster. Und solange dieses Muster nicht fehlerfrei funktioniert, wirst du irgendwann irgendwo über (scheinbar) fehlerhafte Ergebnisse aus der Datenbank stolpern.

Das von PHP bemängelte Byte 65 steckt wohl, wie schon MudGard vermutet hat, in  der Variablen $fields_meta[$i]->name. Ihren Inhalt bekommst du vermutlich am einfachsten, indem du vor Zeile 755, also direkt vor der if-Abfrage, in der das fehlerhafte Muster Verwendung findet, die beiden Befehle

var_dump($i);
var_dump($fields_meta[$i]->name);

einbaust, die Seite aufrufst und dann einen Blick in den HTML-Quellcode wirfst, den der Browser empfangen hat. Dort muss irgendwo die Ausgabe von var_dump() auftauchen und in irgendeiner steckt vermutlich der PCRE-Fehler.

---

1. :space: ↩︎

[gottlieb]

Hi,

Dein Problem ist nicht die Abfrage der Datenbank, sondern die Erstellung des SQL-Befehls, denn für letzteres dient offenbar obiges Muster. Und solange dieses Muster nicht fehlerfrei funktioniert, wirst du irgendwann irgendwo über (scheinbar) fehlerhafte Ergebnisse aus der Datenbank stolpern.

Aso, geht klar. Wenn der Fehler aber nur phpmyAdmin betrifft, wäre das nicht so tragisch. Auf dem Server habe ich eine andere Version drauf. Und phpmyAdmin dient eigentlich nur, um ab und zu mal so Querys zu testen.

Das von PHP bemängelte Byte 65 steckt wohl, wie schon MudGard vermutet hat, in  der Variablen $fields_meta[$i]->name. Ihren Inhalt bekommst du vermutlich am einfachsten, indem du vor Zeile 755, also direkt vor der if-Abfrage, in der das fehlerhafte Muster Verwendung findet, die beiden Befehle

var_dump($i);
var_dump($fields_meta[$i]->name);

einbaust, die Seite aufrufst und dann einen Blick in den HTML-Quellcode wirfst, den der Browser empfangen hat. Dort muss irgendwo die Ausgabe von var_dump() auftauchen und in irgendeiner steckt vermutlich der PCRE-Fehler.

Danke für den Tipp, da ich mich mit PHP garnicht auskenne. Ich schaue mir das an :-)

Grüße

[MudGuard]

Hi,

preg_match('~([^[1],]|[^]`)[[:space:]]+(as[[:space:]]+)?' . $fields_meta[$i]->name . '~i', $select_expr, $parts = array()))
Das erste ~ sagt, daß Dein Regex zwischen 2 ~ steht. Es gibt aber nur eine Tilde.

Ups, ich zieh alles zurück, die zweite ~ ist ja vorhanden.

Der Fehler dürfte also in $fields_meta[$i] liegen. Welchen Wert hat dieses? Vermutlich ist ein ? oder + oder * oder {x,y} enthalten.

cu,
Andreas

---

1. :space: ↩︎

[Sven Rautenberg]

Moin!

habe mir soeben eine Query zusammengebastelt und hätte Fragen dazu.

Ich auch.

2. Die Query hat 3 Selects. Sieht das ganze grob Perfomancelastig aus?

Das erzählt dir ein EXPLAIN vor dem Query.

Ansonsten meine Fragen zu deinem Code:

1. Warum baust du Tippfehler in die Spaltenbezeichner ein? Das macht die Codepflege extrem aufwendig, weil man normalerweise einen menschenverständlichen Begriff eben nicht falsch tippt - damit aber logischerweise den Query zerstört.

Damit meine ich die Spalten
blogingid -> blogging_id
blogerid  -> blogger_id
mitglidsname -> mitgliedsname
priatvsphaere -> privatsphaere

2. Deine Alias-Bezeichner für die einzelnen Tabellen mit A und B zu wählen halte ich ebenfalls für ungünstig. Nimm doch einfach einen sprechenderen Kurzbezeichner, zum Beispiel den ersten Buchstaben der Tabelle. Dann kommt es nämlich nicht zu der Kuriosität, dass die Tabelle "Blogeinträge" mit A und "Mitglieder" mit B abgekürzt wird (und in anderen Querys auch mal anders herum), sondern "Blogeinträge" ist immer "B", und "Mitglieder" ist immer "M" - in jedem Query.

3. Dein Feld "privatsphaere" hat ganz offensichtlich den falschen Typ. Du benutzt manuelle Bitschiebereien und Maskierungen, um dort in einem Bitfeld diverse Berechtigungsschemata zu speichern. Aber für genau diese Anwendungen gibt es die wunderbare Erfindung von "SET" - die den unschätzbaren Vorteil hat, dass man zum einen nicht kompliziert mit Shiften und Bitmaskierung sehr fehleranfällig die korrekten Bits setzen muß, sondern im Klartext mit sprechenden Bezeichnern arbeiten kann, und mit sinnvollen, logischen Operationen.

- Sven Rautenberg

[gottlieb]

Hi,

2. Die Query hat 3 Selects. Sieht das ganze grob Perfomancelastig aus?

Das erzählt dir ein EXPLAIN vor dem Query.

Aha, ok.

Ansonsten meine Fragen zu deinem Code:

1. Warum baust du Tippfehler in die Spaltenbezeichner ein? Das macht die Codepflege extrem aufwendig, weil man normalerweise einen menschenverständlichen Begriff eben nicht falsch tippt - damit aber logischerweise den Query zerstört.

Damit meine ich die Spalten
blogingid -> blogging_id
blogerid  -> blogger_id
mitglidsname -> mitgliedsname
priatvsphaere -> privatsphaere

Oh sorry, real habe ich da natürlich keine Fehler drin. Ich ändere nur schnell die Query, damit ich nicht die orig. Query mit den orig. Tabellen- und Spaltenname öffentlich poste. ICh bemühe mich das nächste Mal die Query leserlicher zu posten :-) Nochmals sorry.

2. Deine Alias-Bezeichner für die einzelnen Tabellen mit A und B zu wählen halte ich ebenfalls für ungünstig. Nimm doch einfach einen sprechenderen Kurzbezeichner, zum Beispiel den ersten Buchstaben der Tabelle. Dann kommt es nämlich nicht zu der Kuriosität, dass die Tabelle "Blogeinträge" mit A und "Mitglieder" mit B abgekürzt wird (und in anderen Querys auch mal anders herum), sondern "Blogeinträge" ist immer "B", und "Mitglieder" ist immer "M" - in jedem Query.

Ist eine blöde Angewohnheit von mir. Ab heute gewöhne ich mir auch eine günstigere Kurzbezeichnung an :-)

3. Dein Feld "privatsphaere" hat ganz offensichtlich den falschen Typ. Du benutzt manuelle Bitschiebereien und Maskierungen, um dort in einem Bitfeld diverse Berechtigungsschemata zu speichern. Aber für genau diese Anwendungen gibt es die wunderbare Erfindung von "SET" - die den unschätzbaren Vorteil hat, dass man zum einen nicht kompliziert mit Shiften und Bitmaskierung sehr fehleranfällig die korrekten Bits setzen muß, sondern im Klartext mit sprechenden Bezeichnern arbeiten kann, und mit sinnvollen, logischen Operationen.

SET? Ich sätze in der Query ja kein Bit, sondern lese ein bestimmtes Bit aus oder habe ich gerade etwas falsch verstanden?

Grüße

[Sven Rautenberg]

Moin!

SET? Ich sätze in der Query ja kein Bit, sondern lese ein bestimmtes Bit aus oder habe ich gerade etwas falsch verstanden?

Datentyp SET. Genau wie ENUM, nur anders.

- Sven Rautenberg

[gottlieb]

Nabend,

SET? Ich sätze in der Query ja kein Bit, sondern lese ein bestimmtes Bit aus oder habe ich gerade etwas falsch verstanden?

Datentyp SET. Genau wie ENUM, nur anders.

Hab einfach die Doku durchgelesen.
http://dev.mysql.com/doc/refman/5.1/de/set.html

Sieht schon interessant aus und dürfte eventuell vorteilhafter sein, anstatt so wie ich das bisher mache.

[Sven Rautenberg]

Moin!

Datentyp SET. Genau wie ENUM, nur anders.

Hab einfach die Doku durchgelesen.
http://dev.mysql.com/doc/refman/5.1/de/set.html

Sieht schon interessant aus und dürfte eventuell vorteilhafter sein, anstatt so wie ich das bisher mache.

Alternativ dürfte sich vermutlich als deutlich handhabbarer erweisen, wenn man die einzelnen Bits in separaten ENUM-Feldern speichert.

- Sven Rautenberg