![]() |
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. |
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