Autoupdate - Versionsgeschichte

Root: /* Technische Details zum Update-Konzept */

2019-03-27T14:11:27Z

Technische Details zum Update-Konzept

← Nächstältere Version		Version vom 27. März 2019, 16:11 Uhr
Zeile 57:		Zeile 57:
	// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:		// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:
	// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im		// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im
	// ~~hebu - Projekt nachgewiesen werden.~~ Ev. mal einen Test-Case daraus machen!		// Ev. mal einen Test-Case daraus machen!
	// *		// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.
	// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.		// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken
	// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken		// ist oder max 25 Sekunden. (Es gibt ja für SYSDBA die Möglichkeit USER
	// ist oder max 25 Sekunden. (Es gibt ja für SYSDBA die Möglichkeit USER		// durch einen "shutdown" rauszuschmeissen!).
	// durch einen "shutdown" rauszuschmeissen!).

OrgaMon: /* Technische Details zum Update-Konzept */

2007-09-11T11:07:30Z

Technische Details zum Update-Konzept

192.168.115.1 am 19. September 2005 um 07:15 Uhr

2005-09-19T07:15:53Z

← Nächstältere Version		Version vom 19. September 2005, 09:15 Uhr
Zeile 1:		Zeile 1:
	// Verwirklichtes Konzept:		Durch das Autoupdate Konzept wird sichergestellt, dass auf jedem OrgaMon Arbeitsplatz immer die neueste Programmversion läuft. Dazu muss der Administrator Schreibrechte auf das lokale OrgaMon-Programm-Verzeichnis (C:\Programme\OrgaMon) gewären.
	//
	// * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'		== Updaten auf die neueste OrgaMon Version ==
	// eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
	// oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!		Der Abruf der neuesten Version aus dem Internet kann eine Arbeitsstation initiieren. Dies erfolgt durch
	// * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis
	// das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder		Update->"neuestes Update im Internet" ausführen
	// nach dem Wert 9999 gesehen!
	// * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event		== Version als "schlecht" markieren ==
	// post_event 'PLEASE_DISCONNECT';
	// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,		Es kann vorkommen, dass sich neu implementierte Funktionen oder Verbesserungen an bisherigen Funktionen als fehlerhaft oder sogar schädlich für den gesamtzusammenhang erweisen. Dann bietet der OrgaMon eine Funktion an, um gewisse Release Nummern als "schlecht" zu markieren. Die Verwendung dieser Versionen wird dann automatisch umgangen. Es wird entweder eine Version vorher oder nach der "schlechten" verwendet. Eventuelle Datenbank Metadaten Änderungen bleiben jedoch bestehen (Stand 19.09.2005).
	// das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC
	// Server keine neuen Verbindungen mehr annehmen! '9998'		== Technische Details zum Update-Konzept ==
	// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
	// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet		// Verwirklichtes Konzept:
	// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.		//
	// Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf!		// * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'
	// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!		// eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
	// spä´¥stens bei Tagesabschluss sollte das gemacht werden!		// oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!
	// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.		// * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis
	// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder		// das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder
	// entfernen will, er will sicherstellen dass alle wieder auf die alte Version		// nach dem Wert 9999 gesehen!
	// zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das		// * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event
	// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions		// post_event 'PLEASE_DISCONNECT';
	// markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben		// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
	// bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-		// das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC
	// Version/empfohlene Version)		// Server keine neuen Verbindungen mehr annehmen! '9998'
	// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen		// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
	// er gibt diese Version frei oder nicht.		// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
	// * Wä¨²end das Datenbank-Update noch läµ¦t, muss verhindert werden dass sich		// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
	// Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene		// Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf!
	// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-		// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!
	// gef?bis das Update abgeschlossen ist.		// spä´¥stens bei Tagesabschluss sollte das gemacht werden!
	// * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden,		// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.
	// dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei		// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder
	// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem		// entfernen will, er will sicherstellen dass alle wieder auf die alte Version
	// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es		// zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
	// zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt		// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
	// werden!		// markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
	// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur		// bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-
	// hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das		// Version/empfohlene Version)
	// Interesse an der Datenbank-Struktur bei siemens da zu sein scheint.		// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
	// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:		// er gibt diese Version frei oder nicht.
	// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im		// * Wä¨²end das Datenbank-Update noch läµ¦t, muss verhindert werden dass sich
	// hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen!		// Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene
	// *		// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
			// gef?bis das Update abgeschlossen ist.
			// * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden,
			// dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
			// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
			// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es
			// zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt
			// werden!
			// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur
			// hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das
			// Interesse an der Datenbank-Struktur bei siemens da zu sein scheint.
			// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:
			// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im
			// hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen!
			// *
			// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.
			// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken
			// ist oder max 25 Sekunden. (Gibt es f? SYSDBA die M?chkeit USER
			// ja durch einen "shutdown" rauszuschmeissen!).

192.168.115.1 am 19. September 2005 um 07:06 Uhr

2005-09-19T07:06:56Z

← Nächstältere Version		Version vom 19. September 2005, 09:06 Uhr
Zeile 1:		Zeile 1:
	//
	~~// todo~~
	//
	~~// * Wenn OrgaMon von aussen beendet wird: wait "OrgaMon" to be down! OrgaMon sollte~~
	~~// einen "InsideTRN" Flag pflegen, damit erkannt werden kann, ob gerade eine wichtige~~
	~~// längere Aktion vorliegt. Er muss gewartet werden bis zu Ende gebucht ist. So dass~~
	~~// das Beenden von aussen nicht "kritisch" ist. Zumindest das eCommerce-Modul sollte so~~
	~~// etwas haben.~~
	~~// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.~~
	~~// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken~~
	~~// ist oder max 25 Sekunden. (Gibt es für den SYSDBA die Möglichkeit USER~~
	~~// ja durch einen "shutdown" rauszuschmeissen!).~~
	~~// * Jede Metadata Modifikation sollte kurz prüfen können, ob das Statement selbst~~
	~~// in der Datenbank schon realisiert wurde oder nicht - es wäre cool, wenn eine~~
	~~// Wissensdatenbank 'Quell-Satements' automatisiert in Ziel-Statements umwandeln~~
	~~// könnte.~~
	~~// * Noch cooler, neben dem check auf ein Undo - also ein "extern" rollback~~
	~~// "one single step" <do it statement>:~~
	~~// -> check-statement:boolean; true: "schon erledigt", false "muss ich noch machen"~~
	~~// -> do-it-statement:boolean; wie gehabt~~
	~~// -> undo-it-statement:boolean;~~
	~~// * ./Updates Verzeichnis leeren!~~
	~~// * No-MetaDatachange (neues Feld in der Revisionstabelle): Soll anzeigen ob der aktuelle~~
	~~// Release-Sprung ohne Meta-Data Änderung möglich war? Dann gelten "ältere" Releases~~
	~~// als "auch lauffähig" da sie zumindest in der Datenbank keinen Schaden anrichten.~~
	~~// * Released: Ein Flag das gesetzt wird, wenn es diese Version aus einem der Standard~~
	~~// Release-Medien stammt. (Developer releases setzen dieses Flag nicht)~~
	~~// * Problem: Der Entwickler hat in die Rev-Tabelle schon eine neuere Rev Nummer eingetragen~~
	~~// diese aber noch nicht released, in so einem Fall sollte sich baseupdate mit einer~~
	~~// Release drunter begnügen oder: Der entwickler muss eine release machen, damit andere~~
	~~// weiterarbeiten können.~~
	//
	// Verwirklichtes Konzept:		// Verwirklichtes Konzept:
	//		//
Zeile 42:		Zeile 10:
	// post_event 'PLEASE_DISCONNECT';		// post_event 'PLEASE_DISCONNECT';
	// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,		// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
	// das in wenigen Minuten heruntergefahren werden muss. z.B. ~~Könnte~~ so ein XMLRPC		// das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC
	// Server keine neuen Verbindungen mehr annehmen! '9998'		// Server keine neuen Verbindungen mehr annehmen! '9998'
	// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen		// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
	// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet		// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
	// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.		// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
	// Danach das Setup, dieses ~~überschreibt~~ den exe, ruft diesem im Anschluss auf!		// Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf!
	// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen ~~können~~, ob Updates vorliegen!		// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!
	// ~~spätestens~~ bei Tagesabschluss sollte das gemacht werden!		// spä´¥stens bei Tagesabschluss sollte das gemacht werden!
	// * Ein Updateadmin sollte das downgeloadete Update ~~für alle~~ freischalten ~~können~~.		// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.
	// * Szenario ~~überlegen~~: Wie kann der Updateadmin ein "~~mörderisches~~" Update wieder		// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder
	// entfernen will, er will sicherstellen dass alle wieder auf die alte Version		// entfernen will, er will sicherstellen dass alle wieder auf die alte Version
	// ~~zurückgehen~~, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das		// zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
	// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions		// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
	// markieren ~~können~~. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben		// markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
	// bzw. gleich die richtige Version ~~drüberinstallieren~~ (Programmversion>Datenbank-		// bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-
	// Version/empfohlene Version)		// Version/empfohlene Version)
	// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen		// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
	// er gibt diese Version frei oder nicht.		// er gibt diese Version frei oder nicht.
	// * ~~Während~~ das Datenbank-Update noch ~~läuft~~, muss verhindert werden dass sich		// * Wä¨²end das Datenbank-Update noch läµ¦t, muss verhindert werden dass sich
	// Clients mit der Datenbank verbinden. Dies ~~könnte~~ einfach durch eine vorhandene		// Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene
	// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-		// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
	// ~~geführt,~~ bis das Update abgeschlossen ist.		// gef?bis das Update abgeschlossen ist.
	// * In einer ~~zukünftigen~~ Version ~~könnte~~ das DB-Update einfach mal versucht werden,		// * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden,
	// dabei ~~müsste~~ aufgezeichnet werden, welche Update-Schritte durchliefen, und bei		// dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
	// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem		// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
	// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es		// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es

192.168.115.3 am 27. August 2004 um 10:22 Uhr

2004-08-27T10:22:12Z

Neue Seite

//
// todo
//
// * Wenn OrgaMon von aussen beendet wird: wait "OrgaMon" to be down! OrgaMon sollte
// einen "InsideTRN" Flag pflegen, damit erkannt werden kann, ob gerade eine wichtige
// längere Aktion vorliegt. Er muss gewartet werden bis zu Ende gebucht ist. So dass
// das Beenden von aussen nicht "kritisch" ist. Zumindest das eCommerce-Modul sollte so
// etwas haben.
// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.
// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken
// ist oder max 25 Sekunden. (Gibt es für den SYSDBA die Möglichkeit USER
// ja durch einen "shutdown" rauszuschmeissen!).
// * Jede Metadata Modifikation sollte kurz prüfen können, ob das Statement selbst
// in der Datenbank schon realisiert wurde oder nicht - es wäre cool, wenn eine
// Wissensdatenbank 'Quell-Satements' automatisiert in Ziel-Statements umwandeln
// könnte.
// * Noch cooler, neben dem check auf ein Undo - also ein "extern" rollback
// "one single step" <do it statement>:
// -> check-statement:boolean; true: "schon erledigt", false "muss ich noch machen"
// -> do-it-statement:boolean; wie gehabt
// -> undo-it-statement:boolean;
// * ./Updates Verzeichnis leeren!
// * No-MetaDatachange (neues Feld in der Revisionstabelle): Soll anzeigen ob der aktuelle
// Release-Sprung ohne Meta-Data Änderung möglich war? Dann gelten "ältere" Releases
// als "auch lauffähig" da sie zumindest in der Datenbank keinen Schaden anrichten.
// * Released: Ein Flag das gesetzt wird, wenn es diese Version aus einem der Standard
// Release-Medien stammt. (Developer releases setzen dieses Flag nicht)
// * Problem: Der Entwickler hat in die Rev-Tabelle schon eine neuere Rev Nummer eingetragen
// diese aber noch nicht released, in so einem Fall sollte sich baseupdate mit einer
// Release drunter begnügen oder: Der entwickler muss eine release machen, damit andere
// weiterarbeiten können.
//
// Verwirklichtes Konzept:
//
// * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'
// eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
// oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!
// * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis
// das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder
// nach dem Wert 9999 gesehen!
// * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event
// post_event 'PLEASE_DISCONNECT';
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
// das in wenigen Minuten heruntergefahren werden muss. z.B. Könnte so ein XMLRPC
// Server keine neuen Verbindungen mehr annehmen! '9998'
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
// Danach das Setup, dieses überschreibt den exe, ruft diesem im Anschluss auf!
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen können, ob Updates vorliegen!
// spätestens bei Tagesabschluss sollte das gemacht werden!
// * Ein Updateadmin sollte das downgeloadete Update für alle freischalten können.
// * Szenario überlegen: Wie kann der Updateadmin ein "mörderisches" Update wieder
// entfernen will, er will sicherstellen dass alle wieder auf die alte Version
// zurückgehen, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
// markieren können. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
// bzw. gleich die richtige Version drüberinstallieren (Programmversion>Datenbank-
// Version/empfohlene Version)
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
// er gibt diese Version frei oder nicht.
// * Während das Datenbank-Update noch läuft, muss verhindert werden dass sich
// Clients mit der Datenbank verbinden. Dies könnte einfach durch eine vorhandene
// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
// geführt, bis das Update abgeschlossen ist.
// * In einer zukünftigen Version könnte das DB-Update einfach mal versucht werden,
// dabei müsste aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es
// zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt
// werden!
// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur
// hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das
// Interesse an der Datenbank-Struktur bei siemens da zu sein scheint.
// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:
// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im
// hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen!
// *

← Nächstältere Version		Version vom 11. September 2007, 13:07 Uhr
Zeile 15:		Zeile 15:
	// Verwirklichtes Konzept:		// Verwirklichtes Konzept:
	//		//
	// * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'		// * Ist es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'
	// eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen		// eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
	// oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!		// oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!
Zeile 24:		Zeile 24:
	// post_event 'PLEASE_DISCONNECT';		// post_event 'PLEASE_DISCONNECT';
	// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,		// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
	// das in wenigen Minuten heruntergefahren werden muss. z.B. ~~K?e~~ so ein XMLRPC		// das in wenigen Minuten heruntergefahren werden muss. z.B. Könnte so ein XMLRPC
	// Server keine neuen Verbindungen mehr annehmen! '9998'		// Server keine neuen Verbindungen mehr annehmen! '9998'
	// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen		// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
	// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet		// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
	// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.		// sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
	// Danach das Setup, dieses ~~?hreibt den~~ exe, ruft ~~diesem~~ im Anschluss auf!		// Danach das Setup, dieses überschreibt die exe, ruft diese im Anschluss auf!
	// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen ~~k?n~~, ob Updates vorliegen!		// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen können, ob Updates vorliegen!
	// ~~spä´¥stens~~ bei Tagesabschluss sollte das gemacht werden!		// spätestens bei Tagesabschluss sollte das gemacht werden!
	// * Ein Updateadmin sollte das downgeloadete Update ~~f?e~~ freischalten ~~k?n~~.		// * Ein Updateadmin sollte das downgeloadete Update für alle freischalten können.
	// * Szenario ~~?gen~~: ~~Wie kann~~ der Updateadmin ein "~~m?risches~~" Update wieder		// * Szenario: Wenn der Updateadmin ein "mörderisches" Update wieder
	// entfernen will, er will sicherstellen dass alle wieder auf die alte Version		// entfernen will, er will sicherstellen dass alle wieder auf die alte Version
	// ~~zur?en~~, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das		// zurückstufen, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
	// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions		// eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
	// markieren ~~k?n~~. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben		// markieren können. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
	// bzw. gleich die richtige Version ~~dr?stallieren~~ (Programmversion>Datenbank-		// bzw. gleich die richtige Version drüber installieren (Programmversion>Datenbank-
	// Version/empfohlene Version)		// Version/empfohlene Version)
	// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen		// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
	// er gibt diese Version frei oder nicht.		// er gibt diese Version frei oder nicht.
	// * ~~Wä¨²end~~ das Datenbank-Update noch ~~läµ¦t~~, muss verhindert werden dass sich		// * Während das Datenbank-Update noch lädt, muss verhindert werden dass sich
	// Clients mit der Datenbank verbinden. Dies ~~k?e~~ einfach durch eine vorhandene		// Clients mit der Datenbank verbinden. Dies könnte einfach durch eine vorhandene
	// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-		// "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
	// ~~gef?~~bis das Update abgeschlossen ist.		// geführt, bis das Update abgeschlossen ist.
	// * In einer ~~zuk?en~~ Version ~~k?e~~ das DB-Update einfach mal versucht werden,		// * In einer zukünftigen Version könnte das DB-Update einfach mal versucht werden,
	// dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei		// dabei müsste aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
	// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem		// welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
	// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es		// Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es
Zeile 54:		Zeile 54:
	// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur		// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur
	// hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das		// hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das
	// Interesse an der Datenbank-Struktur bei ~~siemens~~ da zu sein scheint.		// Interesse an der Datenbank-Struktur bei Siemens da zu sein scheint.
	// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:		// die Datei befindet sich im Verzeichnis "MyApplicationPath". format:
	// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im		// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im
Zeile 61:		Zeile 61:
	// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.		// * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.
	// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken		// Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken
	// ist oder max 25 Sekunden. (~~Gibt es f?~~ SYSDBA die ~~M?chkeit~~ USER		// ist oder max 25 Sekunden. (Es gibt ja für SYSDBA die Möglichkeit USER
	// ja durch einen "shutdown" rauszuschmeissen!).		// durch einen "shutdown" rauszuschmeissen!).