variabler Tabellenname in SQL-Abfrage

[jobo]

Also ich bezeichne es wie folgt:
Hochkomma = '
Anführungszeichen = "
Tick = ´
Backtick = `

Der entscheidende Punkt für den Anfang ist doch erstmal:
Tabellen und Feldnamen gehen idealerweise im SQL "Fließtext" einfach so ohne weiteres ein, keine Hochkomma oder wie auch immer.
Es gibt in mysql (besonders) oder auch woanders (Access dann noch mit eckigen Klammern) dieses Theater, damit man auch Leerzeichen und Chinesisch usw. in die Feldbezeichner bringen kann.
Ich hab es lieber clean, ASCII ANSI Bezeichner auf Englisch und fertig.

Das ganze Problem hat erstmal nichts damit zu tun, wie ich mein SQL dann zusammensetze mit variablen Spalten.
Einfache String Konkatenierung. Dabei muss dann im Quelltext ggF. escaped werden.

Das nächste Problem ist dann die Nutzung von Parametern für die Werteangaben. Das sollte man natürlich machen, wegen kann man überall nachlesen.

Dieses Verfahren mit den Parametern funktioniert nach meiner Kenntnis aber nicht mit Feldnamen.

Im Ergebnis habe ich also Parameter eingesetzt und bin u.U. trotzdem noch nicht gegen Injection gefeit.
Das kann man aber doch wohl verhindern, indem man die Feldnamen nicht beliebig macht, sondern Wertelisten vorgibt, oder?
Also mit einer Combobox ohne Editmöglichkeit.

[blawen]

Zitat von Luca Haas:

Es tut mir leid, aber so genau verstehe ich nicht wie du das mit dem + meinst. Ich programmiere noch nicht so lange und kenne das leider noch nicht

Delphi-Quellcode:

  begin
    CB1Spalte := ComboBox1.Text;
    SQLBefehl := SQLBefehl + (' WHERE +CB1Spalte+ LIKE ''%' + StringReplace(Edit3.Text, '*', '%', [rfReplaceAll]) + '%''');
  end;

Es sieht jetzt so aus, allerdings erhalte ich noch eine Fehlermeldung, wegen falscher Syntax in der Nähe von LIKE

Wieso so "kompliziert"?
Ich würde es Sinngemäss so lösen
Query.SQL.Text := 'SELECT * FROM ' + ComboBox1.Text + ' WHERE...

[p80286]

Zitat von jobo:

Dieses Verfahren mit den Parametern funktioniert nach meiner Kenntnis aber nicht mit Feldnamen.

Du könntest Dir hier mit einem "Wörterbuch" der vorhandenen Tabellen und Felder weiterhelfen. Damit ist dann auch die Gefahr der Injection gemindert.

Gruß
K-H

[HolgerX]

Hmm..

Zitat von p80286:

Du könntest Dir hier mit einem "Wörterbuch" der vorhandenen Tabellen und Felder weiterhelfen. Damit ist dann auch die Gefahr der Injection gemindert.

Je nach Verbindung zur Datenbank kannst Du von der Datenbank auch die vorhandenen Tabellen und Felder auslesen und somit dein 'Wörterbuch' dynamisch erstellen.

[nahpets]

Die TAdoConnction hat 'ne Methode zum Holen der Tabellennamen. Das Ergebnis wird in eine Stringliste geliefert. Dafür kann man ComboBox.Items nehmen.

Ebenfalls gibt es eine Methode zum Holen der Spaltennamen einer Tabelle, auch hier ist das Ergebnis eine Stringliste, kann also Items einer weiteren ComboBox sein.

Wenn sich der ItemIndex der Combobox für die Tabellennamen ändert, befüllt man dann die ComboBox für die Spaltennamen entsprechen (geht einfach über die Ereignisroutinen).

Beim Zusammenbauen des SQLs nimmt man dann nicht mehr ComboBox.Text sondern ComboBox.Items[ComboBox.ItemIndex] und schon hat man eine sichere Auswahl von Tabellen und Spaltennamen.

Wenn der ItemIndex der ComboBoxen kleiner 0 ist, gibt man dem Anwender ggfls. eins auf die Finger, weil er was ungültiges in ComboBox.Text eingegeben hat oder bei ItemIndex = -1 macht man einfach nichts. (Button zum Schließen der Suchmaske disablen, keine Zuweisung des SQLs an die Query ...)

Damit der Anwender über die Eingabe des Suchbegriffes keinen "Mist" mehr machen kann, fügt man, statt der Eingabe, in das SQL einen Parameter ein und befüllt diesen dann mit der Eingabe. Dadurch spart man sich dann auch direkt das Rummhampeln mit ' und '' und ''' und QuotedStr.

[p80286]

Zitat von nahpets:

Die TAdoConnction hat 'ne Methode zum Holen der Tabellennamen. Das Ergebnis wird in eine Stringliste geliefert. Dafür kann man ComboBox.Items nehmen.

Die Funktion ist mit Vorsicht zu genießen, da nicht alle Views/Tabellen zurück geliefert werden (ist je nach DB unterschiedlich) darum lieber die DB direkt fragen.

Gruß
K-H

[nahpets]

Ja, stimmt schon, aber dann verabschieden wir uns sehr schnell von der Datenbankunabhägigkeit.

Und für 'nen Programmiereinsteiger, der gerade seine erste Datenbankapplikation schreibt, dürften die hier von uns vorgeschlagenen Sachen weit über das hinausgehen, was man zum ersten Lernen so benötigt.

[HolgerX]

Zitat von p80286:

Zitat von nahpets:

Die TAdoConnction hat 'ne Methode zum Holen der Tabellennamen. Das Ergebnis wird in eine Stringliste geliefert. Dafür kann man ComboBox.Items nehmen.

Die Funktion ist mit Vorsicht zu genießen, da nicht alle Views/Tabellen zurück geliefert werden (ist je nach DB unterschiedlich) darum lieber die DB direkt fragen.

.. und es funktioniert wahrscheinlich nur mit ADO so

Hingegen ein SQL-Query wie

Code:

Select TABLE_NAME, COLUMN_NAME from INFORMATION_SCHEMA.COLUMNS
order by TABLE_NAME

functioniert meines wissen auf MariaDB, MySQL, PostgreSQL ,SQL-Server.... mit diversern Query Komponenten und liefert dir direkt den Tabellennamen mit den Columnenamen

[nahpets]

Entsprechende Routinen gibt es auch in anderen Komponentensammlungen für Datenbankzugriffe.

Sie kapseln (mal mehr, mal weniger gut), den SQL-Standard, aus dem sich ergibt, wo im INFORMATION_SCHEMA was zu suchen ist.

Wenn man die Routinen der Komponenten nutzt, muss man halt nicht alles selber machen.

Letztlich müssen es alle Komponentensammlungen auf den gemeinsamen Nenner des SQL-Standards runterbrechen, um gegen beliebige Datenbanken laufen zu können.

Und wenn man Glück hat, haben die Bauer der Komponentensammlungen dann auch die Besonderheiten von X Datenbanken (mehr oder weniger gut) berücksichtigt.

Und ja, man kann es immer und überall auch selber machen. Aber für jemanden, der das Programmieren mit Delphi lernt und die ersten Schritte in Richtung Datenbank macht, ist das händische Ermitteln der Datenbankinformationen zur weiteren Verarbeitung, doch etwas übertrieben.

Jedenfalls nutze ich zuerst die Methoden, die Delphi mit seinen Komponenten liefert. Und erst dann, wenn es da Probleme gibt, fange ich an, eigene Lösungen zu entwickeln.
Das soll in der Art auch der Sinn von RAD sein, wofür Delphi ja seit seinen Anfangstagen durchaus bekannt ist.

[p80286]

Zitat von nahpets:

Letztlich müssen es alle Komponentensammlungen auf den gemeinsamen Nenner des SQL-Standards runterbrechen, um gegen beliebige Datenbanken laufen zu können.

Und wenn man Glück hat, haben die Bauer der Komponentensammlungen dann auch die Besonderheiten von X Datenbanken (mehr oder weniger gut) berücksichtigt.

OK die Hardcore Fraktion sieht das wohl etwas enger, aber darüber können wir uns irgendwann anders streiten!
Solange man weiß, daß es ein Kompromiss ist...

Gruß
K-H