![]() |
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 02:21 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