'Müll'-Zeichen in FireDAC-Exception Message (Oracle 19c)

[mjustin]

Bei Exceptions, die bei ungültiger Syntax eines SQL Statements über eine FireDAC Query entstehen, enthält die Exception-Message ungültige Zeichen:



Die ungültigen Zeichen beginnen mit einem CR ($A) und einem Null-Byte. Der Datenbank-Zugriff erfolgt über Oracle InstantClient in Version 19.5. Mit einer anderen Oracle Version (12c) habe ich noch nicht getestet. Ist dies jemandem schon mal begegnet? Ich schaue später auch in der Delphi Bug-Datenbank nach. (update: unten oracle / firedac und oracle / exception habe ich keine Einträge gefunden. Dann müsste ich nun ein minimales Beispielprojekt erstellen ...).

[jobo]

Den Instant Client gibt es ja in verschiednen "Ausbaustufen". Ich erinnere mich, dass für eine Nutzung mit OLEDB diverse Extras installiert werden mussten.
Ich würde überprüfen, ob der Client allein sauber läuft und ordentliche Fehlermeldungen ausspukt, wenn man die gleichen falschen Statements einträgt. Das bedeutet beim Instant Client wahrscheinlich, dass man auch SQLplus oder so als Extra installieren muss. Weiß ich nicht mehr genau. (Alternativ ein anderes, vorhandenes DB Tool nutzen, das möglichst simpel den gleichen Instant Client nutzt. GgF. ein Java basierter Client wie sqldeveloper o.ä. oder irgendeine Test Version eines DB Tools.

[Bernhard Geyer]

Zugriff über ODBC (Firedac -> ODBC -> InstantClient)?
Geht nicht auch FireDac -> InstantClient?

Je mehr zwischenschichten, desto mehr Probleme.

[mjustin]

Vielen Dank für die Anregungen. Mit dBeaver (JDBC) erhalte ich keine besonderen Zeichen am Ende der Fehlermeldung. Mit Oracle 1c und 19c und FireDAC erhalte ich regelmäßig am Ende der 'normalen' Fehlermeldung (zum Beispiel "... ORA-00942: table or view does not exist") die in den Screenshots gezeigten #A #0 und weitere zufällige Bytes.

Meine Vermutung ist, dass beim Lesen des Fehlertextes aus der Oracle/ODBC Client DLL in den FireDAC Treiber ein Bug dazu führt, dass die Länge der Fehlermeldung fehlerhaft ermittelt wird, und dann mehr Zeichen als vorhanden ausgelesen werden. Bei Zugriff über den MS SQL ODBC Treiber tritt dieser Fehler bei gleichen SQL statements nicht auf.

[jobo]

Ich bin mir nicht mehr sicher, aber die JAR Treiber sind vielleicht autark? Also kein geeigneter Test für den Instant Client?
Und woher kommt der MS SQL ODBC Treiber? Instant Client > ODBC Modul > MS SQL ODBC?
Wie aktuell sind die Treiber bzw. passen sie zur Version der DB? (1c ist vermutlich 12c?) Die 12er Version ist ja auch nicht unbedingt frisch.

Und noch was anderes:
(Ich bekomme das aus dem Kopf leider nicht mehr zusammen)
Der Instant Client kann ja pur ohne Setup und erhöhte Rechte "installiert" werden. Also im Prinzip einfach Dateien irgendwo hinkopieren und los geht's. (Wenn man auch ODBC und Tools installiert, geht das ja schon nicht mehr so ohne weiteres). Was aber bei der puren Grundinstallation wichtig ist, der Suchpfad.
Wird der nicht angepasst und hat man zufällig ältere oder auch schlicht andere Oracle Installationen auf dem Rechner, dann geht das leicht in die Hose. Da Du von 12c schreibst, könnte das ja hier der Fall sein.
Auch eine Deinstallation des Oracle (Fat-)Clients oder anderer Oracle Produkte war zumindest früher so schlecht, dass Pfad und Umgebungsvariablen nicht ordentlich hinterlassen wurden. Dann stehen u.U. diverse Oracle Suchpfade im PATH und es ist etwas Glückssache, welcher vorne steht / zuerst gefunden wird.
Solche Probleme kann man relativ leicht durchtesten, wenn man mit der CMD Box im Oracle Client Installationsverzeichnis bleibt, dort die Umgebungsvariablen anpasst/durchändert und sein eigenes Programm von dort lokal startet, so dass es die dortige oci dll nehmen muss.

[mjustin]

Zitat von jobo:

Ich bin mir nicht mehr sicher, aber die JAR Treiber sind vielleicht autark? Also kein geeigneter Test für den Instant Client?
Und woher kommt der MS SQL ODBC Treiber? Instant Client > ODBC Modul > MS SQL ODBC?
Wie aktuell sind die Treiber bzw. passen sie zur Version der DB? (1c ist vermutlich 12c?) Die 12er Version ist ja auch nicht unbedingt frisch.

JDBC läuft direkt (ohne Zwischenhalt im InstantClient) von der Anwendung zum Server, daher hat man damit die ODBC und die FireDAC Schicht nicht im Spiel. MS SQL habe ich als alternatives DB System kontrolliert, es läuft natürlich nicht über den InstantClient. Ich habe aktuelle Treiber für Oracle 12 und Oracle 19 und ausser den InstantClient Installationen keine Oracle Tools installiert, und auch keine PATH Einstellungen für Oracle, d.h. die Installation ist vermutlich sauber. Ich prüfe das noch, Oracle 12 Clients kann man aktuell noch downloaden (12.1.0.2.0), es wird noch unterstützt.

Einen Kommandozeilen-Client habe ich nicht installiert, ich greife nur über ODBC auf die Datenbanken zu, und die ODBC-Konfiguration verwendet jeweils den zur Datenbank passenden InstantClient.

[jobo]

Das mit MS SQL habe ich falsch verstanden. Ich hatte an den MS Treiber für Oracle gedacht, aber Du sprichst von einer separaten MS SQL Installation? Die hat natürlich auch nichts mit dem Instantclient zu tun, nur eben auch Firedac.
Aber Du hast beide Oracle Clients, 12c und 19c auf dem System? Das bietet immerin Potential für Vermischung. Den 12c Client habe ich auch noch verwendet, aber das ist schon länger her.

Es geht ja nur darum, das Problem zu finden. Also einfach mal einen der beiden, den alten z.B., deinstallieren. Der 19er Client geht angeblich auch mit alten 12er DB. Also gibt es eh keinen Grund für 2 clients auf einem System.

[mjustin]

Der Bug wurde gefunden und auch schon korrigiert, leider kann ich den Bugfix hier nicht veröffentlichen.

Er entsteht in einer FireDAC ODBC Treiberklasse, darin wird der Rückgabewert der Client-DLL nicht korrekt ausgelesen.

(reproduziert bisher in Delphi 10.2, eine neuere Delphi-Version habe ich in der entsprechenden Systemumgebung leider nicht)