PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Mit Java zu Oracle ohne ODBC?


aths
2004-03-16, 22:56:15
Wie komme ich über Java an eine Oracle-Datenbank (Oracle 9.2) ohne ODBC zu nutzen?

EgonOlsen
2004-03-16, 23:36:20
Direkt über den entsprechenden JDBC-Treiber von Oracle. Kann man dort runterladen (nach Registrierung, wenn ich mich recht entsinne). Für jede halbwegs aktuelle Version von Oracle sollte es dort das passende geben.

Hier: http://otn.oracle.com/software/tech/java/sqlj_jdbc/index.html

aths
2004-03-17, 04:43:36
Wie binde ich das ein? Hat jemand einen Sample-Code, wie man eine Verbindung bekommt? (Connection aufbauen, SQL-Statement absetzen, Ergebnis zeilenweise ausgeben, Verbindung schließen.)

EgonOlsen
2004-03-17, 07:39:19
Etwa so (wobei man die Sache mit dem Treiber natürlich nicht ständig macht, sondern nur einmal in der Applikation). Der Treiber muss im Klassenpfad liegen. Habe das jetzt nicht wirklich getestet, aber ich hoffe ich habe nichts vergessen/übersehen...


private final static String DRIVER="oracle.jdbc.driver.OracleDriver";
private final static String URL="jdbc:oracle:thin:@xxx.yyy.zzz.ttt:port:schema";

try {
Driver driver=(Driver) Class.forName(DRIVER).newInstance();
DriverManager.registerDriver(driver);
Connection con = DriverManager.getConnection(URL, "User", "Password");
Statement stmt = con.createStatement();
ResultSet rs=stmt.executeQuery("SELECT * FROM person");

while (rs.next()) {
System.out.println(rs.getString("name"));
}

rs.close();
stmt.close();
con.close();
DriverManager.deregisterDriver(driver);
}
catch (Exception e) {
e.printStackTrace();
}


Ach ja, die App. muss natürlich java.sql.* importieren.

HellHorse
2004-03-17, 10:16:53
*räusper*
Den Driver Manager zu Verwenden um Connections zu erhalten ist veraltet.
Das macht man besser über Datasources

http://java.sun.com/j2se/1.5.0/docs/api/

A factory for connections to the physical data source that this DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection.

Der Meinung ist auch Oracle (FAQ)

DataSources provide a more flexible way to create Connections. Once you have a DataSource, getting a connection from a DataSource is just as easy as using the DriverManager. DataSources were designed to be used with JNDI, but you don't have to use JNDI to use DataSources. DataSources can do things other than just create new connections. In particular, a DataSource can implement a connection cache. DataSources are now the preferred way to create a Connection.

The simplest way to get a connection from a DataSource is as follows:

ds = new oracle.jdbc.pool.OracleDataSource();
ds.setURL(myURL);
conn = ds.getConnection(user, password);

Which connection cache should I use, OracleConnectionCacheImpl or the new Implicit connection cache?

You should use the new Implicit connection caching mechanism. This new connection caching mechanism is driver independent. It provides the connection caching mechanism via the OracleDataSource, and supports plenty of new features such as connection attributes to stripe and reuse connections, connection manager per VM to manage one or more connection caches, abandoned connection timeout to reclaim idle checked out connections etc.

Note that the old connection cache, OracleConnectionCacheImpl is deprecated.


Transaktionen werden gemacht indem man per setAutoCommit(false) (http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Connection.html#setAutoCommit(boolean)) das autocommitting deaktiviert und dann, wenn alles fertig ist per commit() (http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Connection.html#commit()) commitet.

Transaktionscode sieht dann etwa so aus:

public class JDBCTest {
public static void sqlSomething(Datasource ds) throws SQLException {

Connection conn = null;
Statement stmt = null;
try {
conn = ds.getConnection();
stmt = conn.createStatement();

conn.setAutoCommit(false);
stmt.execute("SOME SQL QUERY");
conn.commit();
} catch(SQLException sqlex) {
if (conn != null) {
conn.rollback();
}
throw sqlex;
} finally {
if (stmt != null) {
stmt.close();
}

if (conn != null) {
conn.setAutoCommit(true);
conn.close();
}
}
}
}


JDBC FAQ von Oricale
http://otn.oracle.com/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm

Oracle JDBC Code Samples
http://otn.oracle.com/sample_code/tech/java/sqlj_jdbc/index.html

Oracle JDBC How-To
http://otn.oracle.com/sample_code/tech/java/codesnippet/jdbc/index.html

JDBC Tutorial von Sun
http://java.sun.com/docs/books/tutorial/jdbc/index.html

Einen besonderen Blick verdienen Prepared Statements
http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html

aths
2004-03-17, 10:38:13
Transaktionen sind afaik gar nicht notwendig, es zählt nur der Datenbankzugriff, das muss nicht unbedingt via einer Transaktion geschehen.

Z. B. wüsste ich jetzt nicht, wozu ds.setURL(myURL); gut sein sollte?

edit: Nachher poste ich mal einen Source, den ich für DB2 habe. Dieser Source (der mich an EgonOlsens Beispiel erinnert) soll so angepasst werden, dass man mit Oracle arbeiten kann.

HellHorse
2004-03-17, 10:58:45
Original geschrieben von aths
Transaktionen sind afaik gar nicht notwendig, es zählt nur der Datenbankzugriff, das muss nicht unbedingt via einer Transaktion geschehen.

Z. B. wüsste ich jetzt nicht, wozu ds.setURL(myURL); gut sein sollte?

edit: Nachher poste ich mal einen Source, den ich für DB2 habe. Dieser Source (der mich an EgonOlsens Beispiel erinnert) soll so angepasst werden, dass man mit Oracle arbeiten kann.
Serveraddresse + Port + Datenbankname oder so, das ganze irgendwie formatiert
geschätzt:
127.0.0.1:1337/einedbname
RTFjavadoc wirkt hier wahre Wunder ;)

Mann kann das meist (geht im Fall von Oracle auch) umgehen indem man erst eine Datasource per Default Konstruktor erzeugt, und dann ein halbes Dutzend setter drüber jagt. Ich bevorzuge das gegenüber einem formattierten String, da es aus meiner Sicht übersichtlicher und klarer ist. Dann kann man auch getConnection() ohne Argumente verwenden.

http://otn.oracle.com/sample_code/tech/java/sqlj_jdbc/files/jdbc20/BatchUpdateSample/BatchUpdateSample.java.html

OracleDataSource ods = new OracleDataSource( );

// Set the driver type.
ods.setDriverType( "thin" );

// Set the database server name.
ods.setServerName( (String) prop.get( "HostName" ) );

// Set the database name.
ods.setDatabaseName( (String) prop.get( "SID" ) );

// Set the port number.
ods.setPortNumber( new Integer( (String) prop.get( "Port" ) ).intValue( ) );

// Set the user name.
ods.setUser( (String) prop.get( "UserName" ) );

// Set the password.
ods.setPassword( (String) prop.get( "Password" ) );

EgonOlsen
2004-03-17, 12:00:25
Original geschrieben von HellHorse
*räusper*
Den Driver Manager zu Verwenden um Connections zu erhalten ist veraltet.
Das macht man besser über Datasources
Ja, ab Java 1.4. Ist halt die Frage, ob man sich darauf festlegen kann/will. Zumindest hier inne Fürma gibt es noch viele Systeme mit 1.3 und der Umstieg findet erst gaaaannnzzz langsam statt.

HellHorse
2004-03-17, 12:48:55
Original geschrieben von EgonOlsen
Ja, ab Java 1.4. Ist halt die Frage, ob man sich darauf festlegen kann/will. Zumindest hier inne Fürma gibt es noch viele Systeme mit 1.3 und der Umstieg findet erst gaaaannnzzz langsam statt.

Das sind so Sachen, die ich nicht verstehe. 1.4 gibt es mittlerweile nun schon eine ganze Weile. Alles, was benötigt wird, ist eine neue VM.
Applikationen die mit 1.3 liefen, laufen auch mit 1.4. Selbst wenn sie explizit für 1.3 kompiliert wurden und Zeugs nutzten, dass mit 1.4 deprecated wurde.
Zudem hat man Speedgewinne (bei den Labezeiten und Ausführungszeiten) und unzählige Bugfixes.

Mit dieser Argumentation, könnte man auch schliessen, es sei am besten gegen 1.0 programmieren, dann kommt auch die Micro$~1 VM damit klar.

Ist es in der heutigen Zeit zuviel verlangt, dass eine Firma ihre Software einmal pro Jahr auf den aktuellen Stand (gemeint sind gartis Updates, nicht kostenplichte neue Versionen) bringt, schon nur um Sicherheitslücken zu schliessen?

aths
2004-03-17, 13:06:00
Original geschrieben von HellHorse
Serveraddresse + Port + Datenbankname oder so, das ganze irgendwie formatiert
geschätzt:
127.0.0.1:1337/einedbnameDer Zugriff soll nicht übers Web erfolgen, sondern auf dem eigenen PC. Deshalb mit der Loopback-IP? Wo kriege ich raus, welche Port-Adresse für Oracle eingestellt wurde?

edit: Hier das Programm für DB2:

import java.sql.*;
import COM.ibm.db2.app.*;
import COM.ibm.db2.jdbc.app.*;
import java.io.*;


public class FuenfSchritteDB2
{
public static void main(String[] args) throws Exception
{

// Verbindung definieren
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver");

// Verbindung unter dem Nutzer gast und Passwort leer oeffnen
Connection c = DriverManager.getConnection("jdbc:db2:test"," " ," ");

// Anfrage-Statement erstellen
Statement s = c.createStatement();

// Anfrage-Statement ausfuehren; Ergebnis-Tabelle erhalten
//ResultSet r = s.executeQuery ("SELECT * FROM kunde");

s.execute("create table test1 (spalte int)");

// Curser-Konzept anwenden, um Ergebnis auszulesen
// while(r.next())
//{ System.out.println(r.getInt("kunr") + " " + r.getString("name"));
//}

// Verbindung schliessen
c.close();
}
}Mein erstes Problem ist, den Treiber für Oracle einzubinden.

HellHorse
2004-03-17, 15:01:12
Also ich würde das etwa so machen

import javax.sql.DataSource;
import java.sql.Statement;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;

import oracle.jdbc.pool.OracleDataSource;
import com.ibm.db2.jcc.DB2SimpleDataSource;

public class FuenfSchritteJDBC {
private static String databasetype = "oracle";

public static void main(String[] args) throws Exception {
DataSource dataSource = getDataSource("127.0.0.1", "test", 7777, "gast", "");
//ev auch
// DataSource dataSource = getDataSource("localhost", "test", 7777, "gast", "");
doWork(dataSource);
}

private static void doWork(DataSource dataSource) throws SQLException {
Connection connection = null;
Statement statement = null;
try {
// Verbindung unter dem Nutzer gast und Passwort leer oeffnen
connection = dataSource.getConnection();

// Anfrage-Statement erstellen
statement = connection.createStatement();

// Anfrage-Statement ausfuehren; Ergebnis-Tabelle erhalten
ResultSet resultSet = statement.executeQuery ("SELECT * FROM kunde");

statement.execute("create table test1 (spalte int)");

//Curser-Konzept anwenden, um Ergebnis auszulesen
while(resultSet.next()) {
System.out.println(resultSet.getInt("kunr") + " " + resultSet.getString("name"));
}
} finally {
// Statement schliessen
if (statement != null) {
// schliesst automatisch auch das ResultSet
statement.close();
}

// Verbindung schliessen
if (connection != null) {
connection.close();
}
}
}

private static DataSource getDataSource(String serverName,
String databaseName,
int portNumber,
String userName,
String password) throws SQLException {
// hier könnte man auch config files lesen, oder argumente parsen
if (databasetype.equals("oracle")) {
return getOracleDataSource(serverName, databaseName, portNumber, userName, password);
} else if (databasetype.equals("ibm")) {
return getDB2DataSource(serverName, databaseName, portNumber, userName, password);
} else {
throw new RuntimeException("unsupported database type");
}
}

private static DataSource getOracleDataSource(String serverName,
String databaseName,
int portNumber,
String userName,
String password) throws SQLException {
OracleDataSource ods = new OracleDataSource( );

// Set the driver type.
ods.setDriverType("thin");

// Set the database server name.
ods.setServerName(serverName);

// Set the database name.
ods.setDatabaseName(databaseName);

// Set the port number.
ods.setPortNumber(portNumber);

// Set the user name.
ods.setUser(userName);

// Set the password.
ods.setPassword(password);

return ods;
}

private static DataSource getDB2DataSource(String serverName,
String databaseName,
int portNumber,
String userName,
String password) throws SQLException {
DB2DataSource db2ds = new com.ibm.db2.jcc.DB2SimpleDataSource();
// Create the DataSource object
db2ds.setDriverType(4); // Set the driver type
db2ds.setDatabaseName(databaseName); // Set the location
db2ds.setUser(userName); // Set the user
db2ds.setPassword(password); // Set the password
db2ds.setServerName(serverName);
// Set the server name
db2ds.setPortNumber(portNumber); // Set the port number
return db2ds;
}
}

Der Code "sollte" laufen, konnte aber nichtmal prüfen ob er kompiliert, da ich die entsprechenden Klassen nicht habe.
Achja, die portnummern, useraname, passwort und all das zeugs, müssen natürlich angepasst werden.

Damit es mit DB2 läuft muss die Klassenvariable databasetype auf "ibm" geändert werden.
Dort wo gearbeitet wird (doWork), ist keine Oracle spezifischer Code. Soll der Code nun für eine andere Datenbank laufen, muss ein Weg gefunden werden an eine DataSource zu kommen und getDataSource geändert werden.
Aufpassen muss man aber mit den Port Nummern. Ev könnte man getXXXDataSource() überladen, die Port Nummer weglassen und dafür den default port für die jeweilige DB nehmen.

Wo kriege ich raus, welche Port-Adresse für Oracle eingestellt wurde?
Den fragen, der es installiert hat? Manual?

Mein erstes Problem ist, den Treiber für Oracle einzubinden.
Treiber runterladen dem CLASSPATH hinzufügen und gut ist. (eigentlich müssen der Klasse noch die benötigten import statements hinzugefügt werden)
Der schlechteste Weg ist, die Umgebungsvariable direkt zu ändern.
Die meisten IDE's erlauben es, Packete dem aktuellen Projekt hinzuzufügen. Das solltest du mit dem Treiber machen.
Ansonsten ein build-tool wie ant verwenden. Sollte man eigentlich sowieso machen, um unabhängig von der IDE zu sein.

Der Zugriff soll nicht übers Web erfolgen, sondern auf dem eigenen PC. Deshalb mit der Loopback-IP?
Gedanken kann ich leider nicht lesen und ich brauchte irgend eine IP => war Glück
Aber ja, wenn es auf dem lokalen Rechner ist, dann "127.0.0.1" verwenden, ev auch "localhost".

EgonOlsen
2004-03-17, 15:26:22
Original geschrieben von HellHorse

Das sind so Sachen, die ich nicht verstehe. 1.4 gibt es mittlerweile nun schon eine ganze Weile. Alles, was benötigt wird, ist eine neue VM.
Applikationen die mit 1.3 liefen, laufen auch mit 1.4. Selbst wenn sie explizit für 1.3 kompiliert wurden und Zeugs nutzten, dass mit 1.4 deprecated wurde.
Zudem hat man Speedgewinne (bei den Labezeiten und Ausführungszeiten) und unzählige Bugfixes.

Mit dieser Argumentation, könnte man auch schliessen, es sei am besten gegen 1.0 programmieren, dann kommt auch die Micro$~1 VM damit klar.
Das ist schlicht und einfach eine Kostenfrage. Man braucht eine neue VM. Zu hause kein Problem, bei 500 Clients vor Ort und weiteren x Hundert (genaue Zahl weiß ich jetzt nicht) bei Tochterfirmen aber schon. Das macht man nicht mal "so eben". Das kostet Zeit für Abstimmung und Installation und damit schlicht Geld. Geld, das erstmal in den Wind geschossen ist, weil es keinen direkten Ertrag produziert.
Hinzu kommen Kunden, denen man plötzlich klar machen muss, dass sie ihre ganze Infrastruktur von 1.3 auf 1.4 anheben müssen. Nun spricht man da nicht mit den IT-Leuten...die würden das vielleicht aus ideologischen Gründen noch tun, sondern mit "wichtigen" Leuten. Und die sehen dann: "Was bringt mir das? Nix, sondern kostet nur? OK, dann lassen wir das erstmal."
Weiterhin laufen nicht alle Sachen so unter 1.4 wie unter 1.3. Vor allem bei Swing waren unter 1.3 Dinge nötig, um ein gewünschtes Verhalten zu erreichen, die bei 1.4. nicht mehr funktionieren oder sogar schaden. Diese Stellen muss man finden und korrigieren und das kostet mal wieder Zeit. Zeit, die für andere Aufträge fehlt und die damit doppelt Geld kostet.
Ferner ist es eine Frage der Entwicklungsumgebung. Wir verwenden JBuilder Enterprise und der ist teuer. Bis vor kurzem haben wir den 4er verwendet, nur der unterstützt kein 1.4. Also musste der 9er als Ersatzbeschaffung her und das kostet (wieder mal) Geld. Und wieder ist es Geld, welches erstmal weg ist und für andere Dinge fehlt.
Und last but not least müssen sich die Entwickler an die neue Umgebung gewöhnen. Das mag trivial klingen, aber für manche ist es das (leider) nicht. Nicht jeder hat Java (oder programmieren überhaupt) mit der Muttermilch eingetrichtert bekommen und muss trotzdem damit klar kommen.
War jetzt leider etwas OT, aber ich wollte mal darstellen, wieso das alles nicht "so einfach" ist, wie es auf den ersten Blick erscheint.

aths
2004-03-17, 17:03:19
Original geschrieben von HellHorse
Damit es mit DB2 läuft muss die Klassenvariable databasetype auf "ibm" geändert werden.In DB2 läuft der von mir gepostete Samplecode :) Ich brauchs allerdings für Oracle. Werde mal sehen, ob ich das mit Hinweisen aus deinem Beispiel hinkriege.

Original geschrieben von HellHorse
Den fragen, der es installiert hat? Manual?Ich hab's installiert. Kann mich nicht erinnern, dass er eine Portadresse haben wollte :kratz2:

BTW hab ich seit dem Reboot nach der Installation ein blödes Problem (http://ds80-237-203-42.dedicated.hosteurope.de/vbulletin/showthread.php?&threadid=131524).


Original geschrieben von HellHorse
Die meisten IDE's erlauben es, Packete dem aktuellen Projekt hinzuzufügen. Das solltest du mit dem Treiber machen.In Java progge ich nur, weil ich's muss. Ohne IDE (die ich ohnehin nicht vernünftig konfiguriert kriege) sondern mit notepad und Übersetzen / Starten via Kommandozeile.

EgonOlsen
2004-03-17, 17:08:24
Original geschrieben von aths
Ich hab's installiert. Kann mich nicht erinnern, dass er eine Portadresse haben wollte :kratz2: Probier mal 1521.

HellHorse
2004-03-17, 17:10:45
Ja, schon klar, aber OS und sonstige Software Office z.B. sollten ja auch geupdated werden. Deshalb schrieb ich ja auch einmal pro Jahr, und nicht ein Monat nach dem die neue Version rauskam.

Vor allem bei Swing waren unter 1.3 Dinge nötig, um ein gewünschtes Verhalten zu erreichen, die bei 1.4. nicht mehr funktionieren oder sogar schaden.
Bugs, oder lief es bloss anders (Focusmanagement ist mit 1.4 neu, wenn ich mich richtig erinnere)? Kannst du mir ein Beispiel nennen?

Haben sich die Leute überlegt, was passiert, wenn ein Kunde eine halbwegs aktuelle VM hat?

die würden das vielleicht aus ideologischen Gründen noch tun, sondern mit "wichtigen" Leuten. Und die sehen dann: "Was bringt mir das? Nix, sondern kostet nur? OK, dann lassen wir das erstmal."
Der ulitmative Grund für solche Leute:
Produktivität, da man weniger selbst schreiben muss.
Produktivität, da Workarounds für Bugs wegfallen.

EgonOlsen
2004-03-17, 17:20:01
Original geschrieben von HellHorse
Ja, schon klar, aber OS und sonstige Software Office z.B. sollten ja auch geupdated werden. Deshalb schrieb ich ja auch einmal pro Jahr, und nicht ein Monat nach dem die neue Version rauskam.Ich sage es mal so: Wir haben Office97 und Win NT4. Die Umstellung auf XP kommt demnächst und damit auch auf 1.4. Aber über einen angepeilten Jahresrhythmus kann man in größeren Unternehmen (und die paar hundert Leute sind ja nun nicht sooo viel) nur müde lächeln. Ein Jahr reicht da vielleicht gerade so aus, um zu erkennen, dass man etwas tun will...nicht um es zu tun... :D


Bugs, oder lief es bloss anders (Focusmanagement ist mit 1.4 neu, wenn ich mich richtig erinnere)? Kannst du mir ein Beispiel nennen?Nicht konkret, weil es nicht meine Spielwiese ist. Ich habe es nur gesehen: Eine Swingapplikation, die plötzlich überall den Focus hatte...leider gleichzeitig. Natürlich entsteht das, weil man irgendwelche Workarounds hingefrickelt hat, die sich jetzt rächen. Aber so ist nunmal die Welt. Leider...

Haben sich die Leute überlegt, was passiert, wenn ein Kunde eine halbwegs aktuelle VM hat?Ja, dann haben die eines: Pech gehabt. Die Anwendungen starten damit gar nicht, sondern sagen nur Ätsche Bätsche und Tschüß. Du musst dir "Kunden" in diesem Fall nicht so sehr als Endkunden wie du und ich vorstellen. Es ist etwas verworrener und die Kunden kommen alle aus einer Branche und wir diktieren dann eben Umgebung für die Anwendung. Finde ich auch Mist, aber anders bekommst du das nicht in den Griff.


Der ulitmative Grund für solche Leute:
Produktivität, da man weniger selbst schreiben muss.
Produktivität, da Workarounds für Bugs wegfallen. Schon mal versucht?

HellHorse
2004-03-17, 17:31:14
Original geschrieben von aths
In DB2 läuft der von mir gepostete Samplecode :) Ich brauchs allerdings für Oracle. Werde mal sehen, ob ich das mit Hinweisen aus deinem Beispiel hinkriege.

databasetype auf "oracle" lassen und es sollte laufen (korrekte Verbindungsparameter vorausgesetzt).
Original geschrieben von aths
Ich hab's installiert. Kann mich nicht erinnern, dass er eine Portadresse haben wollte :kratz2:

nmap?
Original geschrieben von aths
In Java progge ich nur, weil ich's muss. Ohne IDE (die ich ohnehin nicht vernünftig konfiguriert kriege) sondern mit notepad und Übersetzen / Starten via Kommandozeile.
Dann ist ant dein Freund. Den Spass krieg man hier:
http://ant.apache.org/

Ein Beispielhaftes build.xml
<?xml version="1.0" encoding="UTF-8"?>
<project basedir=".." default="run" name="JDBC for aths">
<property name="build.dir" value="${basedir}/build"/>
<property name="src.dir" value="${basedir}/src"/>
<property name="lib.dir" value="${basedir}/lib"/>
<path id="class.path">
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
<pathelement location="${build.dir}"/>
</path>

<target name="-init" description="makes the dirs">
<mkdir dir="${build.dir}"/>
</target>

<target name="compile" depends="-init" description="compiles the source">
<javac destdir="${build.dir}" srcdir="${src.dir}" classpathref="class.path">
</javac>
</target>

<target name="run" depends="compile" description="runs the app">
<java classname="FuenfSchritteJDBC" dir="${build.dir}" classpathref="class.path" fork="true">
</java>
</target>
</project>
Das File geht von folgender Struktur aus:

Im Projektverzeichnis gibt es einen Unterordner lib, in dem alle gebrauchten jars sind, hier kommen also die Treiber rein.
Im Unterordner src sind die Sourcefiles und das build.xml.
Die Sourcen werden in den Unterordner build (wird erstellt) compiliert.


Vorausgesetzt, du hast alles korrekt installiert, wechselst du per Kommandozeile (oder per "open command window here"-Powertoy) in den src Unterordner. Dort gibst du ant
ein, und die Sourcen werden kompiliert, der CLASSPATH gesetzt und die Sache wird laufen gelassen.

ethrandil
2004-03-17, 23:37:34
Original geschrieben von EgonOlsen
Hinzu kommen Kunden, denen man plötzlich klar machen muss, dass sie ihre ganze Infrastruktur von 1.3 auf 1.4 anheben müssen.
Warum packt ihr nicht einfach ein Java 1.4-Setup mit zu euren ausgelieferten Programmen?

- Eth

EgonOlsen
2004-03-17, 23:44:24
Original geschrieben von ethrandil
Warum packt ihr nicht einfach ein Java 1.4-Setup mit zu euren ausgelieferten Programmen?
Ich denke, das habe ich ausführlich erklärt. Ich sage ja auch nicht, dass ich das alles ganz toll so finde, aber so IST es nun einmal. Man kann damit leben oder sich halt arbeitslos melden...:D

HellHorse
2004-03-18, 07:38:06
@EgonOlsen

Ach wo, du gehst einfach vor das Konklave und beantragst einen "trial of grievance".
Alternativ kannst du die "wichtigen" Leute zu einem "trial of position" über ihren Job herausfordern, oder falls du den nicht willst und lieber deinen machst, die zu einem "circle of equals" und zur Vernunft prügeln.
Ich hoffe für dich bloss es ist nicht so, dass die einen Blutnamen haben und du nicht.
:D

aths
2004-03-21, 19:43:28
HellHorse,

Java nehme ich nur, wenn es sein muss. Bei größeren Sachen weigere ich mich schlicht, das überhaupt in Java zu machen. Insofern beschäftige ich mich jetzt nicht mit einer Entwicklungsumgebung. Hauptsache, mein Projekt ist fertig, zum Konfigurieren und sich-einarbeiten in eine IDE habe ich nicht den Nerv.

Nachher oder morgen versuche ich mal, den Treiber zum Oracle-Zugriff irgendwie einzubinden …

HellHorse
2004-03-21, 21:02:20
Eben genau dann sollte ant erste Wahl sein. ant ist eine Art make für/in Java (kannst auch make verwenden, wenn du willst).
Anstatt einem makefile hat man einfach ein build.xml.
Gepostetes build.xml fügt z.B. alle *.jar Dateien (so z.B. auch den Treiber) im /lib Unterverzeichnis dem Classpath hinzu.
Kompilieren und Ausführen geht dann ganz einfach von der Konsole aus, Optionen werden im build.xml gesetzt.

aths
2004-03-22, 10:04:04
Da müsste ich erst mal lernen, wie das erforderliche xml aussieht – nein danke. Einen Treiber per Hand in das Verzeichnis zu kopieren bzw. einzutragen, werde ich hoffentlich hinkriegen.

HellHorse
2004-03-22, 18:03:48
Original geschrieben von aths
Da müsste ich erst mal lernen, wie das erforderliche xml aussieht –
Wie das gepostete? :eyes:

aths
2004-03-24, 15:35:26
Bei dieser Zeile

OracleDataSource ods = new OracleDataSource( );

kommt der Fehler

unreported exception java.sql.SQLException; must be caught or declared to be thrown

Was tut man dagegen?

edit: Am besten, ich lass den Quatsch, und versuche, einfach dieses Programm
import java.sql.*;
import COM.ibm.db2.app.*;
import COM.ibm.db2.jdbc.app.*;
import java.io.*;


public class FuenfSchritteDB2
{
public static void main(String[] args) throws Exception
{

// Verbindung definieren
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver");

// Verbindung unter dem Nutzer gast und Passwort leer oeffnen
Connection c = DriverManager.getConnection("jdbc:db2:test"," " ," ");

// Anfrage-Statement erstellen
Statement s = c.createStatement();

// Anfrage-Statement ausfuehren; Ergebnis-Tabelle erhalten
//ResultSet r = s.executeQuery ("SELECT * FROM kunde");

s.execute("create table test1 (spalte int)");

// Curser-Konzept anwenden, um Ergebnis auszulesen
// while(r.next())
//{ System.out.println(r.getInt("kunr") + " " + r.getString("name"));
//}

// Verbindung schliessen
c.close();
}
}so umzuschreiben, dass es JDBC für Oracle nutzt. Dazu habe ich eine classes12.zip heruntergeladen. Welche .class-Files brauche ich davon?

EgonOlsen
2004-03-24, 16:26:02
Du müsstest das entweder in einen try-catch-Block packen oder die eventuell auftretende Exception nach oben durchreichen. Dein Programm tut genau dies in der main()-Methode (throws Exception).
Die classes12.zip nimmst du einfach so, wie sie ist und packst sie zum Klassenpfad dazu. Ob die nun .jar oder .zip heißt ist Java egal. Explizit auspacken musst du sie nicht.

aths
2004-03-24, 16:31:06
Welche Files aus dem .zip muss ich importen? Ist der Rest im Programm JDBC-Standard, also nicht Oracle-abhängig?

EgonOlsen
2004-03-24, 16:41:52
Nix. Der Name des Treibers liegt ja nur als String vor. java.sql.* sollte reichen. Wieso das Programm die IBM-Suppe importiert, ist mir nicht klar. Jedenfalls nicht, falls das da das ganze Programm ist.
Der Rest (d.h. Connection, Statement, ResultSet...) ist JDBC und für alle gleich. Höchstens deine SQLs könnten anders sein...da musst du gucken, wo die Unterschiede zwischen DB2 und Oracle sind und ob die für deine Abfragen relevant sind. "select * from tralala" können alle...

aths
2004-03-24, 18:27:01
Danke erst mal soweit für die Hilfe! Heute komme ich nicht mehr dazu, noch was zu machen, morgen mache ich mich aber frisch ans Werk.

HellHorse
2004-03-24, 18:37:18
Original geschrieben von aths
Bei dieser Zeile

OracleDataSource ods = new OracleDataSource( );

kommt der Fehler

unreported exception java.sql.SQLException; must be caught or declared to be thrown

Was tut man dagegen?

Der Compiler sagt's ja eigentlich.
must be caught or declared to be thrown
Also entweder abfangen (try-catch-Block) oder deklarieren (throws SQLException in den Methodenkopf), habs angepasst.

aths
2004-03-25, 12:31:09
Im Source für DB2 steht:
// Verbindung definieren
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver");Wie lautet der Treibername für Oracle?

// Verbindung unter dem Nutzer gast und Passwort leer oeffnen
Connection c = DriverManager.getConnection("jdbc:db2:test"," " ," ");Um die Connection zu kriegen, kann ich wohl kaum mit DB2 antanzen. Was nimmt man für Oracle?

HellHorse
2004-03-25, 13:56:11
1. Frage die Hure (http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=oracle+forName+9i&btnG=Google+Search) meint:
oracle.jdbc.OracleDriver

2. Frage, das fm (http://otn.oracle.com/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm#05_00) meint:
DriverManager.getConnection("jdbc:oracle:thin:@//myhost:1521/orcl", "user", "password");

aths
2004-03-25, 16:13:18
Benutzername und Passwort meine lokalen Oracle-Installation lauten fantasielos Oracle // Oracle. Allerdings komme ich in die Manager-Konsole nur als SYSDBA rein (weiß der Teufel, warum.) Wie erkläre ich JDBC, dass ich gerne als User Oracle, aber in Funktion des SYSDBA connecten möchte?

aths
2004-03-28, 14:37:09
Huh?