nicht angemeldet
Hallo!
Das ist schon kaputt und jemand hat es durch die Gruppierung zu reparieren versucht.
"Gut" :/ Ok, dann versuche ich die Query mal zu reparieren.
Wenn [..]
Das heißt also [..] Die Gruppierung sollte weg und stattdessen die äußere Query um die Bedingung "ANDcms\_menu\_pages.menu\_id=?" erweitert werden.
Ok, habe ich erledigt.
Damit ändern sich die Lösungsmöglichkeiten erheblich. Wenn das jetzige SELECT-Statement (abgesehen von den Fehlerkorrekturen) unverändert bleiben soll, bringt es hier nichts, es nur in eine Stored Procedure zu kapseln. Eine SP kann aber trotzdem helfen. Das SELECT-Statement muss sein Ergebnis in einer temporären Tabelle ablegen und die kann man dann in einem weiteren SELECT-Statement selfjoinen (alles innerhalb der SP).
Eine andere Idee ist, das jetzige verschachtelte SELECT zumindest soweit zu entschachteln (und einfache JOINS draus zu machen), dass die Parameter als Bedingungen des außeren Statements formuliert werden können. Dann kann man das Statement (abzüglich der Bedingungen) in einer View ablegen, und die lässt sich dann syntaktisch gesehen relativ einfach selfjoinen.
Tut mir leid, dass ich nicht wirklich Ahnung von der Materie habe. Ich kann hier eigentlich nur deinem Rat folgen. Das Problem ist halt, dass ich frei definierte Menüs habe die völlig unabhängig von der eigentlichen Seitenstruktur sind. Trotzdem soll das Menü nur die Seiten anzeigen für deren Betrachtung ein bestimmter Benutzer auch die jeweiligen Rechte hat.
Wie wäre der Ansatz, dass ich doch wieder das Array betrachte und solche Menüs einfach nur "flach" zur Verfügung stelle? Oder meinst du, dass es den Aufwand Wert ist? Vielleicht ist das ja auch einfach überhaupt nicht möglich aus Waisen eine Baumstruktur zu rekonstruieren?