Hi Tigerlilly
Zitat:
Das sieht so aus, als ob du für einen Fehler, den du gemacht hast (oder etwas, das du jetzt einfach besser weißt), einen eleganten Workaround suchst. Mir kommt diese Lösung sehr kompliziert und schwerfällig vor.
Das ist nicht
ganz falsch. Zu Anfang erstellte ich mir in
MySQL-Workbench ein Datenbankmodell. Dabei ergaben sich, zB. in einer n:m-Zwischentabelle, so unsägliche Namen wie "BildDescribeTabelle_Bildtabelle_idBild" für ein Fremdschlüsselfeld. Auch wenn ich das relativ früh bemerkte, wollte mir vorerst keine gangbare Lösung einfallen - etwa Text statt Describe oder tbl statt Tabelle für einen immer wieder auftauchenden Teilstring.
Schwerfällig ist eigentlich der Part, der sich, ob unschön oder nicht, zuallererst anbietet: Ich schreibe eine neue Klasse, die genau das tut, was die alte macht, aber mit Feldern und Methodenköpfen analog der SQLite-Datenbank. Nicht unmöglich, aber eine Sisiphusarbeit - einmal ein klein wenig nicht aufgepasst, und schon beginnt später die Suche nach der Nadel im Heuhaufen.
Wobei das nicht mal das Hauptproblem ist. Es wäre aber wünschenswert, eine Customklasse zu haben, um, sollte ich in Zukunft vor dem selben Problem stehen, dieses mit
OOP lösen zu können.
Zitat:
Kannst du nicht alles kübeln + neu beginnen? Und diesmal von Beginn an besser?
Eher nicht. Zum einen würde dies bedeuten, ein funktionierendes Programm neu zu bauen anzufangen und zum andern wäre die Sache mit der Klasse TQueryresultClass nicht gelöst - es sei denn, du meinst mit 'kübeln' gerade mal TQueryresultClass. Das hiesse dann: da weitermachen, wo ich jetzt stehe, nämlich beim Neuerstellen von TQueryresultClass unter Verwendung der nun aktuellen Namen.
Aber vielleicht ist das noch viel einfacher, als ich mir gedacht habe: TQueryresultClass erhält ein Feld "Params" und feuert einen Event - das Datenmodul, oder wer auch immer, erhält einen Eventhandler, der die Tabellen und Felder der DB abfragt. Soweit, so gut: wie TQueryresultClass in die Strings der Params-Liste die Ergebnisse des Querys speichert, weiss ich erstmal noch nicht könnte 
so geschehen.
Andrerseits ist das bis jetzt auch nur die Halbe Wahrheit - TQueryresultClass besitzt Unterklassen, die auch umbenannt werden müssten...
Obigen Absatz habe ich mal stehen lassen. Durchgestrichen habe ich ihn wegen der Unterklassen, die auf diese Weise nicht deklariert werden können, Zumindest so, wie ich das bis anhin sehe.
Im Anhang lege ich mal die TQueryresultClass-
Unit bei, um den Aufbau der Klasse zu verdeutlichen.
Gruss
Delbor