Möglicher Fehler in GetTableName

[Dejan Vu]

Ok, verstanden (dann wäre eine Antwort zwar nicht korrekt, aber unwichtig).

Man kann bei einer Typ-2-Grammatik keinen nichthierarchischen Parser verwenden. Oder einfacher ausgedrückt: Die Sprache ist rekursiv formuliert (Queries können Queries beinhalten, es gibt Klammerebenen), also muss man einen Satz der Sprache (das 'SQL-Statement') auch rekursiv analysieren. Es reicht natürlich ein Stack, aber der ist ja auch rekursiv.

Ob sich das Problem mit RegEx lösen lässt, weiß ich nicht. Rein theoretisch nicht, denn RegEx kann 'eigentlich' nur Typ-3 Grammatiken parsen, aber mit dem ganzen Lookahead-Gedöns und dem bilden von Gruppen wäre es theoretisch denkbar, obwohl... nee. geht nicht (meine Meinung )

Jedenfalls geht es nicht so. Garantiert nicht. Um es richtig zu machen, musst du einen Parser schreiben, der die kompletten SELECT-Syntax implementiert und dann im aufgespannten Syntaxbaum beim 'äußeren' FROM-Knoten nachschauen: Dort hängen dann die JOIN-Operatoren mit den in Frage kommenden Tabellen. Allerdings ist es ja so, dass die Veränderung nicht über eine Tabelle läuft, sondern über viele, d.h. alleine schon das Funktionsresultat "der Tabellenname" ist falsch, es müsste "die Tabellennamen" heißen und pro Feld angegeben werden.

Tipp: SQL-Server kann direkt auf einer View Operationen (DELETE, INSERT, UPDATE) ausführen. Andere RDBMS können das vielleicht/vermutlich auch. Wenn als *das* dein Problem ist, packe deine Query in eine View und führe das Update einfach auf der View aus.

Ansonsten bin ich persönlich kein Verfechter von 'Ich verstehe die Query und baue Dir ein INSERT draus'. Das geht nämlich manchmal auch in die Hose. Besser ist es, die DML explizit auszuformulieren.

Aber vermutlich ist das eh nicht dein Problem.

[Sir Rufo]

Den ersten Tabellennamen vom äußersten FROM ...

SQL-Code:

select 
  *
from 
  ( select * from tab1 )

Es wird schwierig immer den richtigen Tabellennamen zu treffen und aufzulösen.

Darum ist es auch besser, die Statements eben nicht automatisch generieren zu lassen. Den Aufwand den man damit betreibt um auch wirklich alle Ausnahmen zu berücksichtigen schmeisst man wieder in die Tonne, wenn die nächste noch unberücksichtigte Ausnahme kommt. Irgendwann ist man es leid.

Da baue ich mir doch lieber ein Repository und arbeite mit Objekten, oder meinetwegen auch eine DataSet-Factory, die mir die passenden Abfrage-Instanzen liefert.

[jobo]

..lieber ein Repository..
Dazu noch der Hinweis, dass selbest das "richtige" finden des Tabellennamens u.U. nicht das Ende der Fahnenstange ist. Werden hier nur Spalten aus der Update Table selektiert, ist vielleicht alles im grünen Bereich, sind aber Werte aus anderen Tabellen in den Ausgabespalten dabei(soll ja vorkommen), dann kann man die nicht updaten, zumindest nicht auf Basis einer Update Table.

Im Repository würde man also nicht nur die Table, sondern vielleicht auch die Spalten mitverwalten.

[Sir Rufo]

Zitat von jobo:

..lieber ein Repository..
Dazu noch der Hinweis, dass selbest das "richtige" finden des Tabellennamens u.U. nicht das Ende der Fahnenstange ist. Werden hier nur Spalten aus der Update Table selektiert, ist vielleicht alles im grünen Bereich, sind aber Werte aus anderen Tabellen in den Ausgabespalten dabei(soll ja vorkommen), dann kann man die nicht updaten, zumindest nicht auf Basis einer Update Table.

Im Repository würde man also nicht nur die Table, sondern vielleicht auch die Spalten mitverwalten.

Wieso denn jetzt Spalten mitverwalten?

Meine Repositories sehen ungefähr so aus

Delphi-Quellcode:

type
  TFooId = type Integer;
  TFooIdHelper = record helper for TFooId
    const
      null = 0;
  end;

  TFoo = class
  public
    constructor Create( Id : TFooId; const Title : string );
    property Id : TFooId read Fid;
    property Title : string read FTitle;
  end;

  IFooRepository = interface
    function Get( FooId : TFooId; out Foo : TFoo ) : Boolean;
    function GetAll : TArray<TFooId>;
    function Store( Foo : TFoo; Dispose : Boolean = False ) : Boolean;
    function NextFooId : TFooId;
  end;

Das Repository weiß, wo die Informationen gespeichert werden und eben auch, wo es die Informationen wieder holen kann (da wo man auch speichert?). Das Repository hat dann x Abfrage-Objekte und leitet die Anforderungen durch diese hindurch.

[Neutral General]

Leute ihr driftet total ab.

Es ist jetzt total egal ob man sich irgendwelche Statements generieren lassen sollte oder nicht oder welche Alternativen es dazu gibt.

Die Frage ist: Ist das ein Fehler in der RTL?
Sollte diese Funktion in dem von mir genannten Fall nicht "TABELLE1" statt "TABELLE_INNEN" zurückgeben?

Alles andere ist vollkommen irrelevant.

[Uwe Raabe]

Zitat von Neutral General:

Die Frage ist: Ist das ein Fehler in der RTL?
Sollte diese Funktion in dem von mir genannten Fall nicht "TABELLE1" statt "TABELLE_INNEN" zurückgeben?

Gibt es denn irgendwo eine Beschreibung, was die Funktion GetTableNameFromSQLEx bei bestimmten Eingabeparametern zurückliefern soll? Eine vollständige semantische Analyse des SQL-Statements kann man da wohl eher nicht erwarten.

Bei FireDAC ist das zumindest so gelöst, daß man über UpdateOptions.UpdateTableName den Namen angeben kann und sogar muss, wenn "FireDAC den Namen der zu aktualisierenden Tabelle nicht korrekt aus der Abfrage abrufen kann." Dabei ist es ziemlich unerheblich, warum FireDAC das nicht kann, weil der entsprechende Algorithmus vielleicht nur für simple SELECT-Anweisungen funktioniert. Ich habe jetzt die erwähnten DA-Komponenten nicht greifbar, aber vielleicht gibt es da ja einen ähnlichen Mechanismus.

[jobo]

Zitat von Neutral General:

Leute ihr driftet total ab.

Es ist jetzt total egal ob man sich irgendwelche Statements generieren lassen sollte oder nicht oder welche Alternativen es dazu gibt.

Die Frage ist: Ist das ein Fehler in der RTL?
Sollte diese Funktion in dem von mir genannten Fall nicht "TABELLE1" statt "TABELLE_INNEN" zurückgeben?

Alles andere ist vollkommen irrelevant.

Ok, sorry für so viel Drift!
Solange keiner weiß, was die Funktion machen soll, kann das keiner beantworten.

[Dejan Vu]

Zitat von Sir Rufo:

Es wird schwierig immer den richtigen Tabellennamen zu treffen und aufzulösen.

Unabhängig davon, das so ein Automatismus wirklich beknackt ist, glaube ich, das der SQL-Server das auflösen kann, denn er weiß ja durch den Queryplan genau, welche Tabelle er für welches Feld referenzieren muss. Und wenn keine Aggregate in der Query sind und sich alle Spalten der View direkt auf Spalten einer Tabelle abbilden lassen, sollte er das auch auflösen können. Deshalb kann man so eine schöne Systemgrenze ziehen, indem die Anwendung einfach nur 'Tabellen' beackert: Ob das Views sind und aus anderen tabellen zusammengepopelt wurde, ist egal. Ich kann mir auch Instead-of-Trigger bauen, als Alternative zu ORM und alles-im-Delphi-Code. Das ist vor allen Dingen dann besser, wenn ich häufig Massenupdates habe, à la "update meineView set Feld='Bar' where anderesFeld='Foo'"

Zitat von jobo:

Ok, sorry für so viel Drift!

Damned, das war doch eben noch nicht da

Alles klar: Zurück zum Thema: JA ein Bug (sagte ich bereits).