Im Überblick zum Release 1.0.0 hatte ich eigene Beiträge zu den einzelnen Bereichen angekündigt. Hier ist der erste, zu dem Teil, der im Alltag die meiste Arbeit abnimmt: schreiben und importieren.
Eine Bedingung, viele Objekte
insert, update, upsert, delete und variant schreiben mit den Rechten des angemeldeten Benutzers. update und delete nehmen dabei entweder eine ID-Liste oder dieselbe where-Bedingung wie ein select. Das ist mächtig, aber natürlich auch gefährlich, also immer erst mit select testen, was man tut. ![]()
update document Invoice 4711, 4712, 4713 set Status = 'paid'
update document Invoice set Status = 'overdue' where Status = 'open' and InvoiceDate < #DATE#-25d
update document Invoice 4711 set Positions = (Article = 'A-100', Qty = 7) replacetables
update document Invoice 4711 file #NULL#
delete document Invoice where Status = 'void' purge
Tabellenfelder werden als Zeilen geschrieben, replacetables ersetzt die Tabelle und appendtables hängt an.
Die Datei kommt einem Upload innerhalb des Reiters, kann aber auch über einen Dialog beim Ausführen spontan angefragt werden, wenn der Wert #BROWSE#, inline zwischen ''' mitgegeben wird. #NULL# entfernt die Dokumentdateien aber lässt das Objekt stehen. ID-Liste und Bedingung erreichen je bis zu 5000 Objekte, das ist die Voreinstellung.
Objekte werden einzeln geschrieben, ein abgelehntes Objekt stoppt die anderen nicht, und das Log zeigt danach sowohl geschriebenen IDs und auch pro abgelehntem Objekt die Meldung des Servers. Ist nur eine Anweisung im Editor, wird zusätzlich eine Anfrage ausgeführt und direkt darunter angezeigt:
Ordner, Register und Dokument in einem Durchgang
Anweisungen, die mit ; getrennt sind, laufen als Batch nacheinander. Jede Schreibanweisung benennt mit as, was sie erzeugt hat, und @name setzt das in der nächsten als Elternobjekt ein. So legt ein Batch den Ordner, sein Register und das Dokument in einem Durchgang ab, ohne dass eine einzige ID im Text steht.
upsert ist das Verb für Importe: Es sucht das Objekt über die search-Felder und schreibt es, oder legt es an, wenn nichts passt. Der zweite Lauf füllt damit denselben Ordner weiter, statt einen zweiten danebenzustellen. Abschliessen darf einen Batch nur ein Lesen, und das ist dann gleich die Kontrolle.
Fehlerbehandlung
Es gibt keine Transaktion. Ein Batch läuft nach einem Fehler weiter und meldet pro Anweisung erfolgreich, fehlgeschlagen oder übersprungen. Übersprungen heisst, dass die Anweisung eine @-Binding zu lesen versucht, das es dann nicht gibt: Konnte der Ordner nicht angelegt werden, wird das Dokument nicht anderswo abgelegt, sondern gar nicht.
Ein Import, der zur Hälfte durchgelaufen ist, ist deshalb ein normaler Ausgang, und der zweite Lauf muss damit umgehen können. Genau dafür steht upsert auf jeder Ebene, die sich über einen Schlüssel wiederfinden lässt.
Optional kann man beispielsweise auf jeder Importebene ein technisches Feld mit einer Laufnummer belegen. Diese kann etwa mit let run = #UUID7# erzeugt und dann als @run in jedes Objekt geschrieben werden.
Alles davon läuft in der DMS-Sitzung des angemeldeten Benutzers: Was dieser im Client nicht darf, darf er auch hier nicht.
Weiterhin viel Spass mit dem ECMind blue Studio und meldet Euch gerne, wenn ich etwas ergänzen oder erklären darf.


