ODBC Insert und gleich danach Selects

[goetzi]

Hallo Froum,

mich plagt folgendes Problem:
Ich mache über ODBC in eine Access Datenbank einen Insert. Im Anschluss aktuallisiere ich eine jTable mit den neuen Inhalten der Datenbanktabelle. Diese Aktuallisierung der jTable erfolgt direkt im Anschluß an den Insert. Allerdings wird unter diesen Umständen der neu hinzugekommene Datensatz nicht angezeigt.

Baue ich jedoch eine Zeitschleife zwischen Insert und Aktuallisierung (select) der jTable ein, wird der neue Wert angezeigt. Ich denke mal dass es eine Zeit braucht bis das Insert Statement über ODBC die Daten in die Access Datenbank geschrieben hat. Kann ich dies irgendwie abfragen wann das Insert Statement über ODBC fertig ist um erst dann mit der Programmausführung weiter zu machen ?

 

[Antoras]

Ich würde für beide Statements an die DB je eine Methode erstellen. Dann musst nur die Insert- und danach die Select-Methode aufrufen. Das ist übersichtlicher und funktioniert dann mit Sicherheit korrekt.

EDIT: Sonst zeig mal deinen Code. Ich kann mir nicht vorstellen, dass die DB da zu langsam ist. Ist das eine lokale DB oder liegt die auf einem Server?

 

[goetzi]

Die Datenbank liegt lokal. Ist die Sleep Anweisung in der Main Klasse aktiv, dann funktioniert alles tadellos. Ist sleep inaktiv, dann wird in die Tabelle test kein Datensatz eingefügt.

Main

package dbtest;
import java.sql.*;

public class Main {

    
    public static void main(String[] args) {
                ODBCInsert lw = new ODBCInsert();
		String abfrage = "insert into test (name,name2) values ('22','33')";
		
                try{
                lw.query(abfrage);
                //Thread.sleep(1000);		
                }catch (Exception e){System.out.println(e.getMessage());}
    
    
    
    
                ODBCSelect lw2 = new ODBCSelect();
		String abfrage2 = "select name from test";
		
                try{
                ResultSet res = lw2.query(abfrage2);
                		while (res.next()) {
                                    String name = res.getString("name");
                                    System.out.println("Ausgabe: " + name);
                                }
                }catch(Exception e){System.out.println(e.getMessage());}
    }
  
}

ODBCInsert

package dbtest;
import java.sql.*;

public class ODBCInsert {

	ODBCInsert(){
		
	}
	
    void query(String params) throws SQLException {
    
        // Laden des Treibers per Klassen-Loader
		try {
            Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
        } catch (ClassNotFoundException e) {
            System.out.println("Kann den Treiber nicht laden!");
        }

        // Verbindungs-Objekt erzeugen und konfigurieren
        Connection con = null;

        String db = "jdbc:odbc:" + "odbcname";
        

        try {
            con = DriverManager.getConnection(db);
        } catch (SQLException e) {
            System.out.println("Verbindung fehlgeschlagen! " + e.getMessage());
        }

        Statement state = null;

        try {
            state = con.createStatement();
        } catch (SQLException e) {
            System.out.println("Konnte kein Statement erzeugen");
        }
          
          state.executeUpdate(params);
        
    }
}

ODBCSelect

package dbtest;
import java.sql.*;

public class ODBCSelect {

	ODBCSelect(){
		
	}
	
    ResultSet query(String params)  {
    
        
		try {
            Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
        } catch (ClassNotFoundException e) {
            System.out.println("Kann den Treiber nicht laden!");
        }

        
        Connection con = null;

        String db = "jdbc:odbc:" + "odbcname";
        

        try {
            con = DriverManager.getConnection(db);
        } catch (SQLException e) {
            System.out.println("Verbindung fehlgeschlagen! " + e.getMessage());
        }

        Statement state = null;

        try {
            state = con.createStatement();
        } catch (SQLException e) {
            System.out.println("Konnte kein Statement erzeugen");
        }
        
        
        ResultSet res = null;
           try{
           res = state.executeQuery(params);
           }catch(Exception e){}
        return  res;
    }
}

 

[maki]

Die JDBC-ODBC Brücke ist schrott und sollte nie Produktiv verwendet werden, war nie mehr als eine Demo als es noch keine "richtigen" JDBC Treiber gab.

 

[goetzi]

Ich finde leider kein Beispiel unter Verwendung eines direkten JDBC MS Access Treibers. Alle Beispiele die ich bei google gefunden habe sind über die JDBC/ODBC Bridge realisiert.

Kann mir von euch noch jemand ein Tipp geben ?

 

[Antoras]

Für MS Access gibt es keinen direkten JDBC-Driver. Also entweder musst du mit der ODBC-Bridge leben, oder du steigst auf ein anderes DBMS um, was ich dir empfehlen würde. Da wäre z.B H2. Das ist ein super embedded DBMS, also ohne dämlichen Installationszwang und komplett in Java geschrieben.

 

[goetzi]

Vielen Dank, H2 hört sich gut an. Mit den jetzigen Phänomenen von der JDBC-ODBC Bridge kann ich leider nicht leben.

Danke EUCH !!

 

[goetzi]

Ich hab mich mit dem Thema H2 und Derby befasst. Leider bieten diese in der embedded Version nicht die Möglichkeit von mehreren Instanzen bzw. Clients auf das DB File zuzugreifen.

Grundsätzlich würde ich gerne das DB File auf einer Netzfreigabe liegen lassen und die Clients könnten über den embedded Mode unabhängig zugreifen. Was ich nicht will, ist dass zuerst eine Datenbank auf einem zentarlen System installiert werden muss.

Access über ODBC hätte sich da angeboten, hat allerdings die oben erwähnten Nachteile.

Könnt Ihr mir eine JAVA DB nennen, welche dies bietet ?

 

[Antoras]

Bei H2 gibt es schon die Möglichkeit das DBMS im Server-Modus zu starten, die Frage ist nur ob das viel Sinn macht, da die DB ja immer online sein müsste um als Server zu fungieren. Ansonsten hast du das Problem, dass die Clients sich nicht mehr verbinden könnten. Und wenn du die Daten untereinander synchronisierst um immer auf selbige zurückgreifen zu können, dann weist du nie wer gerade Server spielt und läufst Gefahr "Informationsinseln" entstehen zu lassen.
Aber wie gesagt, H2 kann in einem Server-Modus laufen, ob es bei Derby auch geht weiß ich nicht.