Existiert ein Feldname einer TQuery ?

[rokli]

Moin,

also ich kann mir im Moment kein in der Praxis relevantes Beispiel vorstellen, bei dem ich zur Laufzeit der Software noch Tabellenstrukturen anpassen müsste ... das muss doch vorher geklärt sein, maximal noch während der Entwicklung - oder?

Freilich - über die Prüfung der Felder, so wie Ihr es vorgestellt habt mit der Abfrage der FIELDS-Informationen ist das schon ok.

Grüße - und einen schönen Montag und ne gute Woche!

[TigerLilly]

Zitat von rokli:

also ich kann mir im Moment kein in der Praxis relevantes Beispiel vorstellen, bei dem ich zur Laufzeit der Software noch Tabellenstrukturen anpassen müsste

Ich schon.

Software ist nichts statisches, sondern entwickelt sich. Sei es, weil die Kunden neue Anforderungen haben (Wir brauchen hier noch die Bezeichnung in Englisch!), sei es weil sich die Welt ändert (gesetzliche Vorschriften). Möglicherweise hat auch der Softwarehersteller eine coole Idee, die bei einem Update eingebracht werden soll.

Für mich ist es eher genau umgekehrt: Es ist davon auszugehen, dass sich die Tabellenstrukturen ändern werden.

[p80286]

Zitat von TigerLilly:

Ich schon.

Wohl war, aber dann sollte auch bekannt sein, in welcher View/Tabelle die Feld/Tabellen-Namen zu finden sind.
Die vorgestellte Methode ist mMn nur sinnvoll, wenn man eine Oberfläche hat, die keine Information über die darunter liegende Datenbank hat.
Außerdem gibt es Schnittstellen (ADO zB) die mit einem speziellen Befehl Informationen über die darunter liegende DB liefern.

Grüße
K-H

[joehd]

Also ich prüfe beim Start der Software ob die Strukturen stimmen. Ich habe die Software jetzt aber auch so geschrieben das die beim Start prüft ob die DB da ist wenn nicht die ganze Datenbank Version x erzeugt und dann laufen Prozesse die die neueren Felder prüfen. Somit ist es egal ob alle zwischenupdates vom Kunden gemacht wurden. Die Software zieht das immer hoch. Ist in dem Fall jetzt komfortabel ....

[Frickler]

Zitat von rokli:

Moin,

also ich kann mir im Moment kein in der Praxis relevantes Beispiel vorstellen, bei dem ich zur Laufzeit der Software noch Tabellenstrukturen anpassen müsste ... das muss doch vorher geklärt sein, maximal noch während der Entwicklung - oder?

Naja wie TigerLilly schon schrieb, es ändert sich nicht bloß die Software, sondern auch die Datenbank im Laufe der Jahre. Wir haben dafür bei unseren Kunden eine extra Software, die diese Änderungen vornimmt. Als erstes wird natürlich gecheckt, ob noch sonst wer in der Datenbank angemeldet ist - dann wird der Vorgang abgebrochen mit einer Meldung a la "User 'Meier' noch im Programm" - und ansonsten gehts los, wie beschrieben: Felder testen und ggfs. abändern (z.B. Strings verlängern), löschen oder neu hinzufügen.

Im "normalen Betrieb" der Software wird dann aber nichts mehr angepasst.

[rokli]

Hallo,

das ist natürlich klar, aber wenn sich die Anforderung ändert, ändert sich neben der DB natürlich auch das Programm - aber dann sind wir ja wieder an der Weiterentwicklung ...

Und ganz allgemein: Wir bauen die DB in der Regel mit den Tools, die dafür zuständig sind: MS SQL Server Management Studio, IBM System i Navigator oder meinetwegen auch mit dem tollen DBeaver. Aber aus meiner (Anwendungs-)Software heraus, hab ich das quasi noch nie benötigt. Und "Data driven software" halte ich persönlich doch eher für schwierig.

Greez