Kunden Suche Reiter Kunde/Bestellungen keine Funktion nach Update

[marco1004]

Hallo,
nach den Update habe ich folgendes Problem.
Wenn ich auf den Reiten Kunden und dann Bestellung gehe und dort ein Name eingebe kommt nichts.
Habe es gerade auch im Demo Shop probiert mit den Namen Müller da der Name ja unter Kunden angemeldet ist.
Aber auch dort findet er nichts.
Habe noch ein Shop ohne update und wenn ich dort ein Kunden Namen eingebe kommt der Kunde.
Vielleicht habt ihr ja eine Lösung.
Gruß
Marc

Linkback: https://www.modified-shop.org/forum/index.php?topic=39173.0

[Tomcraft]

Hattest du deinen Ordner "/admin/" im alten Shop umbenannt? Dann musst du den Ordner auch im Update-Paket umbenennen bevor du die Dateien auf den FTP-Server hoch lädst.

Ansonsten kann ich dazu nicht sehr viel mehr sagen, da wir bereits mehrere erfolgreiche Updates auf die Version 2.0.4.0 rev 11214 durchgeführt haben.

Grüße

Torsten

[marco1004]

Nein habe ich nicht.
Im Demo Shop findet er auch nichts wenn man einen Name einträgt bei Kunden.

[marco1004]

Hat kein anderer das Problem?

Im Demo Shop geht es doch auch nicht.

[Timm]

Bei mir gehts auch nicht seit 2.0.4.0. Hatte das aber noch nie genutzt.

In dieser Adminsuchleiste funktioniert es

[ Für Gäste sind keine Dateianhänge sichtbar ]

In den Bestellungen selbst  (admin/orders.php) kommt immer ein leeres Ergebnis, wenn man bei Kunde was einträgt.

[ Für Gäste sind keine Dateianhänge sichtbar ]

Hab dafür Ticket #1469 angelegt.

Gruß Timm

[Modulfux]

Ich habe in Ticket #1469 die Lösung gepostet.

[Timm]

Danke für die schnelle Hilfe @modulfux

Mit

Code: PHP  [Auswählen]

(o.orders_status = '".(int)$status."'

soll doch bestimmt irgendwas erzielt werden? 

Ist da nicht einfach eine schließende Klammer zu wenig? Bzw falsch gesetzt?

Ich hab die mal eine Zeile hoch gesetzt und es funktioniert.

Code: PHP  [Auswählen]

$orders_query_raw = "-- /admin/orders.php
                                       SELECT ".$order_select_fields."
                                         FROM ".TABLE_ORDERS." o
                                        WHERE (o.orders_status = '".(int)$status."'
                                          AND o.customers_name LIKE '%".xtc_db_input($customer)."%'
                                           OR o.customers_firstname LIKE '%".xtc_db_input($customer)."%'
                                           OR o.customers_lastname LIKE '%".xtc_db_input($customer)."%'
                                           OR o.customers_company LIKE '%".xtc_db_input($customer)."%')                      
                                              ".$filter.$sort;

Hab mir das jetzt aber nur abgeschaut durch den Vergleich der Datei von 2.0.3.0 und 2.0.4.0, wo die Klammer auch meißt hinter der WHERE Klausel stand. Und vermute mal, dass

Code: PHP  [Auswählen]

(o.orders_status = '".(int)$status."'
                                          AND o.customers_name LIKE '%".xtc_db_input($customer)."%'

zusammengehört und die Klammer in der zweiten Zeile ein Copy und Paste Fehler ist aus der Zeile 148 der 2.0.3.0 Version ist, wo stand

Code: PHP  [Auswählen]

                                            WHERE (o.customers_name LIKE '%".xtc_db_input($customer)."%'
 

Aber ohne das ganze zu verstehen.

Gruß Timm

[noRiddle (revilonetz)]

Das einzige was (wahrscheinlich durch copy & paste entstanden) verkehrt ist diese Zeile

Code: PHP  [Auswählen]

WHERE (o.orders_status = '".(int)$status."'

wie modulfux auch im Ticket korrekt erklärt hat.
Natürlich muß in der Zeile darunter aus dem AND ein WHERE gemacht werden wenn die Zeile entfernt wird.

Ich hatte es nämlich auch eben gefunden...

Gruß,
noRiddle

[Modulfux]

Ja, aber es bringt nichts, weil o.orders_status = '0' ist und das Query nur durch geht, weil die customers_xxx zutreffen.

[Timm]

In 2.0.4.0 wurde das ja geändert, weil der Status in 2.0.3.0 nicht angezeigt wird. Das funktioniert mit beiden Varianten und es gibt auch ein Ergebnis im Gegensatz zur 2.0.4.0 Lösung. Aber ihr werdet Recht haben. Ich habs nur durch Versuch gelöst und die Zeile wird quasi übersprungen und es gelten die OR`s, wie Modulfux sagt.

Mal ne andere Frage: Hat es eigentlich irgendwann mal funktioniert, dass man einen Namen eingegeben hat und danach noch den Status verändern konnte bzw andersherum? Quasi-Hat Herr Müller unter seinen vielen Bestellungen noch eine offene, die ich übersehen hab?

Zur Zeit kann man ja nur einen der beiden Filter nutzen. Entweder den Kundennamen oder den Status zb.

Die Filterfunktionen der Produkteigenschaften lassen aber auch mehrere Filter zu.

Mich persönlich betrifft es jetzt nicht, aber ein größerer Shop könnte das sicher interessant finden.

Gruß Timm

[Modulfux]

[...]
Mal ne andere Frage: Hat es eigentlich irgendwann mal funktioniert, dass man einen Namen eingegeben hat und danach noch den Status verändern konnte bzw andersherum? [...]

Nein, das hat noch nie funktioniert, weil dafür nicht gleichzeitig die passenden Parameter übergeben werden.

[noRiddle (revilonetz)]

Ja, aber es bringt nichts, weil o.orders_status = '0' ist und das Query nur durch geht, weil die customers_xxx zutreffen.

Die Query geht nicht nur durch "weil die customers_xxx zutreffen".
Die Query geht durch weil sie eine valide Query ist, nur findet sie natürlich nichts.

Allerdings sollte man sich generell abgewöhnen einen String (hier '0') mit einem INT-Feld in der DB zu vergleichen, was das DBMS dazu bewegt den String '0' in einen Interger zu casten (= 0) und dann zu suchen.
Das kann zu Bugs führen die nicht so leicht aufzufinden sind (wie ich z.B. in diesem Ticket zu erklären versucht habe, wo ein leerer String mit einem INT 0 in der DB verglichen wird, was 'true' ergibt).
Außerdem kann es dazu führen, daß vorhandene Indizes auf solchen Feldern nicht benutzt werden und diese somit ad absurdum geführt werden, was wiederum Queries langsamer macht.

Gruß,
noRiddle

[Modulfux]

[...]
Allerdings sollte man sich generell abgewöhnen einen String (hier '0') mit einem INT-Feld in der DB zu vergleichen, was das DBMS dazu bewegt den String '0' in einen Interger zu casten (= 0) und dann zu suchen.
[...]

Dann müssen aber 95% der Queries im Shopsystem überarbeitet werden.

[noRiddle (revilonetz)]

Jau, das ist wahr.
Vor Allem solche Dinge sind witzig:

Code: PHP  [Auswählen]

AND pd.language_id='".(int) $_SESSION['languages_id']."'

Auf Int casten und noch einen String daraus machen. (Ich weiß der Cast hat auch Schutzfunktionen gegen mySQL-Injection.)
Ich denke, daß solche Queries auch geringfügig langsamer sein dürften als die korrekteste Form, weil das DBMS eben den String erst zum Integer casten wird.

Nun, meine Behauptung mit dem Index ist glaube ich nicht zutreffend wenn man einen String mit einem INT-Field in der DB vergleicht.
Umgekehrt, also einen Integer mit einem String-Field in der DB vergleichen, dürfte allerdings dazu führen, daß ein gesetzter Index ignoriert wird. Solch eine Query dürfte aber eher nicht vorkommen.

Jedenfalls sind Bugs wie der von mir erwähnte eher vermeidbar wenn man sich angewöhnt nicht Strings mit INT-Feldern in der DB zu vergleichen.

Gruß,
noRiddle

[marco1004]

Danke für die Lösung meines Problemes