1. Oktober 2007

Forms Start-Up (Teil 1)

Dies ist der erste Artikel einer kleinen Serie. Ich zeige an dieser Stelle Methoden und Verbesserungen des Forms-Starts. In fast allen Web-Projekten lernte ich in den vergangenen Jahren Techniken kennen, in denen das Browser-HTML verändert wurde um zum Beispiel das versehentliche Schliessen des Browser-Fensters zu verhindern.

Mein erstes Beispiel kommt von Francois Degrelle. Er gab mir den Tipp mit einem automatisch versteckenden Internet Explorer beim Forms Startup. Der einzige Parameter der geändert werden musste ist der HTMLbodyAttrs in der formsweb.cfg:

HTMLbodyAttrs=onLoad='javascript:self.moveTo(2000,2000)'

Nach dem Forms-Start wandert das Browser-Fenster an die X,Y-Position 2000, 2000. Das ist normalerweise ausserhalb des sichtbaren Bereichs. Dies lässt den Anwender glauben, dass der Browser nun geschlossen ist. Das Icon in der Taskbar ist zwar noch sichtbar, aber der Browser ist nicht zu sehen, selbst wenn der Anwender auf das Icon klickt.

Pro:
- Der Anwender glaubt, dass der Browser sich selber versteckt
- Nur die Forms-Anwendung ist sichtbar (bei separateFrame=True)

Contra:
- Die Task des Browsers ist sichtbar und kann nicht aktiviert werden. Sie kann nur geschlossen werden

Das ist zur Zeit meine Lieblingsvariante

17. September 2007

Bigger. taller. better :-)

Nachdem ich ein wenig am Template-HTML herumgespielt habe fand ich ein paar sehr wichtige Properties für meinen Blog.

Die ehemalige Breite des Blogs war ein echtes Hindernis und sorgte dafür, dass ich Sourcecodes oft kürzen musste, damit sie in eine Zeile passten. Dieses Problem ist jetzt ein für alle Mal gelöst. Nun habe ich 50% mehr Platz für meine Snippets :-)

13. September 2007

Einfaches Logging und Debugging in Forms

Jede Forms-Anwendung braucht eine simple Methode um Fehler wegzuschreiben. Diese Technik kann desweiteren dazu benutzt werden um Forms, Reports und PL/SQL zu debuggen.

Zuerst einmal erstellen wir die Tabelle, Sequence und eine View um die Logging-Information zu speichern:
CREATE TABLE Logging (
  ID                         NUMBER(8,0) NOT NULL,
  SESSION_ID                 NUMBER(8,0),
  INSERT_DATE                DATE NOT NULL,
  TEXT                       VARCHAR2(2000) NOT NULL);

CREATE SEQUENCE Logging_SEQ;

CREATE OR REPLACE VIEW V_Logging_desc 
         (ID, SESSION_ID, INSERT_DATE, TEXT)
AS SELECT ID, SESSION_ID, INSERT_DATE, TEXT
     FROM Logging
ORDER BY SESSION_ID DESC, ID DESC;

Desweiteren brauchen wir ein Package mit den Funktionen und Prozeduren, die für`s Logging benötigt werden.
CREATE OR REPLACE PACKAGE PK_DEBUG IS
  FUNCTION Debug_allowed RETURN BOOLEAN;
  FUNCTION Next_ID       RETURN NUMBER;

  PROCEDURE Disable;
  PROCEDURE Enable;
  PROCEDURE Destroy;
  PROCEDURE Init  (P_Debug_allowed IN BOOLEAN DEFAULT TRUE);
  PROCEDURE Write (P_Text IN VARCHAR2,
                   P_Session_ID IN NUMBER DEFAULT NULL);

  G_Debug_allowed BOOLEAN := TRUE;
  G_Session_ID    NUMBER;
END;
/
CREATE OR REPLACE PACKAGE BODY PK_DEBUG IS
FUNCTION Debug_allowed RETURN BOOLEAN IS
BEGIN
  RETURN (G_Debug_allowed);
END;

FUNCTION Next_ID RETURN NUMBER IS
  V_ID NUMBER;
BEGIN
  SELECT Logging_SEQ.nextval
    INTO V_ID
    FROM DUAL;
  RETURN (V_ID);
END;

PROCEDURE Disable IS
BEGIN
  G_Debug_allowed := FALSE;
END;

PROCEDURE Enable IS
BEGIN
  G_Debug_allowed := TRUE;
END;

PROCEDURE Destroy IS
BEGIN
  Write ('----------------------stopp '
    || to_char (G_Session_ID) || '--');
  G_Session_ID := NULL;
END;

PROCEDURE Init (
  P_Debug_allowed IN BOOLEAN DEFAULT TRUE) IS
BEGIN
  G_Debug_allowed := P_Debug_allowed;
  G_Session_ID := Next_ID;
  Write ('--start ' || to_char (G_Session_ID)
    || '----------------------');
END;

PROCEDURE Write (
  P_Text       IN VARCHAR2,
  P_Session_ID IN NUMBER DEFAULT NULL) IS
  PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  IF Debug_allowed THEN
    IF G_Session_ID IS NULL THEN
      Init;
    END IF;
    INSERT INTO Logging (ID,
      Session_ID, Insert_Date, Text)
    VALUES (Next_ID,
      NVL (P_Session_ID, G_Session_ID),
      Sysdate, P_Text);
    COMMIT;
  END IF;
END;
END;
/

Das Debugging wird mit INIT gestartet und endet mit DESTROY. Fehlermeldungen werden in die Tabelle festgeschrieben mit WRITE. Zum Beispiel:
pk_Debug.Write ('Hello World - ' || V_Test);

Teile des Debuggings können deaktiviert werden mit DISABLE, so dass von dieser Zeile Code an keine Logging-Informationen mehr geschrieben werden, bis man ENABLE startet.

Die View V_Logging_desc zeigt die Logging-Daten, gruppiert nach der neuesten Session-ID.
ID Session Insert-Date     Text
============================================
24    21   10.09.-12:38:48 -------stopp 21--
23    21   10.09.-12:38:48 Hello World - 42
22    21   10.09.-12:38:48 --start 21-------


Viel Spass damit
Gerd

31. August 2007

San Francisco Impressionen

Hier sind einige Fotos von San Francisco, aufgenommen in der Zeit nach dem Test-Event
Lombard Street Richtung Coit Tower

17 Miles Drive

Muir Woods

Der Beweis: Second Life existiert doch in der Realität

Steinkunst in Sausalito

Die Golden Gate

24. August 2007

Oracle Fusion Middleware 11g Beta Test - Letzter Tag

Heute war der letzte Tag des Beta-Tests. Nach den letzten Tests startete die grosse Feedback-Runde im Oracle Conference Center.

Alle Kunden und 50 Oracle Experten trafen sich, desweiteren waren Dutzende Oracle Mitarbeiter per Web-Konferenz zugeschaltet. In den folgenden 3 Stunden wurden nacheinander alle Produkte des Fusion Middleware-Stacks angehört und wir gaben unser Feedback ab. Der einzige Forms-Tester (myself) gab folgendes Statement an Oracle:

Zuerst einmal: Forms ist eine sehr grosse Plattform in Deutschland und dieses Beta 2 Programm zeigte uns in den letzten Tagen das erste Oracle Forms, das nach vielen Jahren mit neuer Funktionalität im Forms Builder aufwartete.

Danach beschrieb ich die neuen Features und wie wichtig sie in der Forms Community sind.

Am Ende erklärte ich noch, welche Funktionalität ich persönlich gerne noch im Forms Builder sähe:

* ein Object namens Web-Service auf Form-Ebene
* die Integration von BI-Beans
* und am wichtigsten: einen neuen PL/SQL-Editor

Das war mein Statement und nun möchte ich mich vielmals bedanken bei Oracle für die Einladung zu diesem Event, Duncan und seiner Gruppe für einen phantastischen Support in der Woche. Es war klasse, solch eine Chance zu bekommen und mit diesen Profis arbeiten zu können.

Vielen Dank auch an Rolf (meinen Boss) der diesen Trip finanzierte, an Manuela (die mich gehen liess) und an Andreas, der eine wichtige Schulung beim Kunden übernahm, während der Testwoche. Vielen Dank euch allen!

Und hier ist der Beweis, dass Duncan seine Karriere in der NBA gestartet hat, bevor er zu Oracle kam (Ich bin 1,97):

PS: Falls sich jemand wundert, warum ich die neuen Features samt Funktionalität nicht beschreibe, dem sei gesagt, dass ich bis zur DOAG Konferenz Stillschweigen halten muss.

23. August 2007

Forms Beta-Test, Tag 4

Duncan und ich erfanden ein neues Feature vor ein paar Tagen. Heute war es soweit und ich konnte es in Forms 11g einbauen und testen:

Remote Debugging-Start mittels AQ

Die Idee ist einfach: Ein Entwickler stellt eine Information in eine Forms-AQ ein, auf der alle Formsmasken horchen. Diese Payload wird nun in den einzelnen Masken ausgelesen und startet einen neuartigen AQ-Trigger. Der Anwender wird nun zur Laufzeit gefragt, ob er seine Maske debuggen lassen möchte. Wenn er dies bestätigt startet die Maske ein debug.attach und der Entwickler kann seinen Forms Builder nutzen um die Client-Runtime zu debuggen.

Dies ist eine neuartige Form des Remote Debuggings das nur mit Forms 11g integriert werden kann.

22. August 2007

Forms Beta-Test, Tag 3

Heute haben Duncan und Phil Kuhn an einigen neuen Forms Features gearbeitet. Es ist grossartig zu sehen, wie sie und das Team im Hintergrund arbeiten.

Dies ist die erste Oracle Forms Version seit ca. sieben Jahren, in der neue Funktionalität (neue Objekte und Trigger) im Forms Builder integriert wurde!

All jene, die das Ende von Oracle Forms propagieren werden eines besseren belehrt, wenn das neue Release herauskommt.

21. August 2007

Forms Beta-Test, Tag 2

Der zweite Tag des Beta-Tests startete mit einem Überblick des neuen Oracle Application Servers. Vier Sessions wurden diesbezüglich heute präsentiert. Die restliche Zeit blieb zum Betatesten von Oracle Forms 11g.

Am Ende des Tages lud Oracle uns in ein nettes Restaurant nahe des Headquarters ein.

20. August 2007

Einladung zum Oracle Forms Beta-Test

Oracle HQ in Redwood Shores lud mich zum diesjährigen Beta-Test der Fusion Middleware ein.

Heute starteten wir im Headquarter zusammen mit 16 anderen eingeladenen Firmen. Zusätzlich zu uns Testern unterstützte Oracle diese Veranstaltung noch mit nahezu 50 Oracle Cracks. Zum Beispiel den Oracle Forms Chefentwickler Duncan Mills.

Oracle entwickelte umfangreiche Test-Szenarien für die kommenden 5 Tage. Somit werden wir in der Lage sein, tief in all die neuen Produkte reinzuschauen.

Die Stimmung in der Mannschaft ist grossartig!

3. August 2007

Setze Record-Status auf Query nach dem POST-QUERY

In Blöcken mit einem POST-QUERY-trigger hat man oft das Problem, dass der Record-Status auf CHANGED wechselt, wenn Non-Basetable-Items verändert wurden im POST-QUERY.

Wenn man nun den Record-Status zurück auf QUERY setzt, ist das auf jeden Fall schon mal eine gute Vorgehensweise. Dazu erstellen wir eine Prozedur zum Setzen des Record-Status auf QUERY:

PROCEDURE Set_Record_Query_Status IS
BEGIN
Set_Record_Property (NAME_IN ('SYSTEM.TRIGGER_RECORD'),
NAME_IN ('SYSTEM.TRIGGER_BLOCK'),
STATUS,
QUERY_STATUS);
END;

dieser wird dann im POST-QUERY-Trigger aufgerufen:

BEGIN
SELECT someColumns
INTO :myBlock.nonBasetable_Item
FROM myTable
WHERE someFilter;

Set_Record_Query_Status;
END;

Nachdem nun jeder Datensatz auf QUERY-Status gesetzt wurde hat man mit den Daten des Blockes auch kein Problem mehr.

Wichtig: Wenn der POST-QUERY Basetable-Items im Datensatz verändert muss man die erzeugten Datensatz-Sperren zurücksetzen, falls der Block-Locking-Modus auf Immediate gesetzt ist. Dieses Problem kann folgendermassen gefixt werden:


BEGIN
Set_Block_Property ('myBlock', LOCKING_MODE, Delayed);

SELECT someColumns
INTO :myBlock.nonBasetable_Item
FROM myTable
WHERE someFilter;

Set_Block_Property ('myBlock', LOCKING_MODE, Immediate);

Set_Record_Query_Status;
END;



try it
Gerd

1. August 2007

Oracle Certified Trainer

Seit Freitag bin ich nun auch Oracle Certified Trainer. Dies ist die Voraussetzung dafür, in der Oracle University arbeiten zu dürfen.

20. Juli 2007

Neustart meines Forms Framework-Projektes

Open-Source-Projekte sollte man dort hosten, wo sie

- einfach zu benutzen
- einfach zu administrieren
- einfach zu finden sind

und vor zwei Tagen fand ich Google Code. Dies ist eine phantastische Plattform, um Projekte zu sharen!

http://code.google.com/p/forms-framework/

Zur Zeit deploye ich gerade die Haupt-PL/SQL Library und das Forms Template

Viel Spass mit dem Projekt und seinen nächsten Releases
Gerd

19. Juli 2007

Check Form_Success für jedes Built-In

Alle Built-Ins haben das Problem, das sie keine echten Exceptions werfen. Nur im ON-ERROR

Beispiel: Sie möchten zum Block Customer navigieren. Dabei unterlief ihnen ein Schreibfehler:

Go_Block ('CUSTOMR');
Do_something_after_Go_Block;

Go_Block kann nicht zu dem angegebenen Block navigieren, da CUSTOMR nicht existiert. Es wird jedoch keine Exception für innerhalb des PL/SQL-Blockes erzeugt. Das heisst, der Code wird nicht unterbrochen und die Abarbeitung von Do_something_after_Go_Block startet. Das ist immer ein grosses Problem!

Lösung: Erzeuge eine Prozedur Check_Builtin

PROCEDURE Check_Builtin IS
BEGIN
IF NOT Form_Success THEN
RAISE Form_Trigger_Failure;
END IF;
END;

Benutze diese Prozedur nach jedem Built-In:

BEGIN
Go_Block ('CUSTOMR');
Check_Builtin;
Do_something_after_Go_Block;
EXCEPTION
WHEN FORM_TRIGGER_FAILURE THEN
-- do something ...
END;

Desweiteren kann man ein eigenes Built-In schreiben für Goto_Block anstelle von Go_Block: Diese neue Prozedur arbeitet intern mit dem neuen Check_Builtin

PROCEDURE Goto_Block (P_Block IN VARCHAR2) IS
BEGIN
Go_Block (P_Block);
Check_Builtin;
Do_something_after_Go_Block;
END;

als nächstes:

BEGIN
Goto_Block ('CUSTOMR');
Do_something_after_Go_Block;
EXCEPTION
WHEN FORM_TRIGGER_FAILURE THEN
-- do something ...
END;

Wichtig: Wenn sie diese Technik anwenden müssen sie ein Exception-Handling schreiben, dass den FORM_TRIGGER_FAILURE abfängt und behandelt.

Diese Technik ist identisch zu Oracle's Check_Package_Failure-Routine, diese kann jedoch nur genutzt werden, wenn in der Maske mindestens eine Master-Detail-Relation existiert.

benutze Check_Builtin
Gerd

10. Juli 2007

Zusammenführung grosser Default-Where-Bedingungen

Der einfachste Weg um Where-Bedingungen zu konkatinieren ist:

Beispiel: Eine leere Maske mit der Tabelle DEPT. In diesem Beispiel soll es drei Regeln geben, nach denen die Default-Where-Bedingung aufgebaut wird. Das Problem ist: Ab dem zweiten IF muss man jedesmal überprüfen, ob in V_Default_Where schon etwas drinsteht. Falls ja wird ein ' AND ' dran konkatiniert vor jedem neuen Teilstring.

DECLARE
V_Default_Where VARCHAR2 (2000);
BEGIN
IF Rule_1_is_TRUE THEN
V_Default_Where := 'DEPTNO IN (10, 20, 30)';
END IF;

IF Rule_2_is_TRUE THEN
IF V_Default_Where IS NOT NULL THEN
V_Default_Where := V_Default_Where ||
' AND DNAME != ''SALES'' ';
ELSE
V_Default_Where := 'DNAME != ''SALES'' ';
END IF;
END IF;

IF Rule_3_is_TRUE THEN
IF V_Default_Where IS NOT NULL THEN
V_Default_Where := V_Default_Where ||
' AND LOC IS NOT NULL';
ELSE
V_Default_Where := 'LOC IS NOT NULL';
END IF;
END IF;

Set_Block_Property ('DEPT', DEFAULT_WHERE,
V_Default_Where);
Go_Block ('DEPT');
Execute_Query;
END;

Diese IF's sind nicht wartbar. Änderungen in der Where-Bedingung bedeuten immer zwei Änderungen im Code:

...
V_Default_Where := V_Default_Where ||
' AND LOC IS NULL';
ELSE
V_Default_Where := 'LOC IS NULL';
...

Ein besserer Ansatz ist die Benutzung von ' AND ' bei jeder Konkatinierung:

DECLARE
V_Default_Where VARCHAR2 (2000);
BEGIN
IF Rule_1_is_TRUE THEN
V_Default_Where := ' AND DEPTNO IN (10, 20, 30)';
END IF;

IF Rule_2_is_TRUE THEN
V_Default_Where := V_Default_Where ||
' AND DNAME != ''SALES'' ';
END IF;

IF Rule_3_is_TRUE THEN
V_Default_Where := V_Default_Where ||
' AND LOC IS NOT NULL';
END IF;

Set_Block_Property ('DEPT', DEFAULT_WHERE,
Substr (V_Default_Where, 6));
Go_Block ('DEPT');
Execute_Query;
END;


der Substr (V_Default_Where, 6) eliminiert zum Schluss das führende ' AND '.

Sehr einfacher und wartbarer Code!

PS: In den englischen Kommentaren gibt es eine Erklärung dafür, dass ich nicht den Trick mit "1=1" benutze

27. Juni 2007

Deutscher Wochentag

Das grosse Problem von "to_char (sysdate, 'D')" ist, dass abhängig vom NLS unterschiedliche Resultate herauskommen:

Sonntag ist der erste Wochentag in den USA
Montag ist der erste Wochentag in Deutschland

Grün-Donnerstag 2000 zum Beispiel:

Green_Thursday := to_date ('23.03.2000', 'DD.MM.YYYY');
in den USA: to_char (Green_Thursday, 'D') = 5
in der BRD: to_char (Green_Thursday, 'D') = 4

Das ist sub-optimal, da die Formatmaske abhängig von der NLS ist.

Meine Lösung in diesem Fall ist: Die Funktion German_Weekday

FUNCTION German_Weekday (P_Date IN DATE)
RETURN NUMBER IS
V_Delta NUMBER;
BEGIN
-- Referenz-Tag: Grün Donnerstag 2000 = Tag 4 in Deutschland
V_Delta := TO_NUMBER (TO_CHAR (TO_DATE ('23.03.2000',
'DD.MM.YYYY'),
'D')) - 4;
RETURN (TO_NUMBER (TO_CHAR (P_Date-V_Delta, 'D')));
END;

und American_Weekday

FUNCTION American_Weekday (P_Date IN DATE)
RETURN NUMBER IS
V_Delta NUMBER;
BEGIN
-- Referenz-Tag: Grün Donnerstag 2000 = Tag 5 in USA
V_Delta := TO_NUMBER (TO_CHAR (TO_DATE ('23.03.2000',
'DD.MM.YYYY'),
'D')) - 5;
RETURN (TO_NUMBER (TO_CHAR (P_Date-V_Delta, 'D')));
END;

diese Funktion gibt nun immer den korrekten deutschen Wochentag zurück, unabhängig von der NLS.

viel Spass damit
Gerd