[Tustep-Liste] SQL in Tustep

[Johannes Leicht]

Liebe Tustepler,

vor einiger Zeit hatte Herr Giaccomazi in seiner der "Quo vadis"-Mail 
angeregt, innerhalb von Tustep Schnittstellen zu schaffen, mit denen 
andere Programme, z.B. Scriptsprachen o.ä. eingebunden werden können. 
Die Diskussion um diesen Wunsch, dem ich mich nur anschließen konnte und 
kann, ist zu meinem Bedauern inzwischen wohl eingeschlafen.
Dennoch ist in der neuen Tustep-Version ein sehr erfreulicher Schritt in 
diese Richtung gemacht worden: Wie bestimmt nicht nur ich festgetellt 
habe kann man mit der Kommandomakro-Funktion REQUEST eine HTML-Seite 
oder ein CGI-Script aufrufen. Wie das recht bequem nutzbar gemacht 
werden kann, möchte ich hier kurz vorstellen.

Bei einem meiner aktuellen Projekte befindet sich ein großer Teil der 
Daten in einer SQL-Datenbank. Um sie in meine restlichen Daten 
einzuarbeiten hatte ich sie zunächst in eine Datei geschrieben, nach 
Tustep importiert und dann auf herkömmliche Art und Weise 
weiterverarbeitet. Da ich jedoch sehr gerne auch die m.E. nur schwer 
leugbaren Stärken von SQL-Abfragen, indizierter Suche usw. nutzen 
wollte, suchte ich nach einer Möglichkeit, solche Abfragen in Tustep zu 
verarbeiten und stieß dabei auf REQUEST. Damit sind Zugriffe auf einen 
Webserver möglich, und über diesen - z.B. verwaltet durch ein PHP-Script 
- auch auf eine SQL-Datenbank.
Da es natürlich ein wenig umständlich wäre, extra einen Apache + MySQL + 
PHP zu installieren, habe ich mir einen kleinen Server gebastelt, der 
(ohne jegliche Installation) lokal (127.0.0.1) ausgeführt wird, an Port 
80 lauscht und ankommende SQL-Queries an eine SQLite-Datenbank 
weiterleitet. Auf diesen Server kann mittels REQUEST zugegriffen werden. 
Zusätzlich habe ich in Tustep ein paar Submakros geschrieben, die den 
Zugriff auf diesen Server vereinfachen.

Sobald der Server läuft ist ein recht komfortabler Zugriff auf die 
SQLite-Datenbank möglich:

01: $$!
02: $$=- {}
03: MODE VARIABLE
04:
05: INCLUDE sql
06:
07: SET result = ""
08: SET status = ""
09: SET request = ""
10:
11: CALL SQL_OPEN_DB("db_test.db", status)
12:
13: CALL SQL_UPDATE("CREATE TABLE emp (id int, name CHAR(20));", result, 
status)
14:
15: LOOP x = 1, 100
16:    SET request = "{request}INSERT INTO emp VALUES ({x}, 'test{x}');"
17: ENDLOOP
18:
19: CALL SQL_UPDATE(request, result, status)
20:
21: CALL SQL_QUERY("SELECT * FROM emp", result, status)
22:
23: LOOP x = result
24: + {x}
25: ENDLOOP
26:
27: CALL SQL_CLOSE_DB(status)

Erläuterung:
05: SQL-Makrosegment einbinden
11: Datenbank öffnen/anlegen
13: neue Tabelle erstellen
15-17: mehrere INSERT-Statements aneinanderkleben, damit nicht für jedes 
INSERT ein Zugriff nötig ist.
19: INSERT-Statements ausführen
21: Tabelle auslesen
23-25: Tabelle anzeigen
27: Datenbank schließen


Soweit so gut. Leider hat diese Methode den Nachteil, daß ein Zugriff 
auf die Datenbank nicht allzu schnell ist (bei mir ca. 0,5s - 1s), da 
bei jedem Zugiff eine neue Verbindung aufgebaut werden muß. Es ist also 
zwar gut möglich, größere Datenmengen auf einmal abzurufen und in einer 
Sternvariablen weiterzuverarbeiten, sobald man jedoch mehr als nur eine 
Handvoll Zugriffe benötigt, wird die Zugriffszeit empfindlich bemerkbar.

Deshalb würde ich es sehr begrüßen, wenn Schnittstellen wie REQUEST 
weiter entwickelt werden könnten. Ich vermute, daß z.B. durch 
persistente Verbindungen, die nicht nach jedem REQUEST getrennt werden, 
die Zugriffsgeschwindigkeit deutlich erhöht würde.

Und vielleicht läßt sich ja dieses Server-Modell, das zumindest für die 
SQL-Datenbank gut funktioniert, so ausbauen, daß auch die von Herrn 
Giaccomazi erwähnten Skriptsprachen eingebunden werden können.

Falls übrigens jemand gerne meine SQL-Lösung ausprobieren möchte, 
schicke ich ihm gerne den Server und das dazugehörende Makrosegment zu. 
Der Server ist in C++ (wxWidgets) geschrieben und für Windows 
kompiliert. Er ist momentan noch eine typische quick-and-dirty-Lösung, 
die in erster Linie das beherrscht, was ich für mein Projekt benötige. 
Ich habe ihn auch noch nicht allzu intensiv getestet, aber falls 
Interesse besteht und Anregungen kommen, werde ich ihn gerne 
weiterentwickeln.

Viele Grüße

Johannes Leicht