![]() |
Datenbank: MySQL/MariaDB • Version: diverse • Zugriff über: UniDAC
MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Ich möchte gern eine einfache Abfrage machen:
Code:
Das ganze in einer TUniQuery, in welcher ich die Felder anlegen lassen habe.
SELECT
YEAR(V_Dat) yr, MONTH(V_Dat) mn, DAY(V_Dat) dy, SUM(Anteil_I) sm FROM rpohis WHERE Tank_Nr = 20 GROUP BY DATE(V_Dat) ORDER BY yr DESC, mn ASC, dy ASC Mit meiner DB auf meinem Entwicklungs-PC werden diese für die Spalten yr, mn und dy als TIntegerField angelegt. Auf dem Live-System beim Kunden ist statt MariaDB noch eine ältere MySQL Installation, die ich auch nicht mal eben wechseln kann. Diese scheint für die Datumsfunktionen nun aber LargeInts zurückzugeben, sodass mein Programm dann meckert, dass TLargeField erwartet würden, aber TIntegerField gefunden wurden. Ich habe bislang keine Möglichkeit gefunden, wie ich in dem SELECT einen bestimmten Ergebnistyp erzwingen kann. CAST() und CONVERT() lassen lediglich die generischen SIGNED und UNSIGNED Tyen zu, die zum selben Problem führen. Einen View kann ich auf dem Live-System aus mir unbekannten Gründen auch nicht erzeugen (die Option zum Anlegen ist unter HeidiSQL ausgegraut) - mit dem hätte ich ja die Möglihckeit die Typen fix zu definieren. Was könnte ich da noch versuchen? |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Ich verstehe jetzt nicht ganz wo Du das Problem hast.
Deine TUniQuery hat angelegte Felder? Und es knallt dann auf einem von beiden Rechnern? Dann arbeite doch ohne angelegte Felder. Das macht doch eh nur Ärger. Und greif dann via FieldByName('FieldName').As... zu. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Das ist leider keine Option, wenn ich das Ergebnis dann mit einer TDataSource in einen TAdvDBGrid darstellen will. Nen Grid von Hand zu befüllen würde ich gern vermeiden, und wozu hab ich denn sonst so schmucke Komponenten gekauft =)
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Du kannst doch im Grid die Spalten schon erstellen und falls die im DtaSet dafür nötig waren, dann aus dem Dataset wieder rauslöschen und automatisch erstellen lassen.
Neuerdings können viele Query-Komponenten nun auch Beides (z.B. FireDAC), also ein paar Felder im Designer oder vorm Öffnen per Code dran und den Rest beim Open automatisch. (früher ging nur entweder oder) |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Mit FireDAC könnte man auch das Datentyp-Problem mit einem entsprechenden Mapping lösen. Ob, und wenn ja, wie das mit TUniQuery geht, kann ich leider nicht sagen.
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Mein Fehler: Habe vergessen zu erwähnen, dass das unter D2007 passieren muss. Das sollte eine ganz einfache aus der Hüfte geschosssene Funktion für ein bestehendes Programm werden, mit der man sich Verbräuche summiert pro Tag anzeigen lassen kann. Habe ich unentgeldlich zugesagt, weil "ist ja bloß 2 Zeilen SQL, und nen Grid auf ein Fenster schmeißen". Bis ich es dann beim Kunden ausgeführt habe war das auch so...
Also: FireDAC schön und gut, kann ich hier aber nicht mal so eben austauschen ohne ein paar Mannwochen Arbeit. Ich habe bei Uni nichts gefunden, was irgendwie den Namen "Mapping" trägt, und habe auch nicht wirklich eine Vorstellung davon was das genau macht in diesem Zusammenhang. Das Alter der IDE und Komponenten führt fürchte ich auch dazu, dass Himi's 2. Idee hier nicht eingesetzt werden kann. Die erste verstehe ich nicht ganz. Die Spalten im Grid an sich sind nicht das Problem, sondern die Fields die ich im Field-Editor der Query anlege. Da diese mitsamt ihres Typen fest im Deklarationsteil landen, verstehe ich gerade nicht wie ich da zur Laufzeit etwas löschen/hinzufügen können soll. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Seit ein paar Versionen erlaubt ein TDataSet einen Mischbetrieb mit statischen und dynamischen Feldern. Das würde aber das Typ-Problem vermutlich gar nicht lösen.
Allerdings unterstützt auch UniDAC so ein Mapping: ![]() |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Sieht interessant aus, aber die D2007 Komponenten haben die entsprechenden Methoden und Eigenschaften offenbar leider noch nicht :(
Kann ich das nicht auch evtl. auf Seite der DB oder Abfrage lösen? Irgendwie muss man doch einem Result-Set konkrete Typen aufdrücken können :? |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
Im Regelfall lade ich die Query einmal zur Designzeit und lasse vom Grid alle Columns erstellen. Zur Laufzeit macht der Grid sich dann selber ran und ordnet alles passend zu. Namen und Typen sind ja bekannt. Der Grid hat zum Glück keine Probleme wenn die Typen leicht abweichen. Wenn dein Grid damit nicht klarkommt, die Columns müssten sich doch auch zur Laufzeit erstellen lassen? ...dann jeweils mit den passenden Typen. Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Es gibt irgendwo in der Komponente eine/meherere Tabelle/Listen, wo Übersetzungen drin stehen.
DatenbankTypen -> TDataType/TFieldType -> TFieldClassIrgendwas Und dann kann man eben teilweise im Select einen CAST machen. Bei uns gibt es noch was bissl Krankes, wo unsere abgeleiteten Querys (TPgQuery) nochmal ein
Delphi-Quellcode:
im BeforeOpen machen, um von der Datenbank die Typen abzufragen und die fehlenden Felder noch schnell zu erstellen. (Fields durchgehen und was noch nicht existiert als FieldDef ins eigentliche Query kopieren)
SELECT * FROM &tablenbame
Einige Felder erstellen wir manuell, z.B. wo Einstellungen gemacht und Events angehängt werden. Der Rest kommt "automatisch" aus der DB, so wie es dort grade aussieht. Nach dem Open kann man ja leider keine TFieldXyz anhängen. Jetzt, im aktuellen Delphi, wo es eventuell nun auch gemischt beim Erstellen geht (selber + automatisch), wäre es nicht mehr zwingend nötig das vor dem Open zu machen. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Genau das hilft leider nicht. Ich vermute, dass das DBMS so "intelligent" ist, dass es beim Cast auf diese generischen Typen die Länge des originalen Typens beibehält. Bei mir gibt meine MariaDB auf dem Entwicklungs-PC auch mit Cast einen Typen zurück, den mein Programm als Integer-Feld anlegen möchte. Die MySQL DB beim Kunden gibt, mit demselben Cast, allerdings ein LongInt zurück. Genau wie die ungecasteten Aufrufe von YEAR() usw.
Die Felder manuell im Feld-Editor als TLargeIntField anzulegen brachte zumindest, dass ich es jetzt beim Kunden laufen lassen kann. Aber testen kann ich damit nun nicht mehr. Ich hatte auch nach einer Möglichkeit gesucht, um mir mal vom DBMS selbst anzeigen zu lassen, welche Typen es für die Spalten um Result-Set verwendet. Für Tabellen gibt es da gleich mehrere Wege, aber für eine Query scheinbar nichts. Damit hätte ich zumindest dann etwas rumspielen können. Hat mich irritiert, dass das scheinbar wohl ein Nischenproblem ist. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Wenn du für einen Kunden ein Anwendung entwickelst ist es sinnvoll hier auch das vom Kunden genutzten System in der Entwicklungsumgebung zu nutzen.
Gegen MariDB zu entwickeln obwohl der Kunde ein (älteres) MySQL hat halte ich für kein guten Ansatz. Hier sind Probleme die nur beim Kunden auftreten vorprogrammiert. Wir haben bei uns z.B. MySQL, MS SQL und Oracle in diversen Versionen laufen, um genau möglichst nahe beim Kundensystem zu sein. Natürlich können wir nicht alles Sub-Versionen abbilden, aber ein "Aktueller Patch-Stand von Vx/y/z ist schon mal ein guter Kompromiss. bei MySQL hatten wir auch mal den Fall das eine Version von MySQL die Feldtypen falsch zurück gemeldet hat. D.h. unsere Anwendung konnte gar nicht mehr Funktionieren, da es die Typen bei Programmstart prüft. mit dem nächsten Fix-Version von MySQL hatten sie diesen groben Fehler behoben. Wenn dein Kunde natürlich eine solche Problematische Version hat wird es schwieriger. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
Die kann man sogar oftmals auf seinem NAS laufen lassen, falls man sowas besitzt und nicht alles auf dem PC haben will. Alternatiuv kann man das DBMS auch in je einer VM installieren (auf PC, NAS, sonstwo), wenn man mit dem Zeugs nicht direkt seinem Entwicklungsrechner zumüllen möchte. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Hallo Uwe,
Zitat:
Danke. Ciao HeZa |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Das verbirgt sich im TDataSet im protected
![]() Mit AutoCreateMode kann man festlegen, wie mit statischen und dynamischen Feldern umgegangen werden soll:
PositionMode steuert die Reihenfolge der Felder. UpdatePersistent passt einige der (statischen) Feldeigenschaften an die Informationen der Datenbank an. Das betrifft z.B. auch die Länge von Stringfeldern - ein häufiges Problem in früheren Versionen und beliebtes Argument gegen statische Felder. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Wie alt ist diese mySQL Version wohl? Ach, egal. Aber wenn man es weder selbst noch anderswo nachvollziehen kann, dann wird es spätestens kritisch.
Wie wär es mit einer Konvertierung in Text? Man müsste nur die Werte auf '00' formatieren. Ggf. sogar diese Werte auch wieder in Zahlen umwandeln. Verhält sich vielleicht anders als cast. (OT: Ich verstehe nicht, warum man sich mit so altem Zeug abgibt) |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
Zitat:
(Edit: Derselbe Kunde hat immerhin kürzlich ein genau soetwas für eine andere Anlage bestellt - die im Moment noch aktiv unter WinXP betrieben wird. Da hat zum Glück deren eigene IT den Hammer fallen lassen und gesagt, dass diese Kiste aus dem Netzwerk verschwinden muss, und die Software ist aus Gründen nicht unter neueren OSs lauffähig.) Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
DataTypeMap wurde bereits erwähnt. Warum wird es nicht genutzt?
Delphi-Quellcode:
Ich kann mir nicht vorstellen, dass es das bei D2007 nicht geben soll. Ich hab´s schon in D7 genutzt.
// FormCreate
Queryx.DataTypeMap.AddFieldNameRule('feldname', ftLargeInt); // <-- Hier den Typ des Entwicklungsrechners eintragen Sollte es kein DataTypeMap geben, Unidac updaten. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Hatte ich bereits beantwortet. Die Methode DataTypeMap() gibt es dort auch nicht.
Zitat:
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Nur 'ne ganz blöde Idee:
SQL-Code:
Mal mit sowas in der Art
SELECT
Cast(Concat(YEAR(V_Dat),"") as Signed) as yr, Cast(Concat(MONTH(V_Dat),"") as Signed) as mn, Cast(Concat(DAY(V_Dat),"") as Signed) as dy, SUM(Anteil_I) sm FROM rpohis WHERE Tank_Nr = 20 GROUP BY DATE(V_Dat) ORDER BY yr DESC, mn ASC, dy ASC
SQL-Code:
auf
SELECT
Cast(Concat(YEAR(sysdate()),"") as Signed) as yr, Cast(Concat(MONTH(sysdate()),"") as Signed) as mn, Cast(Concat(DAY(sysdate()),"") as Signed) as dy ![]()
|
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
Ich habe versucht, Dein Problem nachzuvollziehen, aber kein System gefunden, was alte genug ist, das Problem zu zeigen. Wahrscheinlich kleiner 5.7 oder kleiner 5. Für eine "2 Zeilen" Gefälligkeitsumsetzung habe ich m.E. einen relativ pragmatischen Workaround vorgeschlagen. Ich weiß glaube ich sehr gut, wovon ich rede und ich kenne die Situation, die Du schilderst. Ich fürchte, dass es dem Kunde am Ende auch gar nicht klar ist, wieviel Aufwand darin steckt, ein Altsystem am Laufen zu halten. Es gibt Softwarehersteller, die ewigen Support anbieten, ja, gibt es, aber kostet natürlich auch ewig viel. Das Verrückte ist doch, dass die Arbeit, die durch Anbieter in den Erhalt gesteckt wird, gleichzeitig das Argument des Kunden ist, nie etwas zu ändern. Zumindest läuft es so, wenn der Kunde -wenn schon nicht technisch- es nicht mal an den Wartungskosten merkt. Ich fahre ein relativ altes Auto aus dem vorigen Jahrtausend, nicht mal Oldtimer, aber was besonderes (für mich). Führt zu dem Effekt, dass die Ersatzteile immer teurer werden. (Während die Reparaturarbeit relativ günstig ist / bleibt. Vielleicht auch, weil es noch nicht viel Software in dem Auto gibt). Es ist jetzt nicht Aufgabe der Werkstatt, an dieser Realität etwas zu verschieben. Ich muss mir selbst überlegen, wofür ich wieviel Geld ausgeben will. Ja, der Vergleich hinkt, die Werkstatt ist nicht der Hersteller. Und der Hersteller ist natürlich in dem Segement sowieso raus. Was ich sagen wollte, war ja nichts anderes, als das was Du laut Antwort auch Deinem Kunden sagst, das System muss aktualisiert werden. Alternativ muss man halt einen riesen Popanz an Altsystemen in Gang halten (als Anbieter), um sowas nachzustellen. Auch wenn es nur um vermeintlich kleine Goodies geht. Perspektivisch werden solche Situationen natürlich immer wieder entstehen und die Sachen, die man heute baut, sollte man entsprechend strategisch bestmöglich ausrichten. Delphi war dafür m.E. schon immer ganz gut geeignet im Vergleich zu anderen Systemen. OS seitig kommt da mittlerweile immer stärker Linux ins Spiel, wo dann auch die Freiheitsgrade und Eingriffsmöglichkeiten steigen. |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Zitat:
@Jobo: Alles gut, du hast ja auch völlig Recht! Mich hatte in deinem vorigen Beitrag die Wortwahl und "Grundstimmung" nur etwas gejuckt :) Das Problem bei dem Kunden ist höchstwahrscheinlich, dass eine komplette Reimplementierung des gesamten Systems locker in der hohen Fünfstelligkeit landen würde, sein Mehrwert allerdings nicht operativ ist, sondern er lediglich alle paar Monate dann kleinere Arbeiten für ein paar hundert Euro weniger bekommen könnte. Die sind einfacher in den Etats unterzubringen als eine große Investition, nach der die Geschäftsführer aber keinen gesteigerten Produkt-Output in ihren hübschen Kurven sehen. Ein Stück weit kann ich das sogar nachvollziehen, auch wenn ich am Ende der "Leidtragende" bin. Ich hab das als "part of the job" mittlerweile akzeptieren können, und wir können ja auch davon leben - so ist's ja nicht. Führt aber halt dann auch gelegentlich zu solchen "Zusammenstößen" wie hier. Nichts für Ungut! Und wie schon geschrieben, finde ich die Lösungsidee sehr interessant! Bin gespannt :thumb: |
AW: MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück
Moin...8-)
Zitat:
Das Einzige was dann anders ist: Die Captions der Columns mußt du im Grid definieren... :wink: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz