Query soll anderen Datentyp liefern

[Medium]

Moinmoin!

Ich bastel hier gerade ein älteres Projekt um, und stoße auf einen Stein. Ich hab hier einen schicken QuickReport (den ich auf keinen Fall nach Rave oder was-auch-immer umbauen werde, das zahlt mir keine Sau ). Der hängt an einer TZQuery, in deren SQL Statement u.a. ein gezähltes Feld vorkommt (COUNT(foo)). Nun meckert mich meine TQRExpr-Kompo die mit dessen Darstellung beauftragt ist an, dass dieses Feld einen unbekannten Datentyp hätte.
Kurzerhand die Felder im Feldeditor des Querys automatisch eingefügt, und erkannt: Es ist ein TLargeintField statt eines TIntegerFields, welches sich in einer anderen nicht berechneten Spalte auch ganz wunderbar darstellen lässt.
Ich möchte nun MySQL egal wie unsanft davon überzeugen, dass es mir auch in dem COUNT()-Feld gefälligst einen Int32, und keinen 64-Bitter zurückschmeisst. Mein erster Ansatz war CAST() oder CONVERT(), allerdings treffen die nur die Unterscheidung zwischen signed und unsigned, und machen ansonsten auch einen auf 64 Bit.

Wat habbich denn hier an Chancen und Möchlichkeiten?

[guinnes]

Zitat von Medium:

Wat habbich denn hier an Chancen und Möchlichkeiten?

Multiplizier das berechnete Feld mit 1.0. Dann hast du zwar einen Floatwert, aber kein unbekanntes Format mehr

[Medium]

Nach einiger Sucherei scheint es so zu sein, dass man da schlicht nix machen kann. Auch kann ich kein Update für QR runterladen, da ich dank Bündelung mit D7 keinen Zugang zu den Downloads habe - 1a. Darüber hinaus hab ich nichtmal rausgefunden welche QR Version wir nun eigentlich genau haben, und da ein Update vermutlich eh wieder nen kompletten Neuaufbau der Reports bedeutet hätte, hab ich mir nun anders beholfen:
Ich hab mir ne TkbMemTable geschnappt, der Felder mit den gewünschen Typen aufgezwängt, und die Records aus meinem TZQuery da rein gepresst. Die MemTable kann glücklicherweise als Source für einen QReport benutzt werden. Sicherlich nicht elegant, aber da die Tabellen nur ein paar zig bis ~200 Einträge haben verschmerzbarer als jede andere Alternative (welche als einzige mir erkenntliche eine komplette Migration der Reports auf Rave wäre, wo ich mir noch was intelligents zum Ersatz der TQRCharts hätte aus den Fingern saugen müssen).

Was einen so eine Popeligkeit doch an Zeit kosten kann

Sorry fürs so genervt klingen. 3h Schlaf und dann an sowas den Vormittag verheizen macht dünnhäutig =)

Edit: Huch! Hat sich einer zwischen gedrängelt. Gar keine so üble Idee guinnes, das versuch ich doch glatt auch noch! Merci!

Edit2: Tag gerettet, das klappt vorzüglich! Und fast schon peinlich dass ich da nicht selbst drauf kam, so simpel wie es ist. Ich schieb das mal auf meine kurze Nacht Danke dir guinnes!

[Medium]

Ich muss das noch mal hoch ziehen, da sich eine sehr sehr ähnlich Frage ergeben hat:

Ich habe ja u.a. TQRCharts im Einsatz, und diese sollen auf ihrer X-Achse einen Datumswert tragen. Ziel ist ein Balkendiagramm, dass Werte tageweise summiert darstellt. Der SQL String schaut so aus:

SQL-Code:

SELECT DATE(V_DAT) AS V_DAT, ROUND(SUM(ANTEIL_I)) AS MENGE 
FROM rpohis 
WHERE CHARGE <= 100 
  AND M_NR = '1' 
GROUP BY V_DAT 
ORDER BY V_DAT

Das Feld V_DAT ist hier der Übeltäter, da es den Datumswert anders zurück liefert, als es die alte Version auf Basis von Paradox tat. Diese hat nämlich einen schmucken Float geliefert, den ich im Chart als Achsengröße einsetzen konnte. MySQL liefert hier aber einen String, und mit dem ist's dann leider Essig.

Nun steht in der MySQL Doku:

Zitat:

Note that if either operand is a floating-point value, the result is a floating-point value

Also ich, gewitzt wie ich bin, gleich mal den selben Trick wie oben probiert, und an DATE(V_DAT) noch ein *1.0 angehängt. Und leider Pustekuchen, ich bekomme lediglich das Jahr - also den Ganzzahlanteil daraus. Casts auf Datumstypen brachten auch nix, alle kommen als String in meiner ZQuery an. Auch ein +0.0 brachte übrigens selbiges Ergebnis.

Hat da evtl. noch jemand einen ähnlich einfachen aber genialen Kniff auf Lager, wie ich nun Datumswerte als Floats rauskitzeln kann?

[Bernhard Geyer]

Zitat von Medium:

Auch kann ich kein Update für QR runterladen, da ich dank Bündelung mit D7 keinen Zugang zu den Downloads habe - 1a.

Du kannst dir ja eine QR-Lizenz kaufen um diese Bündelung aufzubrechen. Dann bekomst du auch ganz neue Versionen wo evtl. dein Problem gefixt ist.

[Medium]

Die 1000 Pfund lohnen sich für diese eine Migration nicht mehr für uns - es ist das letzte Projekt aus dem Altbestand "Paradox", und auch das einzige dass QR so intensiv nutzt. Da käme es glatt noch billiger alles auf Rave umzusetzen, und ich habe zudem nirgends einen Hinweis dazu gefunden dass o.g. Problem in neueren QR Versionen nicht mehr besteht. Über kurz oder lang wollten wir schon gerne weg von QR, und DANN mal eben vierstellig britisch dafür auf'n Tisch legen? Ich denke nicht

Das Eingangsproblem ist nun aber mit dem Kniff von guinnes zufriedenstellend gelöst, jetzt geht's nur noch um das von über deinem Posting.

[guinnes]

Wenn dein V_DAT ein DateTime ist, liegts wohl an den Zeos, bei mir kommt ein Datetime Feld auch als Float rüber. Du könntest es noch mit UNIX_TIMESTAMP(V_DAT) versuchen und dann selber umrechnen.

[Medium]

Es ist ein DATETIME (bzw. nur DATE nach dem DATE() Aufruf), allerdings bekomme ich die selben Ergebnisse im MySQL Explorer (der, der auf der MySQL Seite unter Tools mit angeboten wird). Ich vermute mal ganz forsch, dass die wohl eher nicht die Zeos benutzen.

Die Konvertierung auf diese Art ist mir vorhin garnicht aufgefallen, ich hatte immer mit CONVERT() rumexperimentiert. Das schaut glatt nach einer Möglichkeit aus, da ich nun aber zu Hause bin kann ich's erst morgen testen. Danke dir nochmals!

[guinnes]

Hast du es mal ohne das DATE vorher versucht ?

[Medium]

Das nicht direkt. Ich hatte in der Paradox-Variante ein CAST/SUBSTRING/CAST benutzt um das Datum um die Uhrzeit zu beschneiden, wo als letzter Schritt wieder auf DATETIME, also den Ursprungstyp, zurückgecastet wurde. Das hatte ich zunächst so übernommen, und das warf auch ein String hinten raus.