27. September 2010

IE-Upgrade im lokalen Forms-Umfeld

Falls man eine gut laufende lokale Forms-Entwicklungsumgebung auf IE 6.0 or 7.0 hat und denkt: Ich könnte doch mal eben den IE 8.0 oder 9.0 installieren...

... dann könnte man in folgende Probleme reinlaufen:

Nach der IE 8 Installation könnte der erste Start einer Formsmaske aus dem Forms Builder heraus so aussehen:


oh nein... was für eine tolle Fehlermeldung in der URL...

Jetzt heisst es erstmal Fehlersuche und Lösungen finden:

Als Erstes ist zu beachten, dass der IE 8 vielleicht nicht mehr mit dem JInitiator zusammen läuft und man Alternativen braucht. OK also das Sun-Plugin installieren und weitertesten.

Die nächste Falle lauert in der Konfiguration. Wenn man in der URL nun einfach im config-String auf "config=my_sunconfig" wechelt, weil der auf dem grossen Applicationserver schon immer gut lief, dann sollte man bedenken, dass der lokale OC4J natürlich eigene Config-Files, sprich eine formsweb.cfg besitzt, die geändert werden muss..

Nach all diesen Änderungen kann im worst case nun auch noch der Pfad zum Internet Explorer 8.0 fehlerhaft sein. D.h., Forms Builder öffnen, Edit-Preferences, letzte Ragisterkarte: Web-Browser-Speicherort korrigieren, bzw. initial setzen.

Danach klappt's dann auch mit dem IE 8
Gerd

9. Juli 2010

Neues Layout

Ich habe mal wieder ein wenig an den Templates zu talk2gerd gearbeitet. Neue Features sind nun

Followers (Leser)

- hier können sich alle Leser an anmelden, so dass die Community sich untereinander ein wenig besser kennen lernt.

Labels

- hier werden alle Labels, die ich zum kategorisieren genutzt habe, aufgeführt. Wer also nur an Best Practices interessiert ist, der würde z.B. diesen Link dann anklicken

Viel Spass damit
Gerd

9. Juni 2010

"Forms 11g und das iPhone" wurde gerade bei der DOAG eingereicht

In wenigen Wochen endet der Call for Papers für die DOAG-Konferenz 2010.

Diesmal möchte ich einen Vortrag über Forms 11g und das iPhone halten.

Im Kern beschreibe ich dabei, wie man Module aus grossen Oracle Forms Applikationen extrahieren kann und auf dem iPhone neu erzeugt.

Im Vortrag wird anhand eine Beispiels gezeigt, wieviel effizienter es ist, z.B. eine Zeiterfassung in Projekten auf einem mobilen Device zu implementieren statt auf einer grossen schwerfälligen Legacy-Applikation auf dem PC.

In einem weiteren Punkt wird gezeigt, wie man zwischen Forms 11g und dem iPhone eine bidirektionale Kommunikation aufbaut. Genutzt wird hier Advanced Queueing in Forms und die Push Notification im iPhone.

5 Monate noch bis zur Konferenz und die Hoffnung im Vorfeld, dass der Vortrag angenommen wird
Gerd

5. Mai 2010

Ändern des Character Sets auf UTF8, Anmerkung zu Schritt 3

Nach der Datenbank-Migration auf UTF8 kann es Probleme mit dem Report-Server geben. Das erkennt man daran, dass Reports nicht mehr angezeigt und Fehlermeldungen wie "Canceled as server is shutting down" intern ins Log geschrieben werden.

Mit UTF8 braucht man einen grösseren Cache-Size in den "Reports Server-Parametern". Einfachster Weg das Problem zu lösen ist, den Wert des Cache-Size zu verdoppeln.

Try it
Gerd


Zurück zum Teil 3 des Artikels

28. April 2010

Ändern des Character Sets auf UTF8, Schritt 3

Applikationen ohne Reports sind nutzlos :-)

Daraus folgt, dass wir nun auch einige Änderungen in den Umgebungsvariablen des Report-Servers vornehmen müssen, damit UTF8 in PDFs sauber angezeigt wird.

Erstens

editieren wir auf dem OAS im Report-Server die Report-Konfiguration:




Wir können beliebig neue Bereiche erstellen, die wir mit "environment id" beginnen lassen. In diesem Fall nutzen wir je einen Bereich für Entwicklung, einen für Test und einen für Produktion. Danach können wir dann in jedem Bereich unseren eigenen NLS_LANG und Report-Pfad definieren.

Zweitens

Diese neuen Bereiche können von Forms beim Start des Reports genutzt werden. Dazu wird die Parameterliste um einen Parameter erweitert:

Add_Parameter (V_ParamListe, 'ENVID', TEXT_PARAMETER, 'NLS-PROD');

Dadurch kontrollieren wir die NLS_LANG des Reportservers.


Drittens

Zuletzt müssen wir noch das Mapping zwischen unseren Report-Fonts und unseren TrueType-Fonts herstellen (in diesem Beispiel nutzen wir einen OAS unter Windows)

Die Datei "uifont.ali" im Verzeichnis \tools\common wird im Bereich [ PDF:Subset ] um folgende Einträge erweitert:
Arial..Italic.Bold..             = "c:\windows\fonts\arialbi.ttf"
Arial...Bold..                   = "c:\windows\fonts\arialbd.ttf"
Arial..Italic...                 = "c:\windows\fonts\ariali.ttf"
Arial.....                       = "c:\windows\fonts\arial.ttf"

"Courier New"..Italic.Bold..     = "c:\windows\fonts\courbi.ttf"
"Courier New"...Bold..           = "c:\windows\fonts\courbd.ttf"
"Courier New"..Italic...         = "c:\windows\fonts\couri.ttf"
"Courier New"                    = "c:\windows\fonts\cour.ttf"

"Times New Roman"..Italic.Bold.. = "c:\windows\fonts\timesbi.ttf"
"Times New Roman"...Bold..       = "c:\windows\fonts\timesbd.ttf"
"Times New Roman"..Italic...     = "c:\windows\fonts\timesi.ttf"
"Times New Roman"                = "c:\windows\fonts\times.ttf"


In diesem Beispiel liegen die Fonts im Verzeichnis c:\windows\fonts\

Viel Spass damit
Gerd


Es geht weiter mit Ändern des Character Sets auf UTF8, Anmerkung zu Schritt 3

Zurück zum Teil 2 des Artikels

7. April 2010

Ändern des Character Sets auf UTF8, Schritt 2

Nachdem wir nun die NLS auf UTF8 geändert haben, könnte es sein, dass die bisherigen Hotkeys nicht mehr funktionieren.

Der NLS-Wechsel auf UTF8 hat bewirkt, dass im Hintergrund nun eine andere Ressourcen-Datei benutzt wird. Statt fmrwebd.res wird nun fmrweb_utf8d.res benutzt. Die Datei befindet sich im Forms-Home-Verzeichnis.

Falls otherparams in der formsweb.cfg den Parameter "term" nutzt, dann wird auf diese Weise eine Ressourcen-Datei hartkodiert zugewiesen. Hier könnte man nun a) den Wert des Parameters auf eine andere Datei schauen lassen oder b) den Inhalt der Datei überarbeiten.

z.B. Änderung des Parameters:
alt: otherParams=term=\fmrwebd.res
neu: otherParams=term=\fmrweb_utf8d.res

Nach diesen Änderungen arbeiten die Hotkeys wieder wie zuvor.


Es geht weiter mit Ändern des Character Sets auf UTF8, Schritt 3

Zurück zum Teil 1 des Artikels

31. März 2010

Ändern des Character Sets auf UTF8 in 3 Schritten

Was müssen wir in unserer Forms-Applikation alles ändern, wenn die dahinter liegende Datenbank von einem Single-Byte- auf einen UTF8-Zeichensatz geändert wird?

Erster Schritt:

Sichere alle Forms-Sourcen, die lokale Forms-Installation und alle Application-Server-Konfigurationsdateien.

Danach wird die NLS_LANG der Registry geändert. Zuerst einmal kann man den String in einem Dummy-Parameter zwischenspeichern, indem man einen neuen Parameter erzeugt namens "NLS_alt" mit dem aktuellen Wert des NLS_LANG. Danach ändert man den Wert von NLS_LANG z.B. auf "GERMAN_GERMANY.UTF8". Diese Änderung hat nur Auswirkungen auf den lokalen Forms Builder und wird benötigt um alle Forms-Sourcen neu durchzukompilieren.

Jetzt ändern oder erweitern wir die "default.env". Falls es dort schon eine Zeile mit NLS_LANG gibt, dann wird der neue UTF8-Wert (s.o.) dort reingeschrieben. Im anderen Fall wird eine neue Zeile NLS_LANG erzeugt. Diese Änderung hat nur Einfluss auf unseren lokalen OC4J.

Die gleichen Änderung werden auch an der default.env des Application Servers vorgenommen (jedoch mit den Mitteln des OEM-Editors und nicht direkt an den Dateien)

Diese Vorbereitungen im Bereich der Umgebungsvariablen sind zwingend notwendig


Es geht weiter mit Ändern des Character Sets auf UTF8, Schritt 2