Oracle SQL-Develper: object MY_TABLE does not exist

Setzt man im SQL-Developer folgendes Desribe-Statement ab:

describe MY_TABLE ;

erhält man nur folgende Fehlermeldung:

ERROR: 
------------------------------------------- 
ERROR: object MY_TABLE  does not exist

Wer jetzt genau hinschaut sieht, dass zwischen dem Tabellennamen und dem Semikolon ein Leerzeichen sich befindet. Sobald man das entfernt läuft auch das Statement sauber durch.

Betrifft Oracle SQL-Developer in Version 4.0.2.15


Hat Dir mein Beitrag gefallen?

Unterstütze meine Arbeit und werde noch heute Patreon!

Adam-Klasse

Neben den bestehenden Anti-Patterns denen man in der großen Welt der Softwareentwicklung begegnet habe ich nun eine neues Antipattern kennengelernt.

Die Adam-Klasse

Die Adamklasse ist wie ein Wunderwaffe gegen unsere alltäglichen Probleme: So wie wir Menschen (geht es nach der biblischen Version) alle von Adam und Eva abstammen, gilt dies auch für diese Art der Programmierung. Die Adamklasse stellt Grundfunktionalitäten für alle übrigen Klassen bereit und jede Klasse des Systems leitet sich von dieser Klasse direkt oder indirekt ab.


Hat Dir mein Beitrag gefallen?

Unterstütze meine Arbeit und werde noch heute Patreon!

ORA-00907: Rechte Klammer fehlt

ORACLE offeriert uns folgende Fehlermeldung:

ORA-00907: Rechte Klammer fehlt
 00907. 00000 - "missing right parenthesis"
 *Cause:
 *Action:
 Error at Line: 4 Column: 15

Es geht hierbei um das nachstehend geannte SQL, deren Sinnhaftigkeit irrelevant ist da das ursprünge SQL deutlich komplexer war, jedoch auf den ersten Blick technich korrekt erscheint – vor allem in Bezug auf die von ORACLE markierte Position:

SELECT *
  FROM users
 WHERE user_id != 100
   AND ( role_id IN (SELECT role_id
                      FROM userroles as r 
                     WHERE role_id NOT IN( 100 ) ) );

Die Analyse ergibt keine Fehler

  • Alle Klammern sind vollständig
  • Das SQL sieht fehlerfrei aus
  • Das Entfernen oder Ersetzen der äußeren IN-Bedingung löst die Fehlermeldung, lässt den Fehler jedoch nicht erkennen

Ursache

In der hier aufgeführten Query wurde ein Alias in der Subquery gesetzt welcher mit einem AS eingeleitet wurde, die von ORACLE jedoch als Tabellenalias nicht unterstützt werden. Die oben genannte Fehlermeldung führt einen nicht zu dem Problem an dieser Stelle.

Lösung

Die Aliaseinleitung AS entfernen und das SQL erneut ausführen.

Weitere mögliche Ursachen

Sollte die von mir geschilderte Problemlösung bei Dir nicht zutreffen kannst Du Deine Query auf folgende Punkte hin überprüfen:

  • Verwendung eines nicht erlaubten ORDER BY einer Subquerys oder innerhalb eines Joins:
SELECT *
  FROM users
 WHERE user_id != 100
   AND ( role_id IN (SELECT role_id
                       FROM userroles
                      WHERE role_id NOT IN( 100 ) 
                      ORDER BY role_id) );
  • Verwendung eines Joins mit Verweis einer Subquery:
...
LEFT JOIN userroles 
  ON userroles.role_id = ( SELECT max(role_id) 
                             FROM userroles )
...

Literatur zu diesem Thema:


Hat Dir mein Beitrag gefallen?

Unterstütze meine Arbeit und werde noch heute Patreon!

Screen auf der Linux-Konsole benutzen

Mittels screen ist man unter Linux in der Lage – verbunden über Putty und eine lange Serverlaufzeit ohne Neustart vorausgesetzt – ein schier endloses Linuxleben in ein und der selben Konsole zu führen.

Dies hat den Vorteil, dass längere Befehlsausführungen in einer eigenen Sitzung laufen können ohne diese Verbindung dauerhaft aufrecht erhalten zu müssen. Auch führt eine gescheiterte Netzwerkverbindung nicht dazu, dass die gesamte Sitzung abgebrochen wird sondern lediglich die Verbindung zu der Screen-Sitzung. Screen auf der Linux-Konsole benutzen weiterlesen


Hat Dir mein Beitrag gefallen?

Unterstütze meine Arbeit und werde noch heute Patreon!

Umstellung mysql auf mysqli

Mit PHP 5.5.0 wurden die alten mysql-Funktionen als deprecated markiert und seit PHP 7.0.0 gänzlich entfernt. Da inzwischen immer mehr Provider ihr Hostingangebote auf PHP 7 aktualisieren stehen diese Funktionen ab dieser Version dann gar nicht mehr zur Verfügung. Daher muss eine Umstellung dieser in den eigenen Projekten zwingend eingeplant werden. Dafür habe ich an dieser Stelle eine umfängliche Schritt-für-Schritt Anleitung zusammengestellt, welche bei sorgfältiger Abarbeitung einen innerhalb kurzer Zeit ziemlich sicher zum Ziel führt.

MySQL: Das umfassende Handbuch

Die Umstellung der mysql_*-Funktionen auf mysqli_*-Funktionen geht relativ reibungslos vonstatten, sofern man eine zentrale Verarbeitung der Datenbankabfragen implementiert hat. Ist dies nicht der Fall so wird sich der hier aufgeführte Aufwand um die Anzahl der zu behandelnden Stellen zuzüglich der notwendigen Tests in ungefähr multiplizieren.

Umsetzung

Für die Umstellung des eigenen Adapters muss man sich den nachfolgenden Punkten in jedem Einzelfall gesondert widmen und kann dazu wie folgt vorgehen:

  1. Im ersten Schritt ersetzt man alle mysql_ Funktionsaufrufe mit einem mysqli_. Das nachfolgende Suchpattern eignet sich hierfür sehr gut:
    /mysql_([a-z_]+)\(/
  2. In der Funktion mysqli_connect() werden ab dem vierten Parameter Port und Socket erwartet anstelle von link und clients. Sofern diese angegeben wurden müssen diese zunächst entfernt werden. Haben diese Angaben bisher darüber hinaus noch Relevanz gehabt so müssen jene an dieser Stelle gesondert behandelt werden.
  3. Die Funktionen mysqli_query()mysqli_error(), mysqli_escape_string() und mysqli_real_escape_string() benötigen nun zusätzlich die Angabe der Ressource. Dies kann für die beiden zuletzt genannten Funktionen an den Stellen problematisch werden, an denen eine Verbindung möglicherweise noch nicht hergestellt wurde oder die Ressource gar nicht erst verfügbar ist. Hier muss sichergestellt sein, dass diese vor dem ersten Aufruf aufgebaut wurde.
  4. In der Funktion mysqli_select_db() sind von nun an die beiden Parameter für Ressource und DB-Name vertauscht.
  5. Die vier Funktionen mysqli_fetch_assoc()mysqli_fetch_row()mysqli_fetch_object() und mysqli_fetch_array() liefern im Fall eines leeren Ergebnisses nun NULL wo ihre mysql-Pendants  hingegen bisher den Wert FALSE zurückgegeben haben.
  6. Andersherum jedoch liefert die Methode mysqli_stat() fortan FALSE anstelle von NULL sofern die Datenermittlung erfolglos stattgefunden hat.
  7. Prüfungen auf is_resource() sind nicht mehr möglich da der mysqli-Adapter keine PHP Ressourcen mehr darstellen sondern interne Klassenrepräsentationen.
    Konstrukte dieser Art:
    if( is_resource( $this->_link ) {     // ... }
    müssen überarbeitet und ersetzt werden gegen folgende Logik:
    if( $this->_link instanceof mysqli ) {     // ... }
  8. Die Funktion mysql_field_name() kann nicht ersetzt werden, da das entsprechende Pendant nicht existiert. Man muss es durch den nachfolgenden Schnipsel, Umsetzung in einer Klasse vorausgesetzt, ergänzen:
    private function field_name( $offset ) {
       $properties = mysqli_fetch_field_direct( $this->result, $offset );
       return is_object( $properties ) ? $properties->name : null; 
    }
    Anstelle von mysql_field_name( $resource, $offset ) erfolgt der Aufruf nun mit $this->field_name( $offset ).
  9. Der Abruf der Methoden mysqli_stat() und mysql_error() ohne Parameter ist nun nicht mehr zulässig und es muss die Ressource künftig mit angegeben werden.

Fazit

Ich stelle fest, dass eine Umstellung auf mysqli keine zeitaufwändige Angelegenheit ist und mit den wenigen notwendigen Tests innerhalb eines halben Arbeitstages nahezu mühelos erledigt werden kann.

Weiterführende Literatur


Hat Dir mein Beitrag gefallen?

Unterstütze meine Arbeit und werde noch heute Patreon!