Programmierreferenz

  1. Messageclass
  2. Benennung von Stored Procedures und Triggern
  3. Runtimeforms
  4. F2-Fenster
  5. Übersetzung von Oberflächen
  6. Application - Server, Übertragungsprotokoll
  7. Planung & Terminierung

MODULE

  1. BDE
    1. Tagespläne : MitPln führen

 

 

 

MESSAGECLASS

DM1.MessageClass = Klasse die Meldungen verteilt. Jede Anwendung hat sie einmal in DM1. TProdatMessageClass kann viele Listenerclassen registrieren und verteilt die Empfangenen Nachrichten dann. Im Standardclient : Nachrichten vom System oder Application-Server empfangen -> SysForms.USysModule.

Applicationserver : Wird eine Message geworfen wird sie von einer internen Listenerclasse abgefangen und über die Socketverbindung zum Client gesendet. Dieser löst wiederum eine Message mit dem Code 1 aus wodurch die Loadform mit der entsprechenden Message geöffnet wird. Der Server führt intern für jede Verbindung einen MSGCode wodurch eine Zuordnung zum Client ermöglicht wird.

MSGCode : Filter für Nachrichten. Grundsätzlich 0=alles empfangen und OnNotify auslösen. >0=nur entsprechende Nachrichtentypen. <0 unzulässig da vom App-Server vernwendet.

 <0 = Prozesse Server, nicht verwenden!

0 = für LoadForm in Oberfläche (Überschrift!)
1 = für LoadForm in Oberfläche (Detailtext)
2 = MessageBox anzeigen
10 = DMSys.ReadLn deaktivieren
11 = DMSys.ReadLn reaktivieren

siehe auch
Application - Server, Übertragungsprotokoll


 

 

BENENNUNG VON TRIGGER UND STORED PROCEDURE'S

tabellenname+"__"+"b,a"(before, after)+"i,u,d"(insert, update, delete)

Bsp :     llv__a_u = llv_after_update
             llv__a_iud = llv_after_insert+update+delete

 

 

Runtimeforms

Runtimeforms aufrufen mit
ExecuteRtf(RtfNr, Owner) /
ExecuteRtf_AutoParams(RtfNr, Owner)
wenn Parameter AutoParams='CAPTION'->Caption der RuntimeForm

 

F2-Fenster

werden erzeugt in Modulform. (Procedure StartCimComponent); Manueller Aufruf von F2 mittels MakeF2(Unit UModulForm);
F2-Fähigkeit von CimDBGrid/ CimEdit wird in ModulForm.OnKeyDown manuell gewerkstelligt;

 

Übersetzung von Oberflächen

in UGrundModulForm -> Klasse TTranslationCombo.
Im Konstruktor wird die Übersetzung der Ownerform automatisch gestartet.
Hints die mit xtt beginnen werden auch übersetztp

 

BDE : MitPln führen

aktueller Tag : Prüfung und evtl anlegen in auto_midnight_stemp();
lücken schliessen : mitpln_after_();

 

Application - Server, Übertragungsprotokoll

1. eine Anforderung an den Application-Server senden

nach dem ersten Start wird automatisch eine "ProdatSRV.ini" angelegt in der die Standardkonfigurationswerte eingetragen werden. Mann kann diese bearbeiten muss aber den Server dann neu starten. Für ein Connect ist nur "ListenPort" von Relevanz.

ProdatSRV akzeptiert grundsätzlich jede Connection. (Connect). Nach dem Connect muss als erstes eine Zeile mit dem Hostnamen gesendet werden. Nutzer, Passwort usw. werden durch die Datenbank geprüft.

nachdem ein Connect erfolgreich war und die Verbindung akzeptiert wurde (Hostname wurde gesendet) ist das Protokoll in der Form einer Hashtable zu führen. Der Protokollstart wird mittels "SENDDATA"  begonnen. Mit "ENDDATA" wird das Senden beendet und mittels "EXECUTE" werden die gesendeten Daten ausgewertet und entsprechende Vorgänge werden ausgelöst.

Protokollaufbau / Bsp:

Client -> Connect -> Ok -> Client sendet seinen Hostnamen.

Client ->

SENDATA
DATABASE=DB_TO_CONNECT
HOST=hostname
PORT=port
USER=DB-Username
PASSWORT=User-Password

das sind alles nur connectinformationen, die vom App-Server geprüft werden. Aus Sicherheitsgründen müssen diese IMMER KORREKT sein, sonst passiert nix.

AM_PROC=Procedure_to_execute
PARAM1..N (diese Namen sind frei zu vergeben, sie müssen im App-Server implementiert sein, das sind die Übergabeparameter an die Programmierte Procedure)=Daten
ENDATA
EXECUTE

Eventuelle Rückmeldungen können mittels ReadLn auf dem Port empfangen werden.

2. Antwortprotokoll des Application - Servers

siehe auch
Messageclass


Planung und Terminierung

Funktionsname :

term__ask_fertzeit(INTEGER, INTEGER) -> Fertigungszeit der Stammkarte bei gegebener Fertigungsmenge (Parameterreihenfolge genau so) (Stunden)
term__stvtrs_grobterm(RESID : VARCHAR, Zieltermin : DATE) -> führt eine Grobterminierung auf einer ABK - Auflösung durch.
term__stvtrsparent_saz(RESID VARCHAR, PARENTID INTEGER) -> gibt den spätesten Anfangszeitpunkt des Parent Artikel PARENTID der Stücklistenauflösung RESID an.

Algorythmus der Grobterminierung:

  1. aufbauen eines N - ären Abhängigkeitsbaumes (ein Knoten hat N Blätter). Dieser ist in stvtrs zu finden, Parent ist die ID des übergeordneten Knoten

    Dazu wird die Stückliste nach dem Parent sortiert. (Aufsteigend, absteigend ja nach ob vorwärts oder rückwärts) Da jeder Artikel vom root nach unten hin eine immer grösser werdende id hat, ist hier immer gewerkstelligt das die Abhängigkeiten eingehalten werden. Dies ist ein Links / Rechtsdurchlauf den den N-är Baum.

    Bei einer Rückwärtsterminierung schaut die Terminierung dann immer nach dem SAZ (spätester Anfangszeitpunkt) des Parent.
    Bei einer Vorwärtsterminierung schaut die Terminierung nach dem SEZ (spätester Endzeitpunkt) aller Children.

    Rückwärtsterminieren

  1. Am root beginnen
  2. Termine ermitteln
  3. alle Children des Root (Parent) ermitteln und Termin eintragen
  4. jedes der Children aus 3 wird neuer Root
  5. gehe zu 3 bis kein weiteres Children gefunden wird.

Vorwärtsterminieren

an den tiefsten Blättern beginnen, analog zur Rückwärtsterminierung.

Bearbeiten Materialdisposition

wird eine Materialdisposition berabeitet / gelöscht, müssen alle durch diese Materialdisposition ausgelösten Aufträge zurückgezogen werden. Dies wird durch Trigger an stvtrs gewerkstelligt.