Ansi-Join provoziert Fehler

[p80286]

Vergiss die Adresse, bei drei Aufrufen war sie dreimal anders.
Wo zum .. kommt die DLL her? Tante G hat da nichts erhellendes gebracht, nur die üblichen Besserwisserseiten.

Gruß
K-H

[jobo]

Meine Theorie ist:
- offensichtlich kein "ORA-" Fehler, also ein Treiberproblem (OLEDB)
- Die Joinvarianten, die Du produzierst, sind nur der Auslöser, da sie
- vermutlich durch andere Ausführungspläne bzw. in einem Fall anderes Select Statement
-> andere Daten ausspucken
Da liegt dann der Hase im Pfeffer.
Der Treiber hat ein Problem mit den Daten.

Typischerweise sind das Date Werte vor Christi Geburt usw.

Vielleicht kannst Du das durch eingrenzen des selects nachvollziehen. Es müsste demzufolge ein Single Table Select reichen (ohne Join) um das Problem zu reproduzieren. (wenn man die fehlerhaften Daten erwischt)

Seit ich auf Oracle OLEDB umgestiegen bin (glaub aktuell Version 11.2 bei mir) hab ich sowas (Treiberprobleme mit Dateninhalten) allerdings nicht mehr erlebt.

P.S.: Hab grad erst die "OraOLEDBrst11.dll" im Post endeckt. Also 11er Oracle OLEDB Client?
Ist schon etwas her, aber ich erinner mich, dass ich "damals" den Instant Client 11.2 vorinstalliert habe und den OLEDB Teil aus den älteren "ODAC" Komponenten nachinstalliert. Um eben halt so aktuell wie möglich zu sein. Mittlerweile dürfte es ja wesentlich aktuellere Treiber geben.

[p80286]

Nee die Datenwerte aus der Steinzeit hab ich auch schon mal gehabt, das ist es nicht.
Es liegt einzig an dem "select Tab3.*" be dem ein Feld aus Using mit ausgegeben wird (werden sollte)
bloß gibts dann normalerweise einen richtigen ORA.Fehler.

Gruß
K-H

[Jumpy]

Und was ist wenn "using(idkey)" durch "on tab1.idkey=tab2.idkey" ersetzt wird?

[jobo]

Zitat von p80286:

Nee die Datenwerte aus der Steinzeit hab ich auch schon mal gehabt, das ist es nicht.
Es liegt einzig an dem "select Tab3.*" be dem ein Feld aus Using mit ausgegeben wird (werden sollte)
bloß gibts dann normalerweise einen richtigen ORA.Fehler.

Gruß
K-H

Wenn Du das schon weißt, was ist dann die Frage?
Das Tab3.* hat mit dem using eigentlich nichts zu tun, denn das using bezieht sich auf den Join von tab1 und tab2, während tab3 einen expliziten "on " Join hat (und das Asterisks gemurkse vom using nicht relevant sein dürfte). Daher dürften die komischen Feld Selektor Alias Automatismen (ich find sowas furchtbar) nicht greifen. Hat aber vielleicht irgendjemand bei Oracle selbst nicht verstanden und falsch programmiert.
Aber vielleicht hab ich es auch nicht verstanden

@Mikal: Ist das etwa Humor hier in der DP?!

[Bernhard Geyer]

Zitat von p80286:

Nee die Datenwerte aus der Steinzeit hab ich auch schon mal gehabt, das ist es nicht.
Es liegt einzig an dem "select Tab3.*" be dem ein Feld aus Using mit ausgegeben wird (werden sollte)
bloß gibts dann normalerweise einen richtigen ORA.Fehler.

Bei Oracle sollte man mit allem rechnen!
Während meiner Studienzeit hat es ein Mitkommilitone geschafft durch eine Select-Anweisung das ganz Uni-Netz lahm zu legen (ok, der Server auf dem die Oracle-DB lag war nicht nur DB-Server).

[jobo]

@Bernhard: Hast Du eigentlich irgendeinen Schwur gegen Oracle geleistet? Waren "sie" böse zu Dir?
Wie lang ist das her mit dem Studienkollegen?

Man braucht nur einen Join zu vergessen und die Datenbank permutiert durch die Gegend, da muss jede Datenbank ackern.

[Bernhard Geyer]

Zitat von jobo:

@Bernhard: Hast Du eigentlich irgendeinen Schwur gegen Oracle geleistet? Waren "sie" böse zu Dir?
Wie lang ist das her mit dem Studienkollegen?

Dieser Fehler: ca. 20 Jahre

Zitat von jobo:

Man braucht nur einen Join zu vergessen und die Datenbank permutiert durch die Gegend, da muss jede Datenbank ackern.

Bei jeder verfünftigen DB killt man einfach den Prozess der das Problem verursacht und gut ist. Nicht so hier bei Oracle.

Und einen "schwur" braucht man bei Oracle nicht. So oft wie man schon bei Oracle unnachvollziehbare Performanceprobleme hat. Ab und zu bringt es wenn der Server eh durch eine neuere Version aktualsiert werden. Ab und zu muss man praktisch den DB-Inhalt rauspumpen und die DB platt machen bis es wieder geht. Das erschreckende ist auch öfter das die Oracle-Admin (die sich oft als die Elite der DB-Admins ansieht) absolut kein Fachwissen von DB-Interne und gerade noch ihre Standardreports abrufen können die sie bei ihren nicht gerade billigen Oracle-DB-Schulungen durchgenommen haben.

[jobo]

20 Jahre! Da erübrigt sich eigentlich jeder Kommentar.
Dennoch, rechne ca. 10 Jahre drauf, zu der Zeit haben MS SQL Anwendung noch Probleme mit Rowlevel Locking gehabt.

Man braucht da auch gar nicht über verschiedene Anbieter die Nase zu rümpfen. Es reicht falsche Transaktionsverwaltung in der Anwendung und keine DB hat ne Chance, das ist mit Sicherheit kein Admin Problem.
Die Art und Weise, wie sich Schulungsinhalte oder-vorgehen entwickelt haben, reicht auch keinem Anbieter zur Ehre, es geht nur ums Geld verdienen.

Oracle Datenbanken hatten und haben nach meiner Meinung technologisch die Nase vorne. Nicht mehr und nicht weniger. Wahrscheinlich sind sie auch deswegen am komplexesten in der Administration. Ich hatte bereits das "Vergnügen" Terrabyte Systeme zu verwalten- ohne Admin Titel. Die von Dir genannte "Tuning" Technik ist da einfach aus Platzgründen nicht ohne weiteres möglich, ganz abgesehen von der Tatsache, dass sich sowas bei einem 24x7 System von allein verbietet.

Ganz anders sieht die Sache schon bei anderen Oracle Produkten aus. Und bei Oracle-Produkten in der Microsoftwelt merkt man immer wieder, dass es nicht ihre ist. Im übrigen ist es so, dass jedes Software-System eine Geschichte hat, die es idR nicht verleugnen kann. "Best practise" ist hierzu ein schönes (Microsoft- glaub ich) Stichwort. Wenn man ein System so nutzt, wie es gedacht ist, fährt man am besten. (Hier wäre man vermutlich irgendwie wieder beim Thema des Threads angelangt, ANSI Joins sind bei Oracle erst spät(er) angeflanscht worden und ich verwende sie nur, wenn der Oracle Style zu umständlich wäre)

[mikhal]

Vielleicht hilft dir das weiter:

http://www.pcmaxutilities.com/wikidl...fix-guide.html

Grüße
Mikhal