SOS
kann mir jemand helfen,
benötige informationen über die einzeln Funktion der OCI headerdateien,vorallem wo finde ich diese ??
Möchte gern sie in cpp einbinden um aus der Datenbank separat Daten in einer *.txt Datei abzulegen.
Danke
Shadow
Hallo!
Also wenns nicht unbedingt sein muss würde ich den Datanbankzugriff per OCI bleiben lassen, und stattdessen die CPP Datenbankklassen von ORACLE verwenden.
Unter Windows gibst dafür die oDatabase, oDynaset und noch viele andere.
Im Installationsverzeichniss von ORACLE gibts ein Directoy MSHELP.
Da drin ist eine Hilfedatei die die Verwendung der CPP Klassen (ORACLE nennt das OLE-DB for ORACLE) beschreibt.
Gruß Pauli!
SOS
kann mir jemand helfen,
benötige informationen über die einzeln Funktion der OCI
headerdateien,vorallem wo finde ich diese ??
Möchte gern sie in cpp einbinden um aus der Datenbank separat
Daten in einer *.txt Datei abzulegen.
Der Oracle Doku liegt ein Manual für dieses Interface bei. Solange du nicht die Anforderung hast, die SQL-Statemnts zur Laufteit ändern zu müssen, rate ich dir Embedded SQL zu verwenden. Du kommst wesentlich schneller zum Ziel, der Datenbankzugriff ist effizienter. Zum OCI gehört schon einiges an Hinergrundwissen, insbesondere wenn du von Datenbanken noch keinen Plan hast.
Gruß Markus
Vielen Dank,
super werde ich mich gleich mal dran setzen !!
1001 Danke
Shadow
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
1001 Danke !
Gruß Shadow
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Markus!
Der Oracle Doku liegt ein Manual für dieses Interface bei.
Solange du nicht die Anforderung hast, die SQL-Statemnts zur
Laufteit ändern zu müssen, rate ich dir Embedded SQL zu
verwenden.
Soweit stimme ich dir zu.
Du kommst wesentlich schneller zum Ziel,
Auch sicher richtig…
der Datenbankzugriff ist effizienter.
Aber wie zum Teufel kommst du auf DIE Idee??? Eher das Gegenteil ist der Fall (vorausgesetzt, derjenige, der die OCI-Schnittstelle programmiert hat, weiß was er tut).
Zum OCI gehört schon einiges
an Hinergrundwissen, insbesondere wenn du von Datenbanken noch
keinen Plan hast.
Da gebe ich dir wiederum recht, aber an Problematiken wie binding kommt man auch mit embedded sql nicht vorbei. Sprich: Mit DBs muss man sich in jedem Fall etwas eingehender beschäftigen, auch wenn’s um ganz andere Bereiche geht als z.B. beim Tuning von SELECTS.
Gruß Markus
Einen ebensolchen schönen,
Martin
der Datenbankzugriff ist effizienter.
Aber wie zum Teufel kommst du auf DIE Idee??? Eher das
Gegenteil ist der Fall (vorausgesetzt, derjenige, der die
OCI-Schnittstelle programmiert hat, weiß was er tut).
Du sagst es! Das Ausführen von prepare kostet enorm viel Rechenzeit, zudem stellt sich die Frage, ob jedes SQL-Statement ein eigenes Handle erhält oder ob alle sich eines teilen. Je nach Anwendung kann das sehr laufzeit-intensiv oder aufwendig seit. Embedded SQL ist bei der Ausführung sehr schnell und durch den Precompiler werden Programmierfehler vermieden. Wenn du mit dem OCI schon einmal prgrammiert hast, wirst du wissen dass es nicht einen Weg zum Ziel gibt, sondern viele. Dementsprechend viele Fehlerquellen gibt es …
Gruß Markus
Hallo Markus!
der Datenbankzugriff ist effizienter.
Aber wie zum Teufel kommst du auf DIE Idee??? Eher das
Gegenteil ist der Fall (vorausgesetzt, derjenige, der die
OCI-Schnittstelle programmiert hat, weiß was er tut).Wenn du mit dem OCI schon einmal
prgrammiert hast, wirst du wissen dass es nicht einen Weg zum
Ziel gibt, sondern viele. Dementsprechend viele Fehlerquellen
gibt es …
Habe ich (ich habe gerade die Umstellung von OCI7 auf OCI9 bei uns hier gemacht). Und, du hast natürlich recht, OCI ist weder trivial noch frei von Fallen. Da gibt’s wirklich eine Menge Dinge, die man falsch machen kann. Trotzdem ist es - richtig verwendet - mit Sicherheit effizienter als embedded SQL (das ja auch nur die OCI verwendet). Im Unterschied zu embedded SQL habe ich nämlich mit OCI eine Chance Dinge aktiv zu steuern, die der Precompiler bestenfalls richtig raten kann (ein Tipp: Man denke an Cursor-Sharing…)
Die Tatsache, dass etwas komplex ist, macht es nicht automatisch ineffizient; die falsche Verwendung natürlich schon, und das wiederum passiert wohl umso öfter, je komplizierter eine API ist - insofern hast ja doch irgendwie recht 
Gruß Markus
Gruß
Martin
Habe ich (ich habe gerade die Umstellung von OCI7 auf OCI9 bei
uns hier gemacht). Und, du hast natürlich recht, OCI ist weder
trivial noch frei von Fallen. Da gibt’s wirklich eine Menge
Dinge, die man falsch machen kann. Trotzdem ist es - richtig
verwendet - mit Sicherheit effizienter als embedded SQL (das
ja auch nur die OCI verwendet). Im Unterschied zu embedded SQL
habe ich nämlich mit OCI eine Chance Dinge aktiv zu steuern,
die der Precompiler bestenfalls richtig raten kann (ein Tipp:
Man denke an Cursor-Sharing…)Die Tatsache, dass etwas komplex ist, macht es nicht
automatisch ineffizient; die falsche Verwendung natürlich
schon, und das wiederum passiert wohl umso öfter, je
komplizierter eine API ist - insofern hast ja doch irgendwie
recht
Vor gut 1 1/2 Jahren habe ich einen Abstraktionslayer für C++ geschaffen, um Queries und Abfragen ausführen zu können. In der ersten Variante habe ich embedded SQL (dynamic method 4) verwendet. Vor kurzem habe ich die ganze Geschichte auf OCI umgestellt, etwa um vorverarbeitete Statements nutzen zu können. Der Aufwand war vergleichsweise hoch, die Ausbeute ist recht gering. Die Schnittstelle hat sich nach oben nicht geändert, erst im Lasttest zeigen sich die Vorteile: weniger cpu-intensiv, dadurch gering gesteigerter Durchsatz
Fazit: Embedded SQL ist grundsätzlich keine schlechte Wahl, und: embedded SQL arbeitet nich dem OCI zusammen, man kann also sowohl embedded SQL als auch OCI in einer Applikation verwenden. Die Doku geht sogar auf konkrete Beispiele ein.
In einem Punkt gebe ich dir vollkommen recht: Mit dem OCI hast du Kontrolle über sämtliche Details und kannst Feintuning vornehmen.
Gruß Markus