Eine APEX-Anwendung besteht nicht nur aus Seiten und Shared Components. SQL-Ausdrücke, PL/SQL-Prozesse, LOVs, Reports und REST-Abfragen verweisen auf Tabellen, Views, Packages oder einzelne Spalten. Wenn ein Datenbankobjekt umbenannt oder entfernt wird, fällt der Fehler manchmal erst im laufenden Prozess auf. Oracle APEX 24.2 bringt dafür einen ausgebauten Database Object Dependencies Report mit.
1. Report aus den Application Utilities öffnen
Öffnen Sie die Anwendung im App Builder und wechseln Sie zu Utilities → Database Object Dependencies. Mit „Scan Application“ starten Sie einen neuen Scan. Für eine vollständige Bestandsaufnahme wählen Sie den gesamten Application Scope. Wenn Sie nur bekannte Probleme untersuchen, kann ein Scan auf Fehler reduziert werden.
Das Ergebnis wird als Baum strukturiert. Typische Gruppen sind Tables, Views, Packages, Procedures und System Dependencies. Unter einer Tabelle können beispielsweise die verwendeten Spalten aufgeführt sein. Im Report sehen Sie Owner, Objektname, Component Property und den gefundenen Code; die Komponenteneigenschaft führt direkt zur APEX-Definition.
2. Vor einem Deployment gezielt suchen
Besonders wertvoll ist der Report vor einer Schema- oder APEX-Migration. Suchen Sie nach Objekten, die geändert werden sollen, und prüfen Sie alle abhängigen Komponenten. Bei einer geplanten Umbenennung einer Spalte gehören nicht nur direkte Reports auf die Prüfliste, sondern auch Validierungen, Computations, LOVs und Bedingungen.
Die Suche nach einem Objekt ist schneller und verlässlicher als das manuelle Durchsehen aller Seiten. Zusätzlich können Systemabhängigkeiten sichtbar werden, etwa Verweise auf APEX-Views oder Objekte der Datenbankadministration. Diese Hinweise sollten nicht automatisch entfernt werden: Dokumentieren Sie zunächst, ob die Referenz bewusst und für das Zielsystem verfügbar ist.
3. Fehler als eigenes Arbeitspaket behandeln
Ein fehlerhafter SQL- oder PL/SQL-Ausdruck kann dazu führen, dass eine Abhängigkeit nicht vollständig erkannt wird. Deshalb lohnt sich der Scan-Modus „Errors Only“ als eigener Schritt. Beheben Sie zunächst Syntax-, Berechtigungs- oder fehlende-Objekt-Fehler und führen Sie danach den vollständigen Scan erneut aus.
Der Report ersetzt keine Datenbankvalidierung. Prüfen Sie zusätzlich, ob Objekte im Ziel-Schema existieren, ob Grants vorhanden sind und ob Synonyme in der Zielumgebung gleich aufgelöst werden. Der APEX-Report beantwortet vor allem die Frage, wo die Anwendung ein Objekt erwartet.
4. Scan-Ergebnis aktuell halten
Abhängigkeiten sind eine Momentaufnahme. Nach Änderungen an APEX-Komponenten oder am Datenbankschema sollte der Report erneut gescannt werden. Verlassen Sie sich bei einem alten Ergebnis nicht darauf, dass es alle neuen SQL-Ausdrücke enthält. Für wiederkehrende Prüfungen kann die API APEX_APP_OBJECT_DEPENDENCY.SCAN in einen kontrollierten Wartungsprozess eingebunden werden.
Praktische Checkliste
- Vor Schemaänderungen einen vollständigen Application-Scan ausführen.
- Betroffene Tabellen, Spalten, Views und Packages im Baum auswählen.
- Über Component Property jede Fundstelle fachlich prüfen.
- „Errors Only“ separat verwenden und gemeldete Fehler beheben.
- Nach dem Fix erneut scannen und das Ergebnis für das Deployment dokumentieren.
Fazit
Der Database Object Dependencies Report in APEX 24.2 macht aus impliziten Verknüpfungen eine überprüfbare Landkarte der Anwendung. Das verkürzt die Suche bei Schemaänderungen, hilft bei Upgrades und zeigt fehlerhafte Referenzen früher. Entscheidend bleibt der Prozess: scannen, Fundstellen bewerten, Fehler beheben und vor dem Deployment erneut validieren.
Weiterführend: Database Object Dependencies in der APEX-Dokumentation, die APEX_APP_OBJECT_DEPENDENCY API und die Neuerungen in APEX 24.2.