SQL query: alle Beträge falsch um Faktor 1 Mio.

[Dp.]

Ich spiele gerade mit den SQL queries um und habe dabei einen komischen Effekt. Alle Beträge sind hierbei beim Export um den Faktor 1 Million skaliert.

Ich nutze zB das Standard SQL query aus dem Bereich "Bestellungen":

	SELECT SQL_CALC_FOUND_ROWS a.`id_order`, `reference`, `total_paid_tax_incl`, `payment`, a.`date_add` AS `date_add` , a.id_currency, a.id_order AS id_pdf, CONCAT(LEFT(c.`firstname`, 1), '. ', c.`lastname`) AS `customer`, osl.`name` AS `osname`, os.`color`, IF((SELECT so.id_order FROM `ps_orders` so WHERE so.id_customer = a.id_customer AND so.id_order < a.id_order LIMIT 1) > 0, 0, 1) as new, country_lang.name as cname, IF(a.valid, 1, 0) badge_success, shop.name as shop_name FROM `ps_orders` a LEFT JOIN `ps_customer` c ON (c.`id_customer` = a.`id_customer`) INNER JOIN `ps_address` address ON address.id_address = a.id_address_delivery INNER JOIN `ps_country` country ON address.id_country = country.id_country INNER JOIN `ps_country_lang` country_lang ON (country.`id_country` = country_lang.`id_country` AND country_lang.`id_lang` = 1) LEFT JOIN `ps_order_state` os ON (os.`id_order_state` = a.`current_state`) LEFT JOIN `ps_order_state_lang` osl ON (os.`id_order_state` = osl.`id_order_state` AND osl.`id_lang` = 1) LEFT JOIN `ps_shop` shop ON a.`id_shop` = shop.`id_shop` WHERE 1 AND a.id_shop IN (1) ORDER BY a.id_order DESC

Wenn ich das im Backend anzeigen lasse, sieht es gut aus:

 

Beim CSV-Download dann nicht mehr:

 

Ich habe hierzu nichts finden können. Ist jemandem dieses Phänomen (inkl. Lösung 😉 ) bekannt?

[Wuschel]

Das "Phänomen" ist eigentlich jedem bekannt, der weiß,  dass im angelsächsischen Sprachraum Dezimalpunkt und Dezimalkomma genau umgekehrt wie in Deutschland verwendet werden: das Komma trennt die Tausender, der Punkt die Nachkommastellen ab.

Bei den Dezimalzahl musst du daher in die SQL-Abfrage einen REPLACE-Befehl einfügen, der Punkt gegen Komma austauscht.

[Dp.]

Danke dir. Bei einem Faktor 1.000 hätte ich das auch direkt vermutet, aber 1.000.000 ist ja auch bei dieser Thematik wenig ersichtlich. Hier werden ja aus 4,90€ Porto auf einmal 4,9 Millionen €...

 

Jetzt habe ich `total_paid_tax_incl` ersetzt durch:

replace(replace(replace(convert(varchar(30), `total_paid_tax_incl`, 1), ',', '|'), '.', ','), '|', '.')

, ersetzen durch | -> . ersetzen durch , -> | ersetzen durch .

Dann wird das query nicht erfolgreich ausgeführt mir fehlen die Fähigkeiten zum Debuggen 😄 Könnte mir das jemand mit höheren Kenntnissen schnell zusammenbraten?

[Wuschel]

1 hour ago, Dp. said:

Jetzt habe ich `total_paid_tax_incl` ersetzt durch:

replace(replace(replace(convert(varchar(30), `total_paid_tax_incl`, 1), ',', '|'), '.', ','), '|', '.')

, ersetzen durch | -> . ersetzen durch , -> | ersetzen durch .

Dann wird das query nicht erfolgreich ausgeführt

😂Na ja, auf so was muss man erst mal kommen! Für den CSV-Export reicht aus:

REPLACE(ROUND(`total_paid_tax_incl`, 2), '.', ',') 

Aber es sind noch lauter andere Fehler drin. Am besten suchst du dir einen fähigen Programmierer zum "Zusammenbraten", denn das geht nicht mal so eben mit links.  Doch ganz davon abgesehen: der Befehl SQL_CALC_FOUND_ROWS wird an dieser Stelle, also bei den SQL-Abfragen, sowieso nicht unterstützt.

In jedem Fall gibt es hier im Forum die Sektion Job-Angebote. Da wäre dieser Topic vermutlich besser aufgehoben.

[Dp.]

1 hour ago, Wuschel said:

😂Na ja, auf so was muss man erst mal kommen! Für den CSV-Export reicht aus:

REPLACE(ROUND(`total_paid_tax_incl`, 2), '.', ',') 

Aber es sind noch lauter andere Fehler drin. Am besten suchst du dir einen fähigen Programmierer zum "Zusammenbraten", denn das geht nicht mal so eben mit links.  Doch ganz davon abgesehen: der Befehl SQL_CALC_FOUND_ROWS wird an dieser Stelle, also bei den SQL-Abfragen, sowieso nicht unterstützt.

Eventuell reden wir aneinander vorbei. Das ist der Code von Prestashop, nicht meiner. Klickt man bei den bestellungen auf "Zur SQL-Abfragen exportieren", kommt dieser Code dabei rum. SQL_CALC_FOUND_ROWS funktioniert auch wunderbar.

 

Und das Thema ist ja nicht kriegsentscheidend. Wenn ich es in der nächsten Viertelstunde nicht zum Laufen kriege, werden die betreffenden Spalten der CSV vor dem Pivotieren halt durch 1.000.000 geteilt 😉

[Whiley]

vor 5 Stunden schrieb Dp.:

Wenn ich das im Backend anzeigen lasse, sieht es gut aus:

 

Beim CSV-Download dann nicht mehr:

Hallo Dp,

ich denke dein Spreadsheed Programm spielt dir da einen Streich (Spaltenformatierung). Wenn du deine exportierte csv-Datei in einem Texteditor (notepad++ ) aufrufst, was steht dann für ein Zahlenwert drin?

Grüsse
Whiley

[Dp.]

Danke, guter Hinweis. Der korrekte, wenn auch noch mit dem Punkt als Dezimaltrennzeichen:

Es scheint, als würde Excel beim Import den Punkt einfach ignorieren. Seltsam, aber damit kann ich arbetien.

[Wuschel]

On 6/1/2020 at 8:20 PM, Dp. said:

Eventuell reden wir aneinander vorbei. Das ist der Code von Prestashop

Oh, da haben wir wirklich aneinander vorbeigeredet. Mir war nicht klar, dass der AdminController in 1.7 solche umständlichen Abfragen generiert. Allerdings hatte ich gelesen, dass es dort einen Bug bei der Verwendung von SQL_CALC_FOUND_ROWS geben soll, der noch nicht behoben worden ist. 

Und nochmal: Excel ignoriert den Punkt nicht, sondern wertet ihn gemäß deutscher Schreibweise aus. Die 6 Stellen hinterm Punkt werden nicht als Dezimalstellen erkannt.

[Dp.]

Dann sind ja jetzt alle Unklarheiten beseitigt 😄 Danke dir!