17. August 2011

Ergebnisse der Oracle Forms Umfrage - Teil 1

In den letzten Monaten habe ich gemerkt, dass es gar nicht so einfach ist, einen grösseren Blogbeitrag am Stück zu schreiben. Deswegen werden die Umfrageergebnisse nun in mehreren kleinen Teilen publiziert.


Warum habe ich diese Forms-Umfrage durchgeführt?

Zur Jahrtausendwende hörte ich zum ersten Mal: "Forms ist tot und hat nichts mehr mit moderner Softwareentwicklung zu tun. Nutzt Java stattdessen". Das war zur Zeit von Forms 6i Client/Server und Forms 6i Web auf dem Internet Application Server.

Wenige Jahre später erschien dann Forms 9i mit vielen neuen Features und 2006 kam dann auch schon Forms 10g. Dies war für lange Zeit dann die stabilste Version die unter OC4J auf dem Oracle Application Server lief. Die Gerüchte um das baldige Ableben von Oracle Forms gingen weiter.

In 2007 startete Oracle dann einen grossen 5 Tage Betatest in Redwood Shores. Ich wurde eingeladen, daran teilzunehmen und bekam eine Woche lang einen detaillierten Einblick in die neuen Versionen aller Middleware-Produkte inklusive dem neuen Oracle Forms 11g. Das war sehr interessant, unter anderem durch das Kennenlernen der anderen 50 Betatester aus der ganzen Welt.

Forms 11g lief zu dieser Zeit schon so stabil, dass ich dachte, es könne nicht lange dauern, bis es auf den Markt käme. Ein Jahr später kaufte Oracle dann BEA und der Weblogic Server wurde die strategische Plattform für alle Oracle-Produkte. Das war dann auch der Grund, warum Forms 11g noch ein weiteres Jahr bis zur Produktionsreife brauchte.

In all diesen Jahren pushte Oracle immer nur Java und ADF als Entwicklungsplattformen. Dadurch wurde es in der Aussendarstellung natürlich automatisch ein wenig ruhiger um Oracle Forms herum.

Das war dann der Punkt, wo ich den Entschluss fasste, ein Stimmungsbild im Oracle Forms-Umfeld einzuholen. An dieser Umfrage liess ich im deutschsprachigen Umfeld nahezu 1000 Firmen teilnehmen und die Umfrageergebnisse ergaben einige sehr interessante Ergebnisse.

Es geht weiter mit Frage 1: Mit welcher Forms-Version arbeiten sie zurzeit?

2. Mai 2011

Der SQL Developer Data Modeler ist nun kostenfrei

Der alte SQL Developer Data Modeler war recht teuer und dies war für viele Kunden ein grosses Problem.

Jetzt, wo der Data Modeler Bestandteil des SQL Developers ist, entfallen auch die Lizenzkosten.

Bitte lesen


Dies ist ein weiterer wichtiger Schritt für uns Oracle Designer Fans um eines Tages zu den neuen Daten Modellierungstools von Oracle zu migrieren.

Danke Oracle

19. April 2011

SQL Developer 3.0 beinhaltet den Data Modeler

Die neue Version vom SQL Developer ist ein grosser Schritt in die richtige Richtung. Der Data Modeler ist nun integraler Bestandteil des Developers!

Der erste Screenshot zeigt die Differenzen im Objekt Navigator:


Neue Bereiche sind
- Editionierungs-Views (Editioning Views)
- Crossedition-Trigger
- Scheduler

Neben all den grossen Veränderungen machen auch ein paar Kleinigkeiten Spass. Zum Beispiel der Schliessen-Button im User-Interface der Registerkarten. Sie sind nun dauerhaft sichtbar, nicht wie in der alten Version, wo man erst mit der Maus über die Tab gehen musste um die Position des Buttons zu sehen.

Desweiteren werden die Tabellen automatisch gefiltert und zeigen Elemente aus dem Papierkorb nicht an.

Im Menü sind nun neue Menü-Items enthalten, die unter anderem für den Data-Modeler und das neue Data-Mining wichtig sind:


Zum Daten-Modllieren kann man nun direkt im Menü auf Ansicht->Data Modeler->Browser klicken und mit der Arbeit beginnen.


Hier kann man nun ein existierendes Modell per Datei->Data Modeler->Open öffnen oder ein neues Modell erstellen via Import aus dem Data Dictionary. Modelle werden gespeichert in eigenen Verzeichnissen, wobei zusätzlich immer noch eine Konfigurations-Datei mit der Erweiterung DMD erzeugt wird.

Meine nächsten Tests werden in folgenden Bereichen sein
- Generating Scripts
- Packages und Sourcecodes im Data Modeler erzeugen

Gerd

30. März 2011

SQL Developer 3.0 ist verfügbar

Oracle's Breaking News von gestern:

Breaking News: Oracle SQL Developer 3.0 is now available for download (29 March 2011)



Ich werde den neuen Developer in den nächsten Tagen eingehend testen und hoffe, dass der Data Modeler nun integriert ist.

28. Februar 2011

Oracle Forms Umfrage "Forms 12 und weiter"

Vor 6 Wochen startete ich mit der Idee einer grossen deutschen Umfrage zum Thema Zukunft von Oracle Forms.

Vor 5 Wochen lud ich nahezu eintausend Firmen im deutschsprachigen Umfeld ein, an meiner Umfrage teilzunehmen.

Die ersten Ergebnisse erhielt ich schon 2 Minuten, nachdem die Umfrage gestartet war.

In den vergangenen 2 Wochen wertete ich die Ergebnisse aus, schrieb den DOAG News Artikel und warte nun gespannt darauf, dass er in Druck geht.

Das Ergebnis der Umfrage ist sehr interessant. Ich möchte hier an der Stelle noch nicht vorgreifen, da die DOAG News das Vorrecht der Veröffentlichung haben soll.






In 4 Wochen, nachdem die Ausgabe April 2011 veröffentlicht ist, werde ich dann hier im Blog ausführlich über die Umfrage-Ergebnisse berichten.

Solange müssen wir uns noch gedulden
Gerd

17. Januar 2011

Versionierung von Masken + Sourcecodes vergleichen

Sourcecodes unterschiedlicher Maskenversionen miteinander zu vergleichen ist bei der Entwicklung und Wartung von Forms-Applikationen sehr wichtig. Oracle Forms unterstützt dies nicht nativ. Deswegen benötigt man eine Vorgehensweise, in der man entweder alles selber macht oder eine Versionierungs-Software nutzt.

Manuelle Versionierung

Jede Maskenversion wird in einem eigenen Ordner unter dem Maskennamen + Versionsnummer gespeichert. Z.B. emp_27.fmb, emp_28.fmb, ... In diesem Beispiel "emp" + "_27" + ".fmb".

Parallel zu jeder Version wird noch eine Textversion des FMB's erstellt, emp_27.txt, emp_28.txt usw. Die Textversion erzeugt man in Forms über Datei-Verwaltung-Objektlistenbericht.

Differenzen zwischen zwei Versionen kann man sich nun ganz einfach mit Tools wie z.B. Beyond Compare anschauen, meinem Lieblingswerkzeug für Diffs.



Versionierung mit Subversion, Git oder anderen VCS

Der professionelle Weg ist die Nutzung einer Versionskontroll-Software, z.B. Subversion als Repository und Tortoise als Frontend. Hier haben wir aber das Problem, dass das Speichern von binären FMB's in Subversion das eigentliche Problem nicht löst. Unterschiede zweier Binärdateien helfen einem nicht weiter, wenn man Software-Unterschiede finden möchte. Somit könnte man parallel wieder eine Textversion des FMB's speichern beim Check-in ins Repository.

Möchten wir nun die Differenzen zwischen zwei Versionen sehen, können wir die eingebauten Differenz-Viewer der Tools nutzen. Hier z.B. der Tortoise-Merge-Viewer:


Viel Spass beim Versionieren
Gerd

11. Januar 2011

Die Zukunft von Oracle Forms

Ende 2010 fragte mich die DOAG, ob ich einen Artikel zur Aprilausgabe der DOAG News schreiben möchte. Dort ist das Schwerpunkt-Thema "Oracle Forms".

Zuerst dachte ich, da schreib ich mal wieder ein sehr technischen Artikel, wie auch schon in den vergangenen Jahren.

Doch dann hatte ich eine bessere Idee. Der Artikel wird nun lauten: Die Zukunft von Oracle Forms".

Der Artikel besteht aus zwei Teilen. Im ersten zeige ich einen Ausblick auf die neuen Features, die Oracle in Forms 12 plant. Der zweite Teil zeigt die Ergebnisse einer grossen deutschen Umfrage, die ich diese Woche starten werde.

Die Umfrage ist an den typischen Oracle Forms Entwickler gerichtet. Befragt werden die Entwickler nach der aktuell eingesetzten Formsversion, wie lange sie schon mit Forms arbeiten und was sie über die Zukunft von Forms denken

Ich bin sehr gespannt, welche Ergebnisse dabei rauskommen.
Gerd

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