Die folgenden Optionen sind global implementiert, und wirken daher für alle SOG Programme.
Die nachfolgenden Optionen wirken auf das gestartetet Programm, und auf alle Programme die von diesem gestartet werden.
Mit der Option können einzelne Umgebungsvariable gesetzt werden.
Vor Ausführung des Programms wird das aktuelle Verzeichnis gesetzt.
Die Applikations-Log wird eingestellt. Applikations-Logs werden z.B. in einer Job-Verarbeitung verwendet, und stellen dort einen Kanal für Consol-Ausgaben dar. AppLogs können von mehreren Programmen gleichzeitig verwendet werden.
Einschalten einer Trace-Ausgabe.
Legt die Sprache für numerische Eingabefelder fest.
Legt die Sprache für Datums-Eingabefelder fest.
Ermöglicht das Setzen von Umgebungsvariablen, die in einer Textdatei im Format "Name=Wert" festgelegt wurden.
Setzen der Benutzersprache (Oberflächensprache).
Die nachfolgenden Optionen wirken nur auf das gestartete Programm.
Legt der Pfad der zu ladenden Projekt-Script-Dll fest. Wird die Script-Dll z.B. im Developer-Studio entwickelt, kann hier der Pfad zur tatsächlich durch das DevStudio erzeugten Script-Datei gesetzt werden. Damit sind alle DevStudio-Features wie z.B. EditAndContinue möglich.
Setzen des Haupticons der Anwendung.
Ermöglicht die Angabe eines alternative Projektnamens für den Zugriff auf DBFiles Daten.
Kein Timeout beim Herstellen der Verbindung zu einem SQL Server.
Verwendung des ReadOnly-Datenbank Providers. Datenveränderungen werden nicht dauerhaft gespeichert. Nach dem Ende des Programms befindet sich die Datenbank wieder auf dem Zustand, den sie vorher hatte. Wirkt auf alle Datenbankverbindungen außer "OleDbTrans" (Übersetzungen).
Übersetzung von Scripten in einerm Form, die das Debuggen ermöglicht.
Kein Start eines Aktualisierungsthreads für Programminformationen.
Keine Kontrolle der Datenbank am Programmanfang.
Kein Laden der Projekt-Script-Dll.
Kein kopieren der Script-Dll in ein Temp-Verzeichnis.
Beinhaltet -nocommit und -nosemaupd. Versucht die Anzahl der geschützten Datensätze auf der Datenbank zu minimieren. z.B. werden keine Sempahoren oder Transaktionssempahoren geschützt. Wird die Option verwendet benötigt und verbraucht die Anwendung keine ClientLizenz.
Beinhaltet -nosemaupd. Datenbanktransaktionen werden nicht Committed sondern Rollbacked. Wird die Option verwendet benötigt und verbraucht die Anwendung keine ClientLizenz.
Das angegebene Signal (int-Zahl) wird zum Beenden des Programms zusätzlich akzeptiert. (Wirkt nur auf Programme, die per hhterm-Signal beendet werden können)
Im #nocommit Modus verwendet die Anwendung einen "ReadOnly" Datenbankprovider für die OleDbGlobal Datenbank. Dieser Provider sorgt dafür, dass die Anwendung nur eine einzige Datenbankverbindung nutzt. Alle Veränderungen werden über diese Datenbankverbindung abgewickelt. Veränderungen werden aber nicht festgeschrieben (committed) sondern am Programmende zurückgesetzt (rollbacked).
SOG ERP ist in diesem Modus vollständig bedienbar. Allerdings ist Vorsicht geboten, da jede Veränderung bis zum Programmende geschützt bleibt. Es können also in hohem Maße Datenbankblockierungen auftreten, wenn andere Programme oder Anwendungen aktiv sind.
Sollte es durch einen DeadLock zu einem automatischen Rollback kommen, sind alle bis dahin durchgeführten Veränderungen verworfen.
Der #minimumlocks Modus schaltet automatisch auch den NOCOMMIT Modus ein. Die Anwendung versucht möglichst wenig allgemeine Datensätze zu schützen. So werden keine Daten aus den Tabellen "dbsema" oder "dbtranssema" geschützt. Auch werden keine Semaphoren eingerichtet. Im Minimlocks-Modus benötigt und verbaucht die Anwendung keine Client-Lizenzen.
Weiterhin ist aber Vorsicht geboten, da jede Veränderung bis zum Programmende geschützt bleibt. Es können in hohem Maße Datenbankblockierungen auftreten, wenn andere Programme oder Anwendungen aktiv sind.
Folgende weitere Abweichungen gelten im Minimumlocks-Modus:
Es wird kein ClearOldProc durchgeführt.
Die Anwendung benötigt und verbraucht keine Client-Lizenz.
Semaphoren werden nicht geschützt.
Transaktionssemaphoren werden nicht geschützt.
Es werden keine Informationen für den Programmstart über ein Taskleisten Icon geschrieben.
Es wird ohne ActiveSkin Maskencache gearbeiter.
Der #stealth Modus hat eine ähnlich Auswirkung wie der "nocommit" Modus, ist aber technisch vollkommen anders realisiert.
Die Anwendung öffnet wie gewohnt Datenbankverbindungen für verschiedene Aufgaben. Veränderungen werden auf den Verbindungen durchgeführt, und für die Dauer der anliegenden Operation "ganz normal" geschützt. Transaktionen werden aber nicht festgeschrieben, sondern umgehend zurückgesetzt.
Für die Anwendung entsteht also der Eindruck, Daten verändert zu haben. Eine Veränderung findet aber nicht statt. Werden so beeinflusste Datensätze neu gelesen, haben sie umgehend wieder ihren alten Inhalt. Neu eingefügte Datensätze sind umgehend wieder verschwunden.
SOG ERP ist in diesem Modus weitgehend bedienbar, sofern keine neuen Daten angelegt werden. So kann z.B. das p102 - Auftragsbearbeitung (aufbea) zum Verwalten von Aufträgen verwendet werden, beim Neunanlegen eines Auftrages wird es aber abbrechen, da der eingefügte Kopfsatz in der nächsten Transaktion nicht wiedergefunden wird.
Die Anwedung schützt über die aktuelle Transaktion hinaus keine weiteren Daten in der Datenbank. Daher ist sie auch für die meisten Analysetools weitgehend unsichtbar.
Folgende weitere Abweichungen gelten im Stealth-Modus:
Der Fehler "Datensatz wurde zwischenzeitlich verändert!" wird nicht erzeugt.
Die Anwendung benötigt und verbraucht keine Client-Lizenz.
Es wird kein ClearOldProc durchgeführt.
Es werden keine Informationen für den Programmstart über ein Taskleisten Icon geschrieben.
Es werden keine Informationen in DBFile-Tabellen geschreiben.
Es wird ohne ActiveSkin Maskencache gearbeiter.