Tooltips vom Converter bei ADF af:inputText Feldern unterdrücken

Eigentlich machen die Tooltips von Convertern auf Eingabefeldern ja durchaus Sinn, denn sie helfen dabei, mögliche Fehleingaben zu verhindern.

Wenn der Kunde aber wünscht "...bitte nicht anzeigen, die Benutzer wissen, was sie da eintragen..." ist uns das Befehl.

Dieses Posting im Oracle Forum zeigt den Weg, wie es auf af:inputDate Feldern mit dem automatisch gesetzten convertDateTime Converter funktioniert: https://forums.oracle.com/message/10101349#10101349

Das funktioniert analog natürlich auch z.B. für ein af:inputText Feld, auf dem ein Converter manuell eingestellt wurde!

1.) Javascript Funktion in den Code

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
          xmlns:af="http://xmlns.oracle.com/adf/faces/rich"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:c="http://java.sun.com/jsp/jstl/core">

  <af:resource type="javascript">
     function blockHint(event) {
        var source = event.getSource();
        source.getPeer().ShouldShowHint = function() {
            return false;
        }
     }
  </af:resource>
...

2.) Funktion innerhalb des af:inputText mit einem af:clientListener auf den Typ focus aufrufen lassen.

...
<af:inputText id="it6"
              simple="true"
              rows="1"
              columns="#{row.length.value}"
              maximumLength="#{row.length.value}"
              value="#{row.zahl}"
              contentStyle="text-align:right;">
   <af:clientListener method="blockHint"
                      type="focus"/>
   <f:convertNumber pattern="#"
                    type="number"/>
</af:inputText>
...

Fertig.

JDeveloper 12c als public download verfügbar

Der JDeveloper und ADF haben den Sprung auf den 12c Layer von Oracle geschafft. Wie anzunehmen finden wir hier zu großen Teilen ein Versionsmerging von Release 1 und Release 2 des JDeveloper 11g, aber auch einige weitere Feinheiten.

Details sowie ein Download kann unter:

http://www.oracle.com/technetwork/developer-tools/jdev/documentation/1212-nf-1964675.html

gefunden werden.

Viel Spaß beim ausprobieren!

Manuelles Standby Skripting: Data Guard für Arme?

Nein, es ist kein Data Guard, aber dessen Möglichkeiten sind auch nicht immer erforderlich. Zur reinen Absicherung einer Datenbank im Desasterfall ist eine selbst geskriptete Standby Datenbank oft ausreichend. Darüber hinaus erhält man damit die Möglichkeit Reporting in eine Read Only Datenbank auszulagern oder ein Testsystem kurzfristig mit den aktuellen Daten verfügbar zu haben.

Ja sicher ist damit ein enormer Kostenvorteil gegeben. Oracle Data Guard ist eine Option, die nur für die Enterprise Edition zur Verfügung steht. Aber wenn man nur den Desasterfall absichern möchte und ansonsten keinerlei Enterprise Edition Features benötigt, sind die Mehrkosten nicht gerechtfertigt.

Im Vortrag zeigte ich wie eine Standby Datenbank Konfiguration für eine Oracle 11gR2 Standard Edition (One) eingerichtet wird, welche Skripte erforderlich sind und was überwacht werden sollte. Dargestellt habe ich auch einige Unterschiede zu Konfigurationen zwischen Linux und Windows. Die Präsentation dazu ist zu finden als “Appelbaum-Data_Guard_für_Arme.pdf”

Im Wesentlichen sind zwei Skripte beteiligt:

1. Ein Script (stdby_sync.sh) zum Synchonisieren einer Standby Datenbank mit der produktiven Datenbank. Dieses Skript sollte auf dem Standby-Server ueber Crontab oder einen anderen Mechanismus regelmaessig (mehrmals in der Stunde) ausgeführt werden.
   Die Einzelschritte:
   • das aktuelle Redo-Log der Primaer-DB wird gewechselt
   • alle Online Redo-Logs der Primaer-DB werden archiviert
   • die Ziel-SCN (System Change Number) fuer das Recovery wird ermittelt
   • die Archivelog Dateien werden auf den Standby Server synchronisiert
   • die Archivelogs werden in der Standby-DB bis zur Ziel-SCN recovert
   • die Differenz der Logsequenzen zwischen Prod- und Standby-DB wird geprüft
     ggf. wird eine Warn-Mail versandt
2. Ein Script (archive_prim_remove.sh) zum Aufraumen der Archivelogs einer Primär-Datenbank. Dieses Skript sollte auf dem Primär-Server ueber Crontab oder einen anderen Mechanismus regelmaessig (einmal am Tag bzw. nach jedem Archivelog Backup) ausgeführt werden.
   Die Einzelschritte:
   • juengste Log-Sequence-Nummer im Backup ermitteln
   • juengste auf Standby-Datenbank recoverte Log-Sequence-Nummer ermitteln
   • Archivelog Dateien mittels RMAN bis zur ältesten der ermittelten
   • Log-Sequence-Nummern loeschen

Hier einige Auszüge aus den Skripten:

stdby_sync.sh

 

archive_prim_remove.sh

Interessant ist, dass sich die Standby-Datenbank unter Linux anders verhält als die unter Windows:
Unter Linux waren die recoverten Archivelogs in der View v$archived_log sichtbar, unter Windows dagegen war die View v$archived_log immer leer. Damit können die Archivelogs unter Windows nicht mittels des RMAN Befehls delete noprompt archivelog until sequence … auf dem Standby-Server gelöscht werden, auf dem Linux-Standby-Server geht das dagegen schon. Unsere aktuellen Skripte benötigen das allerdings nicht.

Am Ausstellungsstand von TEAM auf der DOAG 2013 Datenbank am 14. Mai 2013 konnte die Konfiguration in einer virtuellen Umgebung dann auch auf die Probe gestellt werden. Bei Interesse diese Installation zu begutachten, wenden Sie Sich bitte an TEAM oder direkt an mich.

ViewObject Query mit IN Where Clause

Anwendungsfall: Wir möchten zur Laufzeit die Abfrage an eine Datenbanktabelle durch eine Where-Clause IN Bedingung einschränken.

Beispiel: SELECT * FROM EMPLOYEES WHERE EMPLOYEE_ID IN (:dynamischeListe)

Problemstellung: Deklarativ bietet ADF nicht die Möglichkeit eine IN Abfrage innnerhalb eines ViewCriterias zu erstellen. Daher müssen wir an dieser Stelle ein ViewCriteria programmatisch erstellen.

Lösungsmöglichkeit:

Schritt 1 - Wir erstellen an dem gewünschten ViewObject eine JavaMethode, welche die IN Einschränkung durchführt.



(Die Methode kann natürlich auch auf andere Datentypen erweitert bzw. generell verallgemeinert werden.)

Schritt 2 - Wir stellen die Methode dem Client zur verfügung.

 

Schritt 3 - Test (hier mittels Test-JavaKlasse)

Was das folgende (gewünschte Ergebnis liefert)

Zum Testen: BC-ProgrammaticAdditionOfViewCriteriaINClause-11.1.1.6