Arbeitsweise von dbServ

dbServ

Die Arbeitsweise von dbServ

Arbeitsweise für die Ein- und Ausgabe
Spezialitäten mit SQL-Statements
Stored Procedures
Transaktionen
Der Counter-Mechanismus
Der Cache

Ein- / Ausgabe

dbServ nutzt die Funktionalität des HTTP-Protokolls, Datensätze zusammen zu binden und als Parameter einem Aufruf zu übergeben. Wenn in einem FORM z. B. zwei Felder gefüllt sind, werden sie an den ACTION-Parameter des Forms angehängt. Dies wirkt auch bei dbServ.

Um die empfangenen Parameter auszuwerten, werden von dbServ Templates benutzt, die entsprechend zusammengestellt sein müssen (zu den benötigten Parametern siehe Dokumentation). Ein Template besteht immer aus einer SQL-Anweisung und aus einem Datenteil im Body des Templates, in dem die gefunden Werte ausgegeben werden. Dazu gibt es zwei Methoden der Eingabe:

OUT - Methode
IN - Methode

Die OUT-Methode

Wenn es folgende Anweisung gibt

     select id_, name_ from adr
     order by 2

benötigt man im Datenteil für die Felder eine Entsprechnung:

     <LI>id_ = ##1## name_ = ##2##

Es wird in der Reihenfolge der Definition ausgegeben. Alternativ kann auch der Feldname angegeben werden.

     <LI>id = ##id_## name = ##name_##

Wird nun die Suche von einem FORM-Window aufgerufen in dem ein Feld gefüllt ist, könnte die Übergabe so aussehen:

     out?template=adr/suchlist.shtml&name_=Fischer

Daraus wird für das Template 'suchlist.shtml' der SQL-Befehl um die Parameter ergänzt:

     select id_, name_ from adr
     where name_ like 'Fischer'
     order by 2

Die IN-Methode

Bei Insert, Update, Delete und machmal auch bei Select-Anweisungen ist es sinnvoll, die Parameterliste der Übergabe direkt in das Statement einzubauen.

Dazu ein Beispiel:

     update adr
     set name_ = ##name##
     where id_ = ##id##

Damit die Methoden auseinandergehalten werden können, wird diese als 'in' gekennzeichnet:

     in?template=adr/suchlist.shtml&name=Fischer&id=3

In Select-Anweisungen arbeitet diese Methode gut in UNION-Statements.

Spezialitäten mit SQL-Statements

Wie im ersten Beispiel zu sehen ist, würden bei diese Abfrage nur die Einträge gefunden werden, die genau der Anforderung entsprechen, nicht aber z.B. eine 'Fischer GmbH'.

Um dieses Problem aufzufangen, gibt es die Möglichkeit, im FORM-Window die Suche näher zu bestimmen. Der Eintrag

     <INPUT TYPE="text" NAME="name_[%]"  size=30>

generiert das Statement

     select id_, name_ from adr
     where name_ like 'Fischer%'
     order by 2

Erst eine Verwendung von

     <INPUT TYPE="text" NAME="name_[%%]"  size=30>

und die entsprechende SQL-Anweisung

     select id_, name_ from adr
     where name_ like '%Fischer%'
     order by 2

findet auch Einträge wie z.B. 'Axel Fischer GmbH'.

Übergabe von Werten

Mit einigen Datenbanken gibt es Probleme bei der Übergabe von Eingaben, deshalb können diese genauer festgelegt werden. Wenn zum Beispiel ein Text über 2000 Zeichen in ein langes Textfeld übergeben werden soll, können die Daten als ASCII-Stream gekennzeichnet werden. Ein weiteres Problem ist die Übergabe numerischer Werte. Um die Übergabe als Textfeld zu erzwingen, kann dieses definiert werden.

ein Beispiel:

 update adr 
	set long_ = ##text_,a##, 
	    plz_ = ##plz_,c##
 where id_ = ##id_##

Es sind keine Leerzeichen erlaubt.

Stored Procedures

Bisher waren die SQL-Anweisungen so formuliert, wie es die jeweilige Datenbank benötigt. Auch der Aufruf von Funktionen wird entsprechend gehandhabt (Z.B. liefert sysdate, now(), date() je nach DB das Datum zurück). Etwas anderes ist es mit Stored Procedures. Um die Flexibilität bei der Benutzung der Datenbank zu erhalten, wird hierbei mit der allgemeinen Java-Funktionalität gearbeitet. Ein Beispiel:

<dbcall>
call myschema.my_proc( ##test##, ##4,o##, ##12,o##)
</dbcall>

ruft eine Prozedur 'my_proc' auf, übergibt den Wert von 'test' und erhält einen numerischen und einen String-Wert zurück. (Die numerischen Definitionen ergeben sich aus der Java-Typdefinition.) Der numerische Rückgabewert muß '0' sein, wenn kein Fehler vorliegt. Der String-Wert entspricht einer Fehlermeldung. Eine Beispielprozedur dazu:

procedure my_proc (
	test    in  varchar,
	errorn  out number,
	errort  out varchar
) begin

errorn = 0;
errort = 'Ok';

update adr
    set text = 'test';
	
exception
   errorn = -1;
   errort = 'Fehler';
   
end

Wird ein Wert ungleich '0' zurückgegeben, wird der Fehlertext ausgegeben, sonst der Wert innerhalb von <dbdata>. Sollte ein Fehler außerhalb der Stored Procedure vorliegen, wird der Alternativtext von <dbdata txt="..."> angezeigt.

Prozeduren in SQL-Anweisungen werden behandelt wie bisher.

Transaktionen

Um Anfragen und Eingaben von bestimmten Rechnern zu ermöglichen wurde eine Transaktionsnummer dbtan eingeführt. Sie muß zu Beginn einmal initialisiert werden und dann durch alle Scripte weitergegeben werden. Die Gültigkeitsdauer kann über die Ini-Datei festgelegt werden.

Der Count-Mechanismus

In dbServ ist ein einfacher Counter integriert. Dafür ist es notwendig, eine Datenbank mit dem Namen 'count' zu installierten (Beschreibung siehe Verzeichnis db). Um einen Eintrag in die Tabelle zu erzeugen gibt es zwei Möglichkeiten:

der Aufruf über ein Image:

    <IMG SRC="http://localhost:4444/count?index" WIDTH="1" HEIGHT="1">

Hinter 'count?' steht ein beliebiger Text, der in der Tabelle abgelegt wird. Als Rückgabe erscheint ein hintergrundloses Image.

der Aufruf über einen Link:

    <A HREF="http://localhost:4444/count?target=http://newhost/index.html"
    target="_new">new Location</A>

Es muß hinter 'count?' ein Ziel für die Umlenkung angegeben werden. Dieser Link wird auch in der Datenbank gespeichert.

Für die Counter-Benutzung sind einige Einstellungen in dbServ.ini zu beachten.

Der Cache

Um die Performanz anzuheben können die Seiten, die über die 'OUT'-Methode generiert werden, auch aus dem Speicher zurückgegeben werden. Dazu muß die Seite einmal aufgerufen worden sein. Über eine Varible kann die Cachezeit festgelegt werden. Außerdem kann eine Seite von diesem Mechanismus ausschlossen werden, wenn ein Tag 'nocache' definiert ist.

Axel Fischer, afischer@dbServ.de

home