Existiert ein Feldname einer TQuery ?

[Delphi.Narium]

Prinzipiell ist das richtig, aber leider nicht so wirklich einheitlich umgesetzt.

Wenn man Software nur für eine bestimmte Datenbank schreibt, ist das klar der bessere Weg.

Muss man "allgemeinverbindlich" sein, hilft leider nur der Weg über 'ne mehr oder weniger sinnvolle Krücke.

Das select * from Tabelle hat den Nachteil: Bei vielen Daten in der entsprechenden Tabelle kann das schon was dauern. Man sollte also die Abfrage einschränken. Da gäbe es z. B.:

SQL-Code:

select first 1 * from tabelle;
select top 1 * from tabelle;
select * from tabelle where rownum <= 1;
select * from tabelle limit 1;
-- eventuell können dashier ja alle:
select * from tabelle where 1 = 2;

Irgendwie nach Jahrzehnten immernoch ein leidiges Thema

[kmartin]

Zitat von Delphi.Narium:

SQL-Code:

-- eventuell können dashier ja alle:
select * from tabelle where 1 = 2;

Irgendwie nach Jahrzehnten immernoch ein leidiges Thema

Die letzte Lösung verwende ich in der Regel sehr gerne. Weiteres Problem zwischen verschiedenen DBMS ist die Frage, wie non Standard Tabellennamen verwendet werden.
Rechteckige Klammer oder doppelte Anführungszeichen.

[p80286]

Zitat von kmartin:

Weiteres Problem zwischen verschiedenen DBMS ist die Frage, wie non Standard Tabellennamen verwendet werden.
Rechteckige Klammer oder doppelte Anführungszeichen.

Was meinst Du damit? Jede Datenbank hat die Tabellen(namen) die verwendet werden. Die kann man mögen oder nicht (gleiches gilt für die Zugriffskomponenten).

Gruß
K-H

[jobo]

Ich denke er meint Tabellennamen mit nicht alphanumerischen Zeichen aus dem ASCII Raum, also so was wie
Select * from Oma's Küchentricks
Select * from [Oma's Küchentricks] (Access)
Select * from ´Oma's Küchentricks´ (mySQL)
Select * from "Oma's Küchentricks" (Oracle)
usw.

Ich würde da dann kuechentricks drauß machen und eine Spalte für den Urheber (Oma oder andere) anlegen.

[joehd]

Meine Erfahrung ist es auch das es von DB zu Db verschieden ist.
Dies hier war ein Beispiel der sqlite ich nutze aber oft auch die Firebird. Ich meine das es da erhebliche Unterschiede gibt.
Ich habe die Sqlite für eine kleine Verwaltungssoftware genutzt die normal nur von einem Platz aus bedient wird. Sqlite ist glaube ich gelesen zu haben nicht so richtig Mehrplatz fähig... aber dafür echt leicht zu handeln

[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.

[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

[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