Auf das Erstellen von Selektionen zur Laufzeit sind wir bereits in einem Beitrag eingegangen. Schwerpunkt des Artikels war das Formulieren von Abfragen auf verknüpfte Tabellen. Im heutigen Artikel möchte ich auf den Aufbau von logischen Ausdrücken in dynamischen Selektionen eingehen.
Bei der Verwendung von dynamischen Selektionen wird über einen logischen Ausdruck entschieden, ob der Datensatz in die Selektionsmenge übernommen wird oder nicht. Damit dies erreicht werden kann, stellt conzept 16 verschiedene Vergleichsoperatoren (=, >, between[ …)] zur Verfügung. Die Abfrage selbst wird mit der Funktion SelDefQuery() definiert. Da die Anweisung einen String erwartet, sind beim Erstellen eines logischen Ausdrucks einige Punkte zu berücksichtigen.
Verwendung von Konstanten:
Bei der Verwendung von Konstanten vom Typ Alpha ist zu beachten, dass diese in doppelten Hochkommata (‚) eingeklammert werden. Innerhalb der Anweisung SelDefQuery() werden diese doppelten Apostrophe zu einfachen Hochkommas geändert.
tHdlSel->SelDefQuery('', 'ART.aBezeichnung =* ''Software*''');Verwendung von Variablen:
Generell lässt sich sagen, dass Variablen nicht Bestandteil der Abfrage sind. Dies ändert sich allerdings, wenn der Inhalt der Variablen in den Abfrage-String eingefügt wird. Ab diesem Zeitpunkt ist der Inhalt der Variablen Teil der Abfrage. Soll nun innerhalb dieser eine Variable vom Typ Alpha eingefügt werden, muss diese mit doppelten Apostrophen eingeklammert werden. Innerhalb der Abfrage-Zeichenkette werden die doppelten Hochkommata zu einfachen Hochkommata geändert.
tHdlSel->SelDefQuery('', 'ART.aBezeichnung =* ''' + tValue + '''');Liegt die Variable nicht als Alpha-Typ vor, ist es erforderlich diese dementsprechend zu konvertieren und ebenfalls durch Apostrophe zu maskieren. Diese Maskierung wird innerhalb der Anweisung dementsprechend umgewandelt.
tHdlSel->SelDefQuery('', 'ART.iNummer >= ' + CnvAI(tValue));Besonderheit bei den Datentypen ‚Date‘ und ‚Time‘:
Ist die Variable vom Typ Date oder Time, so gibt es hier bei der Konvertierung eine beachtenswerte Besonderheit. Die Darstellung vom Zeit- bzw. Datumsformat ist in der Regel abhängig von den länderspezifischen Einstellungen des Betriebssystems. Sind diese beispielsweise auf das Format ‚JJJJ-MM-TT‘ eingestellt, gibt eine Konvertierung ohne Angabe einer Formatoption folgenden String zurück:
'KND.dEintrDatum = 2015-02-24'
Dieser String verursacht den Fehler Inkorrekter Datentyp (_ErrParserWrongType), da an dieser Stelle zwingend das Datumsformat ‚Tag.Monat.Jahr‘ ('24.02.2015') erwartet wird. Um den Fehler zu vermeiden, ist bei der Konvertierung zwingend die Formatoption _FmtInternal anzugeben. Wird diese Formatoption angegeben, führt dies zu einem immer gleichen Ausgabeformat und dies unabhängig der länderspezifischen Einstellungen. Der String besitzt somit folgendes Aussehen: 'KND.dEintrDatum = 24.02.2015'
Variable vom Typ Date:
tHdlSel->SelDefQuery('', 'KND.dEintrDatum = ' + CnvAD(tValue, _FmtInternal));
Variable vom Typ Time:
tHdlSel->SelDefQuery('', 'KND.tEintrZeit = ' + CnvAT(tValue, _FmtInternal));Auch bei der Konvertierung von numerischen Variablen kann es notwendig sein, die Formatoption _FmtInternal anzugeben. Die Ursache hierfür ist ebenfalls in den länderspezifischen Einstellungen des Betriebssystems zu suchen. Standardmäßig ist hier bei Zahlen eine Zifferngruppierung eingestellt, welche nach jeder dritten Zahl einen Punkt einfügt. Wird nun eine Konvertierung ohne Formatoption durchgeführt, so wird im Abfrage-String ebenfalls der Punkt eingefügt, was letztendlich wiederum zu dem Fehler _ErrParserWrongType führt.
7 Antworten
Danke für die wohlwollende Prüfung 😉
Selektion + zu Grunde liegende Abfrage: Dies ist doch aber in dem alten Tool zur Selektionserstellung möglich, oder? Also sollte auch die DV dazu in der Lage sein, oder wie sind hier die Zusammenhänge?
Wie auch immer: Wichtiger scheint mir, dass man vorhandene Selektionen nutzen kann, welche Abfrage dahinter steckt, kann man zur Not in der Entwicklungsumgebung anderweitig herausfinden.
Wir werden Ihre Vorschläge in unsere Überlegungen zur Weiterentwicklung der Datensatzverwaltung einfließen lassen =).
Es gibt bereits die Vorschläge, auf vorhandene Selektionen zugreifen und eingegebene Abfragen als solche speichern zu können.
Leider haben wir dabei den Nachteil, dass man die zu Grunde liegende Abfrage nicht mehr aus der Selektion entnehmen und daher auch nicht dem Benutzer anzeigen kann.
Klar, am Schönsten wäre es, wenn man das Datum einfach irgendwie eingeben könnte und es trotzdem immer funktionieren würde :-).
Aber meine Einwände haben den Hintergrund, dass ich davon ausgehe, dass die Datensatzverwaltung überwiegend von Programmierern genutzt wird und nur selten von Personen mit anderen Rollen (Admin, Anwender etc.). Daher wäre es m. E. am sinnvollsten, wenn die DV sich möglichst eng an den Vorgaben für den Programmierer orientieren würde. Bezogen auf die Filterangaben bei der DV hiesse dies: Man sollte die Angaben, die man bei SelDefQuery machen kann, 1:1 in die DV übernehmen können, das Datum ist da womöglich nur ein Punkt unter anderen.
Hier noch eine andere Idee: Wie wäre es, wenn die DV vorhandene Selektionen nutzen könnte, also Seketionen, die bereits in der Datenbank gespeichert sind? Das wäre auch praktisch, z.B. um die eigenen Selektionen direkt auf dem Datenbestand zu testen usw.
Die Notation für Konstanten in dynamischen Selektion orientiert sich an der Notation für Konstanten in Prozeduren. Dort entspricht das Datumsformat auch dem deutschen.
Für mich liegt der Unterschied darin, dass dynamische Selektionen durch die Applikation generiert werden, die Datensatzverwaltung aber von einem Benutzer verwendet wird.
Das wäre tatsächlich schön. Ich hatte mal die Idee, neben dem internationalen Datumsformat auch das lokale Datumsformat zu unterstützen. Das habe ich bisher aber auf Grund der dadurch komplexeren Verarbeitung beim Parsen des Ausdrucks und geringer Notwendigkeit zurückgestellt.
Hallo Florian
Dieses Argument sollte auch für Datumsangaben in dyn. Selektionen gelten, oder?
Auf jeden Fall wäre es schön, wenn die D-Verwaltung beide Formate verstehen würde.
Hallo Kilian, wir haben uns bei der Datensatzverwaltung für das internationale Datumsformat "Jahr-Monat-Tag" entschieden, statt für das deutsche Datumsformat "Tag.Monat.Jahr", weil CONZEPT 16 auch außerhalb des deutschsprachigen Raumes eingesetzt wird.
Zum Datumsformat: Lustigerweise muss man in der Datensatzverwaltung wiederum das Datumsformat <JJJJ-MM-TT> einhalten, obwohl die doch sicherlich auch Selektionen im Hintergrund nutzt.
Ich fände es weniger verwirrend, wenn hier eine grössere Übereinstimmung bestünde.