MySQL Funktion (z.B. YEAR()) gibt je nach DB unterschiedliche Typen zurück

[Medium]

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 =)

[himitsu]

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)

[Uwe Raabe]

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.

[Medium]

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.

[Uwe Raabe]

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: https://docs.devart.com/unidac/data_type_mapping.htm - zumindest in der aktuellen Version.

[Medium]

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

[himitsu]

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 SELECT * FROM &tablenbame 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)
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.

[HeZa]

Hallo Uwe,

Zitat von Uwe Raabe:

Seit ein paar Versionen erlaubt ein TDataSet einen Mischbetrieb mit statischen und dynamischen Feldern.

davon hatte ich noch nicht gehört. Hast du (oder jemand anderes) einen Tipp, wo ich mehr Informationen dazu finden kann?

Danke.

Ciao HeZa

[Uwe Raabe]

Das verbirgt sich im TDataSet im protected FieldOptions, das in abgeleiteten Klassen dann veröffentlicht wird.

Mit AutoCreateMode kann man festlegen, wie mit statischen und dynamischen Feldern umgegangen werden soll:

• acExclusive arbeitet so wie gehabt. Wenn keine statischen Felder da sind werden alle Felder dynamisch erzeugt.
• acCombineComputed lässt dabei dann noch (statische) berechnete Felder zu.
• acCombineAlways mischt die statischen Felder mit den (noch nicht vorhandenen) dynamischen Felder.

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.

[Medium]

Hatte ich bereits beantwortet. Die Methode DataTypeMap() gibt es dort auch nicht.

Zitat von Medium:

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.

Wenn ich nicht irre, sollte ich die letzte Version haben die ich für D2007 mit meiner Lizenz abrufen konnte. (Zudem würde ich nicht riskieren, für einen Zweizeiler potenziell in einem mehrere Mannmonate schweren Projekt nach unerwarteten Folgeeffekten eines Updates jagen zu müssen. Der ganze Thread hier ist schon in WEIT mehr Arbeit ausgeartet, als ich dafür je investieren wollte.)