DLEX und DYACC: SQL bzw PL/SQL Parser ?

[MaBuSE]

Hallo,
ich habe mir dlex und dyacc besorgt und denke gerade darüber nach einen PL/SQL Parser zu bauen.

Ziel ist es SQL-Skripte auf Syntax zu prüfen und die Skripte um eigene Anweisungen zu erweitern.

Meine Frage:

• Hat jemand schon Erfahrungen mit dlex und dyacc gesammelt?
• Hat jemand funktionierende sql.l bzw sql.y Dateien?
  (die er mir zur Verfügung stellen würde)
• Wo sind die Fallstricke?
• Gibt es vieleicht eine deutschsprachige Einführung / Tutorial / Buch zu lex und yacc (bzw. dlex und dyacc)?
  (außer das Drachenbuch)

Im Studium wurde zwar lex und yacc angesprochen, aber leider eben nur angesprochen (ca. 30 min) und das ist bei mir auch schon viele Jahre her ;-)
Ich hab mich damals schon geärgert, dass wir nicht mehr darüber erfahren haben, aber nie die Zeit gehabt es mir anzueignen.

Über Antworten würde ich mich sehr freuen.
Ich bin für jeden Hinweis dankbar.

[mschaefer]

Habe leider keine Erfahrungen mit dem aufgeführten Parser, aber bei der ZEOS-Libarie gibt es eine TZSQLParsr.pas vielleicht könntest Du da mal einen Blick drauf werfen.

Grüße // Martin

[alzaimar]

Es gibt von Turbopower eine OpenSource Datenbank-Engine (FlashFiler, glaube ich). Die gibt es bei Sourceforge zum Download. Der SQL-Parser deren SQL-Engine ist mit einem Compilergenerator geschrieben. Soweit ich mich erinnere, ist *.l und *.y-Datei bei den Sourcen mit bei.

Wieso schickst Du das Skript nicht einfach zum Server und überlässt dem die Arbeit?

Welche zusätzlichen Befehle / Features möchtest Du einbauen?

[mkinzler]

Oder
Alcinoe SQL Parser Functions v.3.50
und vielleicht auch der ActiveQueryBuilder, von dem es hier auch eine kostenlose Version gibt

[mschaefer]

Den Bedarf kann ich schon nachvollziehen. Oft hat man Abfragen die der User Umsortieren kann oder man lässt bestimmte Felder auswählen Oder ein Suchfeld mit Like Statement. Wenn man dann die Tabelle, Felder oder den Order-Anteil in seperaten Einheiten hat, dann kann man da schöne SQL´s dynamisch zusammenbauen. Frage mich aber ob man da wirklich einne kompletten Parser für braucht oder ob es nicht auch einfacher geht...

Grüße // Martin

[MaBuSE]

Hallo,
zuerst einmal Danke für Eure Antworten.

Zitat:

Zitat von alzaimar

Wieso schickst Du das Skript nicht einfach zum Server und überlässt dem die Arbeit?
Welche zusätzlichen Befehle / Features möchtest Du einbauen?

Alle Datenbankänderungen werden bei uns per Skript geliefert.
Diese werden analysiert und um weitere Anweisungen ergänzt.
(grants, stored procedure Aufrufe, ...)
Außerdem sollen bestimmte "Langläufer" erkannt werden. (z.B. Updates auf bestimmte Tabellen)
Diese bearbeiteten Skripte werden auf einer speziellen Test Datenbank ausgeführt und wenn keine Fehler aufgetreten sind auf der Produktionsdatenbank.
Wir haben viele Datenbanken, einige davon im mehrstelligen TerraByte Bereich mit sehr sensiblen Daten, da kann man nicht eben mal ein Skript auf der Produktion laufen lassen.
Das Tool soll ein Bestehendes ablösen und den DBAs etwas Arbeit abnehmen.

Ich habe mittlerweile ein kommerzielles Produkt entdeckt, dass auf lexx/yacc basiert.
GSP - general sql parser ( http://www.sqlparser.com/howto.php )
(Die VCL Version besteht aus einer Hand voll *.dcu Dateien, es muss also keine dll mitgeliefert werden.)

Es macht eigentlich einen guten Eindruck. Ich war nur über das Beispielprogramm in der Trail entsetzt und hoffe, das der eigentliche Code nicht so katastrophal programmiert ist.
Kleines Beispielprogramm -> nicht kompilierfähig, >250 Compilerwarnungen, nicht gerade übersichtlich programmiert.

Aber mit einem eigenen kleinen Beispielprogramm bin ich sehr schnell zum Ziel gekommen.

Delphi-Quellcode:

...
var
  SqlParser: TGsqlparser;
  i: Integer;
  j: Integer;
  s: string;
begin
  // Parser mit Create erzeugen, Sprache (=Oracle) zuweisen. 
  SqlParser := TgSqlParser.Create(DbvOracle);

  // SQL (PL/SQL) Text zuweisen
  SqlParser.SqlText.Assign(Memo1.Lines);

  if SqlParser.Parse = 0 then
  begin
    ...
    for i := 0 to SqlParser.SqlStatements.Count - 1 do
    begin
    ....
      // in SqlParser.SqlStatements[i].SqlStatementType steht der Typ z.B. update, create view, ...

      // verwendete Tabellen in dem Statement:
      for j := 0 to SqlParser.SqlStatements[i].Tables.Count - 1 do
      ...

      // neu formatiertes SQL (Die Formatierung lässt sich über diverse properties beeinflussen.)
      s := SqlParser.SqlStatements[i].PrettySql; 
      // unverändertes SQL
      s := SqlParser.SqlStatements[i].GetTextFromParseTree

      // Auf die einzelnen Bestandteile der eigentlichen SQL Statements, 
      // kann man natürlich mit bestimmten Properties analog zu oben auch zugreifen.
      // Es gibt auch die Möglichkeit auf den Lexxer und Syntaxbaum direkt zuzugreifen.
      // Damit ist dann alles möglich...
      ...
    end;
    ...
  end;
  ...
end;
...

Eine site Lizenz kostet nur 220 USD. Für das Geld bekomme ich es nicht selbst programmiert.
Wir haben es bestellt. Ich werde mal was zu meinen Erfahrungen schreiben, wenn ich das Projekt realisiert habe.

[alzaimar]

Meine Idee basierte darauf, den Syntaxcheck (ich dachte, darum geht es) vom Server durchführen zu lassen. Sofern es keine kompletten Schemas sind, sondern nur Batches, kannst du das ja in ein 'CREATE PROCEDURE FOO' einbetten und schauen, ob der Server diese SP anlegt. Wenn ja, ist der Code ok, wenn nicht, dann eben nicht. Das wäre die billige Möglichkeit. Du benötigst aber offenbar den Syntax-Baum (is ja auch logisch, sonst bräuchtest Du keinen echten Parser).

Hier sind übrigens Yacc-sourcen für MySQL:
http://dev.personnelware.com/carl/sqlparser/

Zitat:

Zitat von MaBuSE

...hoffe, das der eigentliche Code nicht so katastrophal programmiert ist.

Wenn das auf YACC basiert, *IST* der Code katastrophal, denn er wurde ja von einem Compilergenerator geschrieben. :stupid:

Im Ernst, bei YACC ist das ein Standardcode, der von verdammt großen Tabellen (bei Lexer ein NDEA, bei Yacc .. vergessen, riesige Tabellen halt :mrgreen: ) gefüttert wird (in den Tabellen steht eben die Syntax).

Was andere Compilergeneratoren mittlerweile so produzieren, weiss ich nicht. Bei einfachen Sprachen könnte man glatt reinen Quellcode ausspucken...

Schade, das man von denen offenbar die Y-Dateien nicht bekommt...

[MaBuSE]

Zitat:

Zitat von alzaimar

Schade, das man von denen offenbar die Y-Dateien nicht bekommt...

Wenn man den Quellcode kauft schon. ( hoffe ich ;-) )

Zitat:

General SQL Parser VCL version
...
Site License + 1 year subscription US$219.95
...
Additional Source code: Contact Us

Wenn das alles so funktioniert wie wir wollen und wir das Produkt produktiv einsetzen, werden wir auch den Quelltext kaufen.
Dann kann ich Dir sagen was es kostet und ob die *.l und *.y Datenen enthalten sind.