Abfragecode und Ausdrücke

Abfragen werden als Simplified Query Definition SQD verwaltet und nicht als Structured Query Language SQL-Kommando. Die Gründe hierfür sind:

1. ASYS wurde entworfen als ein datenbankgestütztes konfigurierbares System, welches ursprünglich mit einer ganzen Reihe unterschiedlicher Datenbanken (Oracle, Informix, Ingres, MS-SQL-Server, Access, DB2) anpassungsfrei umgehen können sollte. Hierzu wurde eine von Besonderheiten der SQL-Dialekte der verschiedenen Datenbanken abstrahierte Abfragenotation - SQD - eingeführt. Erst zur Laufzeit werden so Datenbankspezifika - z.B. die Datumsnotation - entsprechend der tatsächlich genutzten Datenbank umgesetzt.
2. Die Abfragen arbeiten - anders als SQL - nicht mit physischen Datenbanknamen für Tabellen, Views und ihre Attribute, sondern mit den ASYS-Fachobjektemodellnamen, die Bestandteil des Repositorys sind und auch in Prüfregeln und Maskendefinitionen genutzt werden. Die Namen des Fachobjektemodells werden als Platzhalter geschrieben und zur Laufzeit durch physische Datenbanknamen bzw. die Werte aus einem Datensatz ersetzt. Auch dieser Mechanismus dient der Abstrahierung von einer konkreten Datenbank¹⁾.

Das folgende Beispiel zeigt einen SQD, der eine Auswertung erstellt, die die Abfallmengen aus Begleitscheinen eines bestimmten Erzeugers, in einem bestimmten Zeitraum summiert je Kombination aus Entsorgungsnachweis- und Entsorgernummer enthält.

 COMMENT: Begleitscheinmengen gruppiert und summiert nach EN-Nummer und Entsorgernummer, für ein bestimmtes Jahr und einen Erzeuger;
 
 NAME: BGS Erzeuger Jahresmenge;
 
 MODEL: AsysProto;
 
 CLASSES: 
 BGS UNS=BGS;
 BGS UNS.Rolle Erzeuger=Erz;
 BGS UNS.Rolle Entsorger=Ent;
 \
 
 RESULTS:
 *Abfallmenge=sum({%BGS.Menge In Tonnen%});
 $ENNummern={%BGS.EN Nummer%};
 $Entsorgernummer={%Ent.Behoerdliche Nummer%};
 $LetztesAnnahmedatum=last({%Ent.Datum 1%});
 \
 
 CONDITIONS:
 {%Erz.Behoerdliche Nummer%} = '{*BTRNr*}';
 #{%Ent.Datum 1%} ge {*MyDate1*}#;
 #{%Ent.Datum 1%} le {*MyDate2*}#;
 \
 
 GROUP:
 {%BGS.EN Nummer%}, {%Ent.Behoerdliche Nummer%};
 \
 
 ORDER:
 last({%Ent.Datum 1%}) DESC;
 \

Die einzelnen Abschnitte haben folgende Bedeutung:

Der Abschnitt CLASSES umfasst die Tabellen (oder Views), aus denen in den Abschnitten RESULTS, CONDITIONS, GROUP oder ORDER Attribute verwendet werden sollen. Da i.d.R. nicht 'wahllos' Daten aus verschiedenen Tabellen in eine Auswertung einfließen sollen, sondern z.B. die Anfallstellen eines bestimmten Erzeugers benötigt werden, müssen die Beziehungen zwischen den Tabellen angegeben werden. Die Beziehung der Tabellen wird durch die Punktnotation dargestellt. Im SQL entstehen daraus WHERE-Klauseln, die die Datensätze der verwendeten Tabellen über die Datensatz-ID verknüpfen oder JOIN-Ausdrücke im FROM-Abschnitt des SQL²⁾. Man kann diese Beziehungsdefinitionen auch als Pfade bezeichnen. Einem solchen Pfad wird ein Alias-Name zugewiesen (optional aber dringend empfohlen), über den er verwendet werden kann.

Es können natürlich nur solche Beziehungen verwendet werden, die im Datenmodell tatsächlich definiert sind.

Beispiele:

CLASSES

BGS UNS=Bgs
BGS UNS.Fehlerprotokoll BGS=Feh

Hier wird die Tabelle BGS UNS benötigt und erhält den Alias-Namen Bgs. Der Name der Tabelle muss exakt dem Modellnamen im ASYS-Datenmodell entsprechen. Andere Schreibweisen für den Tabellennamen z.B. bgs uns, BGSUNS, BGS-UNS, Bgs Uns etc. würden dazu führen, dass die Tabelle nicht gefunden wird. Gleiches gilt für die Schreibweise des Alias-Namens: Die hier im Classes-Abschnitt verwendete Schreibweise muss auch in den nachfolgenden Abschnitten des SQD exakt eingehalten werden!
Die zweite Zeile beschreibt die Beziehung zur Tabelle Fehlerprotokoll BGS. Auf der Basis dieser Classes-Definition könnten z.B. BGS gesucht werden, die bestimmte Fehler aufweisen.

CLASSES

BGS UNS=BGS
BGS UNS.Rolle Erzeuger=Erz
BGS UNS.Rolle Entsorger=Ent

Eine solche Definition ist erforderlich, wenn zu einem Begleitschein Daten aus der Tabelle der Abfalltransportbeteiligten (Tabellenname: Abfalltransportbeteiligter) benötigt werden. Die Tabelle der Abfalltransportbeteiligten 'hängt' an der Tabelle der Begleitscheine. Zu jedem Begleitschein können bis zu sechs Datensätze in der Tabelle der Abfalltransportbeteiligten stehen (für jeden Beteiligten [Erzeuger, Beförderer, Entsorger, 2. Beförderer, 3. Beförderer und Umschlag/Lagerung] ein Datensatz). Für die korrekte Zuordnung der Beteiligten zu einem BGS erfolgt der Zugriff nicht direkt auf die Tabelle der Abfalltransportbeteiligten, sondern über Views, die die Beteiligten anhand von internen Rollen auseinanderhalten. Diese Views haben wie Tabellen Namen.
Soll also z.B. der Name eines Erzeugers aus einem BGS verwendet werden, würde die Definition BGS UNS.Abfalltransportbeteiligter=Erz; NICHT ausreichen. Es muss wie im obigen Beispiel der Name der View (hier: Rolle Erzeuger) verwendet werden (analog Rolle Entsorger, Rolle Befoerderer, Rolle Befoerderer 2 etc.).

CLASSES

Rolle Vorgang EN=Dbl
Rolle Vorgang EN.Entsorgungsnachweis=EN
Rolle Vorgang EN.Entsorgungsnachweis.Verantwortliche Erklaerung=VE

Auch für die verschiedenen Arten von Nachweisen gilt, dass die Tabelle Vorgang Deckblatt nicht direkt angesprochen werden kann, sondern dass - sobald Daten aus abhängigen Tabellen benötigt werden - die View (hier: Rolle Vorgang EN) verwendet werden muss. Die dritte Zeile dieser Classes-Definition legt fest, dass ausgehend von einem bestimmten Datensatz in der Tabelle (View!) Rolle Vorgang EN, der zugehörige Datensatz der Tabelle Entsorgungsnachweis und von diesem ausgehend die zugehörige Verantwortliche Erklaerung verwendet werden soll. Wird also eine bestimmte EN-Nummer als Bedingung übergeben, könnte der Inhalt des Feldes 'Betriebsinterne Bezeichnung' aus der VE dieses EN als Resultat verwendet werden.

CLASSES

FKB=FKB
FKB.Rolle Betrieb Erz=Btr
FKB.Rolle Betrieb Erz.Erzeuger=Erz

CLASSES

Rolle Betrieb Erz.FKB=FKB
Rolle Betrieb Erz=Btr
Rolle Betrieb Erz.Erzeuger=Erz

Die Stammdaten bestehen aus Betrieben einer FKB. Die Attribute der Betriebe, die in allen Betrieben gleich sind (z.B. Telefon, Fax) befinden sich in der Tabelle Betrieb. Die speziellen Attribute (z.B. Sekundärerzeuger bei Erzeugern, Entsorgungsfachbetrieb bei Entsorgern etc.) befinden sich in den Tabellen für die unterschiedlichen Betriebsarten (Tabelle Erzeuger, Tabelle Entsorger etc.). Die Daten in der Tabelle Betrieb können deshalb - sobald Attribute aus abhängigen Tabellen verwendet werden sollen - ebenfalls nur über die Views angesprochen werden (hier: Rolle Betrieb Erz).

Für die Ausführung der Abfrage ist es irrelevant, aus welcher Richtung der Klassenbaum aufgebaut wird (von der FKB ausgehend oder von der Rolle Betrieb Erz ausgehend). Beide oben aufgeführten Beispiele führen zum gleichen Ergebnis.

Herkömmliche Abfragen sind immer als Inner-Join-Ausdrücke formuliert. Darunter ist zu verstehen, dass nur Datensätze in die Auswahl kommen, die in allen in der Abfrage miteinander verknüpften Tabellen einen oder mehrere Datensätze enthalten³⁾.

Im nachfolgenden Beispiel ist eine Abfrage definiert, bei der für Erzeuger auch Ansprechpartner und Anfallstellen ermittelt werden. Durch die Inner-Join-Logik werden auf diese Weise alle Erzeuger implizit ausgefiltert, die entweder keinen Ansprechpartner, oder keine Anfallstelle oder weder das eine noch das andere besitzen! Diese implizite Filterung erfolgt auch für diejenigen Datensätze, die durch die Filterausdrücke im CONDITIONS-Abschnitt eigentlich in die Ergebnismenge mit aufgenommen würden.

CLASSES

Rolle Betrieb Erz=Btr
Rolle Betrieb Erz.Betrieb.Betrieb Zu Anspr=Bza
Rolle Betrieb Erz.Betrieb.Betrieb Zu Anspr.Ansprechpartner=Ans
Rolle Betrieb Erz.Erzeuger=Erz
Rolle Betrieb Erz.Erzeuger.Anfallstelle=Anf

Das Ergebnis wird also maßgeblich mitbestimmt von der Auswahl und Verknüpfung der Tabellen, die für die Abfrage miteinander verbunden werden.

In ASYS V6.x werden die Beziehungen der Tabellen untereinander nicht - wie bislang generell in ASYS üblich - über automatisch generierte WHERE-Bedingungen im SQL-Kommando abgebildet, sondern statt dessen über JOIN-Ausdrücke im FROM-Abschnitt⁴⁾ des SQL-Kommandos. Hierüber ist es auch möglich, dass Outer-Join-Ausdrücke definiert werden können. Outer-Join bedeutet, dass die verknüpfte Tabelle für einen konkreten Datensatz auch leer sein kann.

Sollen also gemäß vorstehendem Beispiel auch diejenigen Erzeuger im Ergebnis erscheinen, die keinen Ansprechpartner oder keine Anfallstelle enthalten (aber davon unabhängig den übrigen Bedingungen in CONDITIONS gehorchen), so müssen die beiden betreffenden Tochtertabellen mittels Outer-Join verknüpft werden. Dies ist im nachfolgenden Beispiel illustriert:

CLASSES

Rolle Betrieb Erz=Btr
Rolle Betrieb Erz.Betrieb.Betrieb Zu Anspr=Bza*
Rolle Betrieb Erz.Betrieb.Betrieb Zu Anspr.Ansprechpartner=Ans
Rolle Betrieb Erz.Erzeuger=Erz
Rolle Betrieb Erz.Erzeuger.Anfallstelle=Anf*

Als Outer-Joins sind die Tabellen Betrieb Zu Anspr und Anfallstelle mittels * hinter dem Klassen-Alias gekennzeichnet. Alle anderen Verknüpfungen zwischen den Tabellen sind weiterhin Inner-Joins.

Der Outer-Join für die Ansprechpartner wurde nicht bei der Tabelle selbst sondern bei Betrieb Zu Anspr gelegt, weil jeder Ansprechpartner eines Betriebs immer einen Datensatz in Betrieb Zu Anspr besitzt (1-zu-1-Beziehung). Jeder Betrieb mit Ansprechpartnern enthält für jeden Ansprechpartner je einen Datensatz in Betrieb Zu Anspr. Ein Betrieb ohne Ansprechpartner besitzt folglich keinen zugeordneten Datensatz in Betrieb Zu Anspr, daher muss die Outer-Join-Kennzeichnung an dieser Tabelle erfolgen. Anders herum ist eine Outer-Join-Kennzeichnung an der Tabelle Ansprechparter funktionslos, da es zu jedem Datensatz in Betrieb Zu Anspr immer einen Datensatz in Ansprechpartner gibt.

Mit dem Beispiel der Tabellen Betrieb Zu Anspr und Ansprechpartner wird zugleich verdeutlicht, dass eine per Outer-Join verknüpfte Tabelle nicht notwendigerweise ein Endpunkt im Verküpfungsbaum der Tabellen einer Abfrage sein muss. Die Tabellen Betrieb Zu Anspr und Ansprechpartner sind untereinander mittels Inner-Join verknüpft. Dies ist immer dann sinnvoll, wenn mittels Outer-Join verknüpfte abhängige Unterstrukturen (z.B. per Outer-Join mit Entsorger verknüpfte Teilanlagen mit zugelassenen Abfallschlüsseln und 4.BImSchV-Nummern) nur dann selektiert werden sollen, wenn diese Unterstrukturen in sich vollständig vorhanden sind.

Outer-Joins können auch über mehrere aufeinanderfolgende Verknüpfungsebenen festgelegt werden. Werden der Entsorger und seine Teilanlagen sowie die Teilanlage und ihre Abfallschlüssel jeweils mittels Outer-Join verknüpft, so ermittelt die Abfrage auch alle Entsorger ohne Teilanlagen und alle Entsorger mit Teilanlagen mit und ohne Abfallschlüssel die den übrigen Bedingungen in CONDITIONS genügen.

CLASSES

Rolle Betrieb Ent=Btr
Rolle Betrieb Ent.Entsorger=Ent
Rolle Betrieb Ent.Entsorger.Teilanlage=Tla*
Rolle Betrieb Ent.Entsorger.Teilanlage.Abfall TA=Ata*
Rolle Betrieb Ent.Entsorger.Teilanlage.Teilanlage BImSchV=Tbv*
Rolle Betrieb Ent.Entsorger.Teilanlage.Teilanlage BImSchV.LEA Kat 4BImSchV=Kbv
  

Die vorstehenden Aussagen gelten nur unter der Voraussetzung, dass im CONDITIONS-Abschnitt keine Bedingungen enthalten sind, die sich auf Attribute aus einer der per Outer-Join angebundenen Tabellen beziehen (also in den obigen Beispielen keine Bedingung zu einem Ansprechpartner, einer Anfallstelle, einer Teilanlage, einem Abfallschlüssel einer Teilanlage oder einer 4.BImSchV-Nummer einer Teilanlage). Werden derartige Bedingungen gestellt, so ist davon auszugehen, dass die Betriebe ohne Datensätze in den Tabellen, auf die sich die Bedingungen beziehen, ausgefiltert werden, da ja nicht vorhandene Datensätze die Bedingungen nicht erfüllen!

Der Abschnitt RESULTS gibt an, welche Ergebnisse von der Abfrage zurückgeliefert werden sollen. Hierbei handelt es sich entweder um bestimmte Attribute oder um Attribute, auf die zusätzliche Aggregatfunktionen (Summe, Mittelwert, etc.) oder andere Funktionen (Distinct, Last etc.) angewendet werden sollen. Die notwendigen Alias-Namen sind sozusagen die Überschriften der Spalten in der Ergebnistabelle.

Beispiele:

RESULTS

Erz.Name 1=NAME
Erz.Name 2=ZUSATZ
Erz.Postleitzahl Str=PLZ
Erz.Ort Str 1=ORT

Dieses Beispiel zeigt eine RESULTS-Definition, die keine Funktionen verwendet. Jeder Eintrag unter RESULTS muss mit dem Alias aus der CLASSES-Definition beginnen, gefolgt von einen Punkt und dem Namen des Attributes aus dem ASYS-Fachobjektemodell. Beides muss in seiner Schreibweise exakt stimmen. War der Alias in der CLASSES-Definition also ERZ wäre der Eintrag in diesem Beispiel (Erz) falsch. Ebenso wäre als Attributname Name1 (Leerzeichen fehlt) oder NAME 1 etc. falsch. Der Alias-Name für das Ergebnis kann frei gewählt werden, allerdings darf natürlich innerhalb eines SQD nicht zweimal der gleiche Name verwendet werden. Darüber hinaus ist darauf zu achten, dass kein Alias-Name Teil eines anderen Alias-Namens sein sollte, da es ansonsten zu Problem bei der Ausführung der Abfrage kommen kann (es sollte also darauf verzichtet werden z.B. 'Name1' und 'EZ_Name1' in einer Abfrage als Alias-Namen zu verwenden).

RESULTS

$NAME=distinct {%Erz.Name 1%}
Erz.Name 2=ZUSATZ
Erz.Postleitzahl Str=PLZ
Erz.Ort Str 1=ORT
*ANZAHL=count(*)

Im Unterschied zum obigen Beispiel wird hier die Funktion DISTINCT verwendet, die bewirkt, dass jeder Erzeuger nur einmal ausgegeben wird. Zusätzlich wird definiert, dass die Anzahl der Datensätze gleichen Namens als Anzahl ausgegeben werden soll (Funktion COUNT(*)). Wird im RESULTS-Abschnitt eine Funktion verwendet, muss

• der Alias-Name zuerst genannt werden,
• bei Zeichenketten ein $ und bei Zahlen ein * vor den Alias-Namen gesetzt werden und
• das Attribut in geschweifte Klammern und Prozentzeichen {% … %} gesetzt werden.

RESULTS

Erz.Name 1=NAME
$ZUSATZ={%Erz.Name 2%}

Dieses Beispiel zeigt die beiden alternativen Schreibweisen für RESULTS-Einträge ohne Funktionen. Immer, wenn der Alias-Name vorne steht (zweite Zeile) muss ein $ (bzw. bei Zahlen ein *) davor gestellt werden und das Attribut muss in {% … %} eingeschlossen werden. Die Schreibweise in der ersten Zeile ist jedoch einfacher und daher zu empfehlen.

Datentypen
Die Rückgabewerte können mit einem Datentyp versehen werden. Sinnvoll ist dies insbesondere für die Datentypen 'Memo' und 'double'.

Für die Angabe des Datentyps muss der Alias an erster Stelle (also links vom Gleichheitszeichen) stehen. Bitte achten Sie auf korrekte Groß- und Kleinschreibung des Datentyps.

Beispiele:

$Nebenbest/Memo={%Bb.Nebenbestimmungen%}
$Summe/double=sum({%BGS.Menge In Tonnen%})

Das $-Zeichen steht ansonsten (ohne Angabe des Datentyps) für den Rückgabewert 'Text' und das *-Zeichen für Zahlen ohne Nachkommastellen (Integer/Long).

Im Abschnitt CONDITIONS werden die Bedingungen für die Abfrage eingetragen. Die Bedingungen werden mit und (AND) verknüpft, wenn nicht explizit oder (OR) angegeben ist.

Zwei Beispiele:

CONDITIONS

{%EAK.EAK Schluessel%} = {*BGS UNS.Abfallschluessel*}
#${%EAK.Gueltig Von%} le {*Rolle Erzeuger.Datum 1*}#
#?${%EAK.Gueltig Bis%} ge {*Rolle Erzeuger.Datum 1*}#
{%EAK.FL gestrichen%} = #false#

CONDITIONS

{%BGS UNS.Abfallschluessel%} like '{*EAK Schluessel*}'
{%Erz.Name 1%} is not null

$MEIN_TEXT = 'Das gebe ich aus.'

{%RBeh.Bezeichnung%} = 'Entsorgerbehörde'

Die folgende Tabelle erläutert mögliche Einträge:

Weitere Beispiele:

CONDITIONS

{%Btr.Behoerdliche Nummer%} = {*Rolle Vorgang EN.Entsorgernummer*}
#${%FKB.Gueltig Von%} le {*Rolle Vorgang EN.Gueltig Von*}#
#?${%FKB.Gueltig Bis%} ge {*Rolle Vorgang EN.Gueltig Von*}#
{%RBeh.Bezeichnung%} = 'Entsorgerbehörde'

Hier wird in der letzten Zeile eine konkrete Zeichenkette als Bedingung abgefragt. Die Bezeichnung der Rolle der zuständigen Behörde soll Entsorgerbehörde sein.

CONDITIONS

{%VGB.Vorgangsnummer%} = '{*ENNummer*}'
{%VGB.Entsorgernummer%} = '{*Entsorgernummer*}'
#{%EN.Gueltig Von%} = {*Datum*}#

Hier wird in der letzten Zeile ein Datum als Variable festgelegt. Wird diese Abfrage aufgerufen, müssen die Anwender eine ENNummer, eine Entsorgernummer und ein Datum eingeben. Da es sich nicht um eine Regelabfrage handelt, darf nach dem # kein $ folgen.

CONDITIONS

{%VGB.Vorgangsnummer%} = {*BGS UNS.EN Nummer*}
#${%VGB.Gueltig Von%} le {*Rolle Entsorger.Datum 1*}#
#?${%VGB.Gueltig Bis%} ge {*Rolle Entsorger.Datum 1*}#
((#${%EN.Gueltig Von%} le {*Rolle Entsorger.Datum 1*}# AND #${%EN.Gueltig Bis%} ge {*Rolle Entsorger.Datum 1*}#) OR (#{%EB.Datum Versand%}+30t <= {*Rolle Entsorger.Datum 1*}#))

Die letzte Zeile zeigt das Setzen von Klammern und die Verwendung von oder (OR). Grundsätzlich werden alle Zeilen im CONDITIONS-Abschnitt gleichberechtigt mit UND (AND) verknüpft. Hier sollen jedoch als Bedingung in einer Regelabfrage nur solche Treffer ermittelt werden, bei denen das Datum der Annahme (Rolle Entsorger.Datum 1) entweder größer als das Gültig Von und kleiner als das Gültig Bis des EN ist oder das Annahmedatum soll größer als das Versanddatum der Eingangsbestätigung plus 30 Tage sein (verfristeter EN).

Der Abschnitt GROUP beinhaltet die Vorgaben für die Gruppierung, um z.B. Summierungen nach bestimmten Kriterien vornehmen zu können. Die einzelnen Attribute werden, wenn mehrere verwendet werden sollen, in der Reihenfolge aufgeführt, die der gewünschten Gruppierung entspricht. Gruppierbedingungen werden nur in eine Zeile geschrieben. Mehrere Gruppierbedingungen sind hierbei durch ein Komma zu trennen. Die Attribute der Gruppierung müssen als Resultate im RESULTS-Abschnitt definiert sein.

GROUP

{%BGS.EN Nummer%}, {%Ent.Behoerdliche Nummer%}

Sollen die Ergebnisse in einer bestimmten Reihenfolge ausgegeben werden, kann der ORDER-Abschnitt verwendet werden. Wie bei GROUP werden die Attribute nur in eine Zeile entsprechend der gewünschten Sortierreihenfolge geschrieben und müssen im RESULTS-Abschnitt enthalten sein. Standardsortierung ist aufsteigend, mit dem Zusatz DESC kann eine absteigende Sortierreihenfolge erreicht werden.

ORDER

{%BGS.EN Nummer%}, last({%Ent.Datum 1%}) DESC

SKRIPTS erlauben es, auf den in den RESULTS ermittelten Spalten und Werten (Rechen)Operationen auszuführen, die weiteren Ergebnisspalten liefern.

Angegeben wird im SKRIPTS-Abschnitt der Name der Ergebnisspalte (hier ERGEBNIS) und hinter dem Gleichheitszeichen die auszuführende Anweisung. Wie bei den RESULTS darf der Name keine Leer- oder Sonderzeichen enthalten. Das folgende Beispiel addiert die beiden Ergebnisspalten MengeA und MengeB.

RESULTS

VE.Erzeugernummer=Erzeugernr
$MengeA/double={%VE.Menge Jahr 1%}
$MengeB/double={%VE.Menge Jahr 2%}

SCRIPTS

ERGEBNIS/double=dc.getDoubleValue("MengeA") + dc.getDoubleValue("MengeB")

Hinter dem Namen der Ergebnisspalte muss mit / getrennt der Typ angegeben werden. Wird kein Typ angegeben, wird String (Zeichenkette) verwendet. Weitere Typen neben double (Fließkommazahl) sind int (Ganzzahl) und date (Datum).

Unter RESULTS sollte ebenfalls der Typ mit angegeben werden, zumindest bei double und bei date.

Um die Resultate verwenden zu können, muss jeweils die Methode dc.get…Value(„…“) verwendet werden (dc.getDoubleValue, dc.getIntValue, dc.getMemoValue, dc.getStringValue).

Es können auch mehrere SKRIPTS in einer Abfrage verwendet werden. In diesem Fall wird jedes Skript eine Zeile geschrieben.

SKRIPTS

ERGEBNIS1/double= dc.getDoubleValue("MengeA") + dc.getDoubleValue("MengeB")
ERGEBNIS2/double= dc.getDoubleValue("MengeA") - dc.getDoubleValue("MengeB")

Die Anweisungen, die in einem SKRIPTS-Abschnitt verwendet werden, werden wie Prüfregeln, also in Java definiert. Statt der Variablen in der {% … %}-Notation wird die o.g. dc.get…-Notation verwendet.

Verwendung zum Auslesen von Memofeldern

Memofelder werden in Asys in speziellen Tabellen gespeichert. Bei Auslesen innerhalb einer Abfrage erhält man daher zunächst nur die ID, die auf den Eintrag in den speziellen Memotabellen verweist. Diese ID kann über eine SKRIPTS-Anweisung in den eigentlichen Memo-Text umgewandelt werden.

RESULTS

Btr.Behoerdliche Nummer=Befoerderernr
Btr.Bemerkungen=MemoIDNotizen

SKRIPTS

Notizen=dc.getMemoValue("MemoIDNotizen")

Btr.Behoerdliche Nummer=Befoerderernr
$MemoIDNotizen/Memo={%Btr.Bemerkungen%}

Der folgende SQD zeigt ein weiteres Beispiel für SKRIPTS, hier wird das Feld Rolle interpretiert und die Nachweisart mit den offiziellen Buchstaben ausgegeben. Zusätzlich wird das Bemerkungsfeld ausgegeben.

COMMENT: Hole alle Vorgänge (Nachweise) einer Firma, unabhängig von der Art des Vorgangs;

NAME:IKAVorgang;

MODEL: AsysProto;

CLASSES: 
Vorgang Deckblatt=VGB;
\

RESULTS:
VGB.Vorgangsnummer=Vorgangsnummer;
VGB.Name 1=Firmenname;
VGB.Rolle=Rolle;
VGB.Bemerkungen=BemerkungsID;
\

SCRIPTS:
Vorgangstyp = (dc.getIntValue("Rolle") == 1) ? "VS" : (dc.getIntValue("Rolle") == 2) ? "KO" : (dc.getIntValue("Rolle") == 3) ? "EN": (dc.getIntValue("Rolle") == 4) ? "FR" : (dc.getIntValue("Rolle") == 5) ? "AN": (dc.getIntValue("Rolle") == 6) ? "SN" : (dc.getIntValue("Rolle") == 7) ? "BI": (dc.getIntValue("Rolle") == 8) ? "VN" : "Sonstige";
\
Bemerkung=dc.getMemoValue("BemerkungsID");
\
\

CONDITIONS:
{%VGB.Name 1%} like '{*Firmenname*}';
{%VGB.Gueltig Bis%} is null;
{%VGB.Gueltig Von%} is not null;
\

Im Administrator für ASYS V6.x werden diese beiden Skript-Definitionen wie folgt eingetragen:

SKRIPTS

Vorgangstyp = (dc.getIntValue("Rolle") == 1) ? "VS" : (dc.getIntValue("Rolle") == 2) ? "KO" : (dc.getIntValue("Rolle") == 3) ? "EN": (dc.getIntValue("Rolle") == 4) ? "FR" : (dc.getIntValue("Rolle") == 5) ? "AN": (dc.getIntValue("Rolle") == 6) ? "SN" : (dc.getIntValue("Rolle") == 7) ? "BI": (dc.getIntValue("Rolle") == 8) ? "VN" : "Sonstige"
Bemerkung=dc.getMemoValue("BemerkungsID")

Das erste Skript nutzt eine IF-THEN-ELSE-Notation: Bedingungsausdruck ? Aktion falls Bedingung erfüllt : Aktion falls Bedingung nicht erfüllt. Dieser Ausdruck wird in diesem Beispiel mehrfach geschachtelt genutzt: Ein jeweils neuer Bedingungsausdruck befindet sich im Abschnitt Aktion falls Bedingung nicht erfüllt des vorhergehenden Bedingungsausdrucks bis alle Alternativen abgedeckt sind.

VARIABLES erlauben es, bei freien Abfragen (und seit Version 5.10 mit dem Attribut 'Value' auch für Regelabfragen) für vom Anwender auszufüllende Parameter des CONDITIONS-Bereich diverse Formatierungsanweisungen mitzugeben. Die Syntax für einzelne Formatierungsanweisungen lautet hierbei

<Parametername>.<Formatierungsanweisung>=<Wert>

Folgende Formatierungsanweisungen sind möglich:

Jede VARIABLES-Definition ist in eine Zeile zu schreiben.

Anbei ein Beispiel aus der Referenzinstallation der Version 5.5. Abfrage IKAE3Ref_ErzMitAbfall.

CONDITIONS

…
{%Bgs.Abfallschluessel%} = '{*Abfallschluessel*}'
#${%Bgs.Datum Eingang%} >= {*Eingangsdatum*}#
{%Btr.FL gestrichen%}={*Gestrichen*}

VARIABLES

Abfallschluessel.Default=010101
Abfallschluessel.Format=######
Abfallschluessel.SQD=IKAE3Ref_BGSAbfSchluessel
Abfallschluessel.Info=Bitte wählen Sie einen Abfallschlüssel aus
Abfallschluessel.RegExp=(01|02|03|19).*
Eingangsdatum.Default=01.01.1990
Eingangsdatum.Type=Date
Eingangsdatum.Info=Bitte geben Sie ein Datum ein oder wählen Sie eins aus
Gestrichen.Type=Boolean
Gestrichen.Default=0

Der Anwender hat nach Auswahl der Abfrage die Parameter Abfallschluessel, Eingangsdatum und Gestrichen zu füllen.

Für den Abfallschluessel sind hierbei folgende Angaben definiert:

• Als Default wird 010101 vorgeblendet.
• Der Abfallschluessel muss aus sechs Zahlen bestehen.
• Es wird über die Abfrage IKAE3Ref_BGSAbfSchluessel eine Auswahlliste für den Abfallschluessel gefüllt, die aus allen Abfallschlüsseln besteht, die in den Begleitscheinen der Datenbank vorkommen.
• Als Tooltip erscheint der eingetragene Text.
• Der ausgewählte/eingegebene Abfallschluessel muss mit 01, 02, 03 oder 19 beginnen.

Für das Eingangsdatum sind folgende Angaben definiert:

• Als Default wird der 01.01.1990 vorgeblendet.
• Es kann ein Datum aus einem Kalender ausgewählt werden.
• Als Tooltip erscheint der eingetragene Text.

Für den Parameter Gestrichen sind folgende Angaben definiert:

• Als Default wird die 0 (False) vorgeblendet.
• Der Parameter wird als Checkbox angezeigt. Nur True = 1 oder False = 0 sind als Werte möglich.

Anbei ein Beispiel für den .Value-Bereich:

CONDITIONS

{%Eak.EAK Schluessel%}={*BGS UNS.Abfallschluessel*}
{%Eak.FL gestrichen%}=#false#
{%Eak.FL Gefaehrlich%}=#true#
#${%Eak.Gueltig Von%} le {*PRUEF_DATE*}#
#?${%Eak.Gueltig Bis%} ge {*PRUEF_DATE*}#

VARIABLES

PRUEF_DATE.Value=firstDateNotNull(new Array(dc.getDateValue("Rolle Erzeuger.Datum 1"),dc.getDateValue("Rolle Befoerderer.Datum 1"),dc.getDateValue("Rolle Entsorger.Datum 1")));

Der ASYS-Funktion firstDateNotNull wird eine kommaseparierte Menge von Werten übergeben. Der erste Wert dieser Menge, der nicht NULL ist, wird zurückgegeben. In genanntem Beispiel wird dieser Wert dann in den Parameter PRUEF_DATE eingetragen. Ist also z.B. im konkreten Datensatz das Feld Rolle Erzeuger.Datum 1 NULL und im Feld Rolle Befoerderer.Datum 1 steht der 01.01.2011 wird der Parameter PRUEF_DATE durch den 01.01.2011 ersetzt.

Einige der hier stehenden Anmerkungen wurden ebenfalls bereits weiter oben ausgeführt:

• Bedingungen, die ein Datum enthalten: Bedingungen (CONDITIONS), die ein Datum enthalten, müssen in Gatter (# …#) gesetzt werden. Einzige Ausnahme ist die Abfrage auf 'is null', hier können die Gatter entfallen (z.B. {%FKB.Gueltig Bis%} is null;). Steht hinter dem ersten # ein ? (z.B. #?{%VGB.Gueltig Bis%} >= {*Rolle Befoerderer.Datum 1*}#;), wird die Bedingung im SQL zu x >= y or x is null automatisch erweitert.
• Soll mit dem aktuellen Datum verglichen werden, wird @heute verwendet (z.B. #{%FKB.Gueltig Von%} > @heute#).
• Es kann auch mit dem Datum gerechnet werden (z.B. #{%EB.Datum Versand%}+30t ⇐ {*Rolle Entsorger.Datum 1*}#, t für Tage, m für Monate und j für Jahre)
• Funktionen im RESULTS-Abschnitt: Werden im RESULTS-Abschnitt Funktionen verwendet, muss der Alias-Name vorne stehen, bei Integerwerten mit einem * beginnen (z.B. *trefferzahl=count(*);) und bei Strings mit einem $ (z.B. $Name=distinct {%Erz.Name 1%};).
• Der Alias-Name bei den CLASSES- und den RESULTS-Einträgen darf keine Leer- oder Sonderzeichen enthalten.
• Memo-Felder können direkt im RESULTS-Abschnitt angegeben werden. Sie müssen nicht über die SKRIPTS ermittelt werden.
• Im CONDITIONS-Abschnitt können auch die sc.-Funktionen verwendet werden. Sie müssen jedoch in Hochkomma gesetzt werden.
  Zur Abfrage des Loginnamens muss sc.userID() verwendet werden.

Für den Zugriff auf die ID-Felder einer Klasse ist eine spezielle Notation zu verwenden. Diese hängt davon ab, in welchem Abschnitt das ID-Feld verwendet wird.

RESULTS

[Klassenalias].=ID_FELD
oder
*ID_FELD={%[Klassenalias].#%}

CONDITIONS

{%[Klassenalias].#%}={*Klasse.*}

D.h. immer wenn die {%…%}-Notation verwendet wird, ist hinter den Klassenalias ein # zu schreiben. Bei der Ausgabe als RESULT oder der Verwendung als Parameter wird einfach die Klasse oder der Klassenalias mit einem Punkt geschrieben.

Beispiele:

RESULTS
Bgs.=THE_ID
*THE_ID={%Bgs.#%}

CONDITIONS
{%Bgs.#%}={*BGS UNS.*}

Weitere Beispiele für Abfragen finden Sie in der ASYS-Standardkonfiguration.

Dazu noch einige Anmerkungen:

Regelabfragen: Viele Regelabfragen haben unter RESULTS nur den Eintrag *trefferzahl=count(*). Damit wird i.d.R. geprüft, ob es genau einen Treffer zu der vorgegebenen Bedingung (CONDITIONS) gibt. Will man z.B. wissen, ob das Ankreuzfeld EB vorhanden in einem Entsorgungsnachweis TRUE ist, liefert Trefferzahl auch dann 0, wenn der Inhalt von EB vorhanden NULL ist. Würde man wie in der Abfrage IKA STD BGS EN Nutzbarkeit, bestimmte Ankreuzfelder als RESULTS definieren, muss vorher sichergestellt werden, dass die Felder nicht NULL sind.

Der Zugriff auf die freien Abfragen wurde seit der ASYS Version 3.14 geändert. Ab dieser Version wird die Abfragenmaske über eine Schaltfläche in der Toolbar der ASYS-Oberfläche aufgerufen. Damit ergeben sich folgende Ergänzungen / Erweiterungen:

• Für alle nicht modalen Masken (Aufgabenbereiche) können freie Abfragen definiert werden.
• Es werden die Abfragen für diejenige Maske (den Aufgabenbereich) geladen, die den Fokus hat (im Vordergrund ist).

Gleichzeitig wurde eine Erweiterung bzgl. der Parameter im CONDITIONS-Bereich der Abfrage implementiert. Sofern hierbei eine spezielle Notation eingehalten wird, werden die Parameter beim Aufruf über die ASYS-Oberfläche mit Daten des aktuellen Datensatzes der Maske vorbelegt. Die Notation der Parameter hat hierbei so zu erfolgen, wie bei Regelabfragen oder Abfragen für erweiterte Textformulare (d.h. Klassenname.Attributname).

Beispiele: Aufgabenbereich Begleitscheine

CONDITIONS

{%Bgs.EN Nummer%}='{*BGS UNS.EN Nummer*}'

Die Begleitscheinnummer wird aus dem Datensatz übernommen.

Aufgabenbereich Versand-/Begleitformular Liste

CONDITIONS

{%Vbf.Notifizierungsnummer%}='{*Notifizierung.Notifizierungsnummer*}'

Die Notifizierungsnummer wird aus dem Datensatz übernommen.

Aufgabenbereich Entsorgungsnachweis Grundverfahren (EN)

CONDITIONS

{%Dbl.Vorgangsnummer%}='{*Rolle Vorgang EN.Vorgangsnummer*}'
#{%Dbl.Gueltig Von%}={*Rolle Vorgang EN.Gueltig Von*}#

Die Vorgangsnummer (= Nachweisnummer) und das Startdatum der Datensatzgültigkeit werden aus dem Datensatz übernommen.

Achtung: Für Stringfelder müssen hierbei die Hochkommata gesetzt werden!

Die Auswertungsabfragen stellen eine neue Möglichkeit dar, den Anwendern Auswertungen, Summierungen oder Sonstiges für den Datensatz, der gerade bearbeitet wird, zur Anzeige zu bringen. Bei einem Begleitschein z.B. für die Fragestellung, wie viele Begleitscheine es bisher für den Nachweis gibt, wie hoch die gesamte entsorgte Menge bisher ist, welche Angaben in der VE stehen etc. Für jede Einzelfragestellung ist hierbei eine eigene Abfrage zu erstellen. Nach Betätigung der neuen Schaltfläche aus der Anwendungsoberfläche werden die Abfragen nacheinander ausgeführt und jedes Ergebnis in eine eigene Zeile in eine Tabelle geschrieben. Es können beliebig viele Abfragen definiert werden. Die Abfragen werden nach ihrem laufenden Reihenfolgenummer sortiert ausgeführt (s. Eigenschaften der Abfrage).

Bei der Definition der (Auswertungs-)Abfragen müssen einige Rahmenbedingungen eingehalten werden:

• Die Abfrage muss der gewünschten Maske (Aufgabenbereich) zugeordnet sein.
• Die Abfrage muss als Auswertungsabfrage in den Eigenschaften gekennzeichnet sein und eine Reihenfolgennummer erhalten.
• Es darf nur ein Ausgabeparameter definiert sein (bzw. nur der erste Ausgabeparameter wird angezeigt, alle anderen werden ignoriert).
• Die Abfrage darf nur einen (oder keinen) Datensatz zurückliefern (bzw. nur der erste Datensatz wird angezeigt, alle anderen werden ignoriert).
• Für die Beschreibung, um was für einen Wert es sich handelt, wird das Anwnederinfo-Feld der Abfrage verwendet.
• Es muss auf der Maske ein Datensatz selektiert worden sein.
• Im CONDITIONS-Bereich der Abfrage muss die bereits oben beschriebene spezielle Notation für aufgabenbezogene freie Abfragen eingehalten werden. Können bei einer Abfrage die Parameter während der Ausführung nicht automatisch durch Werte von der Maske ersetzt werden, kommt es zu einer Fehlermeldung und die Ausführung wird abgebrochen.

Aus der Ergebnisliste einer freien Abfrage kann automatisch in eine Maske gesprungen werden, wenn folgenden Randbedingungen eingehalten werden:

1. Der Abfrage ist zumindest diejenige Maske (Aufgabenbereich) zugewiesen, die aus der Ergebnisliste der Abfrage heraus geöffnet werden können soll. Diese Maske MUSS die erste Maske in der Liste sein. Die nachfolgenden Masken in der Liste lassen sich nicht auf diese Weise erreichen⁵⁾.
2. Als erstes Feld im RESULTS-Abschnitt der Abfrage ist das ID-Feld der Hauptgruppe der Datendarstellungsdefinition des unter 1 zugewiesenen Aufgabenbereichs anzugeben und dieses ID-Feld muss den Aliasnamen THE_ID haben. Welche Hauptgruppe je Aufgabenbereich die richtige ist, wird auf der Abfragenmaske angezeigt.

Beispiel

Zugewiesene Maske: Erzeuger (EZ)

CLASSES

...
BGS UNS=Bgs
BGS UNS.Rolle Erzeuger=Erz
Rolle Betrieb Erz=Btr
Rolle Betrieb Erz.FKB=Fkb

RESULTS

$THE_ID=distinct {%Btr.#%}
$Name={%Erz.Name 1%}
...

CONDITIONS

{%Erz.Behoerdliche Nummer%}={%Btr.Behoerdliche Nummer%}
...

Zurück zum Seitenanfang