Access Datenbank in .jar-Datei

[Dagobert]

Ich hab ein kleines Problem.
Ich hab eine Accessdatenbank. Diese soll in eine .jar-Datei mit hinein.
Aber wie kann ich nun eine Verbindung zu dieser Datenbank aufbauen?
Ich habe es so verscuht:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
		con = DriverManager
				.getConnection("jdbc:odbc:DRIVER={Microsoft Access Driver (*.mdb)};DBQ="+ClassLoader.getSystemResource("/resourcen/hdr.mdb").toString());

Aber irgendie Funktioniert das so nicht. :?:
Kann mir bitte jemand einen Tipp geben?
Und kann ich eine Datenbank in einer .jar-Datei editieren solange ich die .jar-Datei geöffnet habe, oder sollte ich sie erst irgendwo auf der Festplatte kopieren und dort dann alles machen?
mfg. Dagobert

 

[ms]

Nein, das geht so nicht.
Die Datenbank muss außerhalb des .jar-Files liegen.

ms

 

[L-ectron-X]

Du kannst nicht in Jar-Files schreiben, so lange du sie im Zugriff hast.

 

[Dagobert]

Aber wie kann ich denn dann die DB aus der Jar Datei in einen Ordner Kopieren?
Kann ich das über getClass machen?

 

[FArt]

Du könntest sie über den Classloader mit getResourceAsStream beziehen udn als File wegschreiben... ist aber irgendwie von hinten durch dir Brust ins Auge.

Liefer die Datei mit dem Programm aus... fertig.

 

[AlArenal]

Und warum muss es zwingend Access sein?

 

[Gelöschtes Mitglied 5909]

www.h2database.com <= die is gut imo

 

[Dagobert]

1. Warum nicht???
2. Weil ich kein extra Server laufen habe und ich die Date kopieren kann
3. Weil da nur ein par optionen/profiele usw gespeichert werden
4. Weil alles nur Lokal immer auf einem Rechner gebraucht wird

noch frage?
Ne antwort auf meine Frage hät mir mehr geholfen... ???:L :!:

Ok dann werde ich die DB dabei beilegen...

 

[tfa]

Die Antworten von AlArenal und raiL sind absolut hilfreich: Vergiss Access, nimm eine Datenbank!

 

[maki]

1. Warum nicht???

Weil Access so richtig mies ist, und die JDBC/ODBC Krücke nie fürt den Produktiven Betrieb voirgesehen war und laut Sun auch nicht dafür verwendet werden sollte.

2. Weil ich kein extra Server laufen habe und ich die Date kopieren kann

Na und, braucht man mit zB JavaDB/Derby auch nicht.

3. Weil da nur ein par optionen/profiele usw gespeichert werden
4. Weil alles nur Lokal immer auf einem Rechner gebraucht wird

Brauchst du bei meinen Vorschlag auch nicht.

Optionen/Profile speichert man am besten in properties.

Ne antwort auf meine Frage hät mir mehr geholfen... icon_scratch.gif

Hast du doch bekommen, klar sind keine "eleganten" Lösungen dabei solange du auf Access bestehst.

 

[AlArenal]

1. Warum nicht???
2. Weil ich kein extra Server laufen habe und ich die Date kopieren kann
3. Weil da nur ein par optionen/profiele usw gespeichert werden
4. Weil alles nur Lokal immer auf einem Rechner gebraucht wird

noch frage?
Ne antwort auf meine Frage hät mir mehr geholfen... ???:L :!:

1. Wenn es keine zwingenden technischen Gründe gibt, ist es u.a. aus den von den anderen Mitgliedern bereits angeführten Gründen keine gute Lösung über Java per JDBC/ODBC auf Access zuzugreifen.
2. Muss man auch nicht. Stichwort: Native Java DB / In-Process DB (Derby/JavaDB, hsqldb, h2, ...)
3. Umso besser.
4. So ist das immer - bis es sich mal ändert

Nö, sonst hab ich keine Fragen mehr.
Manchmal hilft es aber mehr zu bohren und bzgl. der Beweggründe nachzuharken / die grundlegende Situation zu analysieren, anstatt der Entscheidung eines Forum-Fragers blind zu vertrauen. So wie in diesem Fall.

 

[thE_29]

Hihi

Da hier ja mal wieder jeder gegen access, würde ich doch gerne mal ein Bsp mit h2 Java DB sehen und im File Betrieb bitte! (bitte bitte :bae

 

[Gelöschtes Mitglied 5909]

sowas?

// H2ObjectDatabase.java
// Project: h2o
// Author: Liar
// 28.05.2008 20:50:04

package h2o;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import org.h2.jdbcx.JdbcDataSource;

/**
 * @author Liar
 */
public class H2ObjectDatabase {

	public final static int		CACHE_SIZE	= 10000;

	private final static String	CREATE		= "CREATE TEMPORARY TABLE IF NOT EXISTS TEMPORARY_OBJECTS (OBJECT OTHER)";
	private final static String	INDEX		= "CREATE INDEX IF NOT EXISTS OBJECT_INDEX ON TEMPORARY_OBJECTS(OBJECT)";

	private final static String	INSERT		= "INSERT INTO TEMPORARY_OBJECTS(OBJECT) VALUES(?)";

	private final static String	CLEAR		= "DROP ALL OBJECTS DELETE FILES";

	private final static String	SELECT		= "SELECT OBJECT FROM TEMPORARY_OBJECTS";

	private final static String	SELECT_ASC	= "SELECT OBJECT FROM TEMPORARY_OBJECTS ORDER BY OBJECT ASC";

	private final static String	SELECT_DESC	= "SELECT OBJECT FROM TEMPORARY_OBJECTS ORDER BY OBJECT DESC";

	private Connection			connection;
	private int					cache;

	public H2ObjectDatabase( int cacheSize ) {
		cache = cacheSize;
	}

	public H2ObjectDatabase() {
		this(CACHE_SIZE);
	}

	public void init() throws SQLException, ClassNotFoundException {
		Class.forName("org.h2.Driver");
		JdbcDataSource datasource = new JdbcDataSource();
		datasource.setURL("jdbc:h2:file:~/.h2/data;CACHE_SIZE=" + cache);
		datasource.setUser("SA");
		datasource.setPassword("");
		connection = datasource.getConnection();
	}

	public void create() throws SQLException {
		PreparedStatement preparedStatement = connection.prepareStatement(CREATE);
		preparedStatement.execute();
		preparedStatement.close();
		preparedStatement = connection.prepareStatement(INDEX);
		preparedStatement.execute();
		preparedStatement.close();
	}

	public void insert( Object object ) throws SQLException {
		PreparedStatement preparedStatement = connection.prepareStatement(INSERT);
		preparedStatement.setObject(1, object);
		preparedStatement.execute();
		preparedStatement.close();
	}

	public ResultSet select() throws SQLException {
		PreparedStatement preparedStatement = connection.prepareStatement(SELECT);
		return preparedStatement.executeQuery();
	}

	public ResultSet selectAscending() throws SQLException {
		PreparedStatement preparedStatement = connection.prepareStatement(SELECT_ASC);
		return preparedStatement.executeQuery();
	}

	public ResultSet selectDescending() throws SQLException {
		PreparedStatement preparedStatement = connection.prepareStatement(SELECT_DESC);
		return preparedStatement.executeQuery();
	}

	public void clear() throws SQLException {
		PreparedStatement preparedStatement = connection.prepareStatement(CLEAR);
		preparedStatement.execute();
		preparedStatement.close();
	}

	public void close() throws SQLException {
		connection.close();
	}

}

edit: schon wieder sind die scheiss tabs im eimer 0o

 

[thE_29]

Sehr fein

Und der speichert die DB aber nicht so ab, indem er alle Befehle beim Starten wieder ausführt?

 

[Gelöschtes Mitglied 5909]

nö, sind verschiedene files auf der platte für daten, index und so

C:\Dokumente und Einstellungen\Liar\.h2

data.1.log.db
data.data.db
data.index.db

 

[thE_29]

Woohoo! Eine einzige Datei wäre mir zwar lieber, aber was solls

Ich danke dir! EOD

 

[L-ectron-X]

Ich hätte dann auch noch einige Fragen dazu:

Wie man auf Datenbankserver im Netzwerk zugreift, weiß ich. Aber wie läuft das hier in diesem Fall, wenn die Datenbank im File-Modus läuft? Wo liegt dann z.B. die Jar-Datei? Wohin werden die DB-Dateien gespeichert? Spricht man dann immer noch von einem Datenbankserver? Können sich mehrere Clients gleichzeitig verbinden?

Mit einer Access-DB geht sowas noch - mit einer einzigen Datei, die auch irgendwo im Netzwerk liegen kann. Man braucht nicht mal MS-Access installiert zu haben. Allerdings läuft das Programm nur noch unter Windows.

 

[tfa]

Die JAR-Datei liegt ganz normal im Klassenpfad. Die DB-Dateien werden im aktuellen Benutzerverzeichnis abgelegt, wenn man das nicht anders angibt. Bei JavaDB kann man in der JDBC-URL auch einen absoluten Pfad eingeben, z.B.:

jdbc:derby:D:/Projekt/Database/testdb;create=true

Wenn die Datenbank im Embedded-Modus läuft, kann sich kein weiterer Client verbinden. Es gibt aber auch einen Server-Modus, bei dem das möglich ist. Das ist dann aber nicht mehr Embedded, d.h. ein eigener Prozess für den DB-Server muss laufen.

 

[thE_29]

Wenn die Datenbank im Embedded-Modus läuft, kann sich kein weiterer Client verbinden

Tjo, dann bleib ich weiterhin bei Access, den das ist ein wichtiges Kriterium

 

[tfa]

Gibt's denn bei Access einen Embedded-Modus?
Ich dachte immer, wenn bei Access die Clientanzahl größer ist als 1 ist das Ding überhaupt nicht mehr vernünftig zu gebrauchen.

 

[thE_29]

Warum sollte es nicht mehr zu gebrauchen sein?
Geht tip top! Nur sollten die Daten unter 1 GB sein!

Rewe Deutschland ist zZ noch dabei in gewissen Filialen von Access auf SQL Server umzusteigen. (zwar nicht für die Warenwirtschaft, aber für die ganzen Kassendaten)

 

[maki]

5-10 User sind das Maximum unter Access, selbst dann wird das ganze sehr langsam und die Datenkonsistenz ist so 'ne Sache...

 

[thE_29]

Weiß nicht wo ihr alle eure Gegenargumente von Access her habt..
http://de.wikipedia.org/wiki/Microsoft_Jet_Engine

Max. 255 (real 80 und schreibend 10).

Also mind. 10 mal mehr User als bei der Java DB im Embedded Modus!

 

[AlArenal]

Rewe Deutschland ist zZ noch dabei in gewissen Filialen von Access auf SQL Server umzusteigen. (zwar nicht für die Warenwirtschaft, aber für die ganzen Kassendaten)

Ich kenne Läden, die sind noch dabei von proprietären Flatfile-DBs auf irgendwas anderes umzusteigen - weil alles andere besser ist. Aber was sagt uns das?

 

[tfa]

Max. 255 (real 80 und schreibend 10).

Ganz großes LOL!

Also mind. 10 mal mehr User als bei der Java DB im Embedded Modus!

Embedded-Modus ist eben nur für bestimmte Anwendungsfälle. Wenn mehr Clients nötig sind, nimmst du eben
den Server-Modus, dann klappt's auch mit mehr als 10 schreibenden Verbindungen.

 

[thE_29]

Najo, aber wenn ich eine kleine Anwendung schreibe, wo max. 5 User gleichzeitig drauf schreiben, will ich keinen Server einrichten!

Sondern leg das Access File auf ein Netzlaufwerk und bin glücklich.

@Al: Das sogar große Konzerne mit Access gearbeitet haben und glücklich waren. Und es anscheinend keine Probleme gab (im Gegensatz so wie ihr hier alle Access runtermacht).

Und wenn ich nen Server haben will, greife ich zur Oracle XE oder SQLServer Express und zur keine Java DB!

 

[L-ectron-X]

Und wenn ich nen Server haben will,...

Dann nehm ich PostgreSQL.

Aber was mache ich, wenn ich keinen DB-Server aufsetzen darf und das Ganze trotzdem netzwerkfähig sein soll?

 

[thE_29]

Jo, Postgres ist auch nicht so verkehrt!

Tjo, bis max. 10 User bleibt dir nix anderes als Access anscheinend übrig.

Maybe gibts ja auch ne andere DB im Embedded Modus...

 

[AlArenal]

@Al: Das sogar große Konzerne mit Access gearbeitet haben und glücklich waren. Und es anscheinend keine Probleme gab (im Gegensatz so wie ihr hier alle Access runtermacht).

Dem liegt diese verniedlichende Vorstellung zugrunde, dass in großen Konzernen alles immer super-tipptopp läuft. Deren Haufen stinken aber genauso wie die jedes anderen Erdenbürgers auch. Die haben zwar zertifizierte Prozessketten bis zum Klogang, aber wer meint dort wäre jede Entscheidung über alles erhaben, "denn sonst wären die ja nicht da, wo sie jetzt sind", irrt. Und je größer die Firma, desto größer in der Regel der Irrtum.

Irgendein Schreibtischtäter in Abteilung XY kam / kommt irgendwann auf die Idee sich mal was in Access etwas zu stricken, um sich selbst das Leben einfacher zu machen. Ein Zweiter sieht es und schon benutzt es die Abteilung. "Ach, das ist aber hübsch bunt und so, das können wir doch auch noch hier und da erweitern und schwupps haben wir die Endlösung". Was man dann oft hat, ist die Kacke am Dampfen - big time! So habe ich schon Warenwirtschaftssysteme, Projektmanagementsysteme, QM-/UM-Systeme, etc. gesehen....

Ich kenne (nicht ganz) zufällig auch so ein paar Access-Fraggles. Die kamen auch vor Äonen wie die Jungfrau zum Kind ins Thema und wurden dann als ehemals Externe abgeworben / eingestellt, um Uralt-Access-Ungetüme irgendwie am Laufen zu halten, da sonst keiner durchsteigt wie sie funktionieren. Da muss man mal alle Nase lang den Server neu starten, hier was tricksen, da was tricksen und Speed ist eh superübel, aber was solls?
Access ist so ein wenig das Cobol unter den Desktop-DBs

Schön ist auch, wenn jemand nen neuen Rechner bekommt, mit neuem Office 2007 (weil Office 2003 oder älter gibts ja nicht mehr zu kaufen). Reihenweise wird laut geschrien, weil die ollen Access-Teile nicht mehr funzen. Erst stutzt man wegen der doofen Sicherheitseinstellungen ("Wasn ditte!?"), dann funktioniert hier und da was nicht, weil MS mal einfach ganz cool war, Access-VBA-Funktionen ersatzlos zu streichen. Im Kleinen klappts bei denen wohl gut in Sachen Alte-Zöpfe-Abschneiden, nur bei Windows bekommen sie es mal wieder nicht auf die Kette...

Nen Bekannten von mir freuts. Er ist 32 und studiert noch ne Runde Informatik. Die wenige Freizeit, die er hat (weil er auch noch in ner Firma als ITler knechtet), lässt er sich mit €90 netto die Stunde versüßen. Wie praktisch, dass nun ständig Altkunden anrufen.. ;-)

 

[Gelöschtes Mitglied 5909]

Zu h2 db:

http://h2database.com/h2.pdf

Seite 29 vergleich zu anderen DBs

Seite 32 DB urls für h2

=> man kann den server auch mit SSL etc starten
und die files mit AES encrypten, angabe mit filepfad und so geht natürlich auch (~ entspricht user.home)

Es gibt tools (mitgeliefert) für backups der DB files,
einen eigenen query browser (webapp) und vieles mehr

 

[thE_29]

Btw.: http://www.java-forum.org/de/topic71165_problem-hochkomma.html in Access geht das ohne Problem

SCNR

 

[maki]

Btw.: http://www.java-forum.org/de/topic71165_problem-hochkomma.html in Access geht das ohne Problem

SCNR

Wobei erwähnt werden sollte, dass nur blutige Anfänger damit ein Problem haben...

Hab genug Ärger mit Access gehabt, weiss aus Erfahrung das ab 10 Users das Ding zur Hölle wird, davor ist es einfach nur nervig, gibt bessere und vor allem Portable Lösungen

 

[thE_29]

Naja, sag uns allen ein Produkt welches Embedded mehr als 10 Benutzer kann (also ohne Server).

Dann wären wir alle glücklich

 

[AlArenal]

Proprietäre Eigenschaften proprietärer Anwendungen sind denkbar schlechte Anforderungen, wenn man wirklich darauf aus ist Alternativen zu suchen.

 

[maki]

Was ist denn das Problem zB. die JavaDB als Server zu starten?

Abgesehen davon liegen in einem Unternehmen mehr als genug DB Server rum, eine DB anzulegen ist nicht schwer(login + SQL Script), musst ja nicht gleich den ganzen Server installieren.
Dafür bekommt man dann auch echte Datenkonsistenz, Backups, etc. pp., als das, worauf Nutzer bestehen wenn die Daten auch nur annähernd einen Wert haben.

 

[thE_29]

Es geht drum wenn es ein kleiner Betrieb ist oder etwas für die Familie! Da hat man am besten ein File wo rumliegen und keinen Server am Laufen.

Und die Java DB gehen ja alle als Filemode anlegen, nur max. 1 User (soviel zu proprietäre Eigenschaften @ Al :bae.

Und was hat ein Server mit Backups zum tun? Reißt der DB Server zusammen ist dort auch die komplette DB im Eimer! Und Konsistenz sind die Daten bei Access auch!

Und wenn ich heute an den Fehler in der Firma denke! SQLServer 2005 schafft es manchmal einen Primary Key 2mal zu vergeben! Das lustige ist, die DB regt sich erst dann auf wenn man diesen löschen will und blockiert dadurch alles.

 

[ms]

Naja, sag uns allen ein Produkt welches Embedded mehr als 10 Benutzer kann (also ohne Server).

Dann wären wir alle glücklich

Öhm ... vielleicht sollten wir nochmal den Begriff "embedded" genauer erläutern.
Heist für mich, dass eine Datenbank exklusiv von einem Programm mit direktem Zugrif verwendet wird, also eben nicht von anderen benutzt wird.

Rewe Deutschland ist zZ noch dabei in gewissen Filialen von Access auf SQL Server umzusteigen.
...
Es geht drum wenn es ein kleiner Betrieb ist oder etwas für die Familie!

Wie jetzt?
Das Familienaddressbuch oder Omis Kochrezeptdatenbank interessiert doch niemanden.

Das was AlArenal oben geschrieben hat kann ich aus leidiger Erfahrung nur bestätigen.
Irgendwer in einer Abteilung hat eine Idee, diese Idee wird mit Access schnell mal umgesetzt, es entwickelt sich, wächst und gedeiht. Mit der Zeit wird diese in Access umgesetzte Idee fast schon zur Notwendigkeit innerhalb der Abteilung aber es gibt kein Budget um es ordentlich zu machen. Ausserdem funktioniert es ja eh mit Access was ein gerechtfertigtes Budget für eine gescheite Lösung völlig absurd dastehen lässt.

Für wirklich kleine Sachen oder schnelle Prototypen mag Access ok sein weil es ja mehr - weil schnelle Frontends möglich - als nur eine Datenbank ist. Darüber hinaus rächt es sich aber irgendwann.

ms

 

[thE_29]

Ok, dann sag ich halt nicht embedded sondern eine DB im File Betrieb wo mehrere User drauf zugreifen können.

Und toll das du irgendwas zusammenzitierst was logisch überhaupt nicht zusammengehört (erinnert mich an noch jemanden hier im Forum).

Es geht darum das Rewe Deutschland noch immer Access im Einsatz hat und ein Kollege von mir gerade ein Konvertierungstool schreibt zu SQLServer.

Desweiteren meinte ich mit kleinen Betrieb oder für die Familie, das dort eine Access DB vollkommen reicht! Warum sollte ich da einen Server aufsetzen?!

Und tut mir leid, wenn sich Produkte heutzutage noch so entwickeln wie Al und du beschrieben hast.
Das mag vielleicht früher gewesen sein, aber heutzutage (hoffe ich halt und ich rede von den Unternehmen wo ich bereits gearbeitet habe) werden auch Vor/Nachteile abgewogen und dann entschieden und nicht weil Manager A sowas gut findet, obwohl es der totale Blödsinn ist.

 

[ms]

Ich habe gerade deswegen zitiert, weil Rewe nun sicher kein kleines Unternehmen ist aber trotzdem Access im Einsatz hat. Genauso wie in der Bank, in der ich diese Erfahrung gemacht habe. Und es sind genug Unternehmen die so Ihre IT-Landschaft aufbauen. Das Dilemma liegt ja daran, dass Access scheinbar sehr viel kann aber eben nicht wirklich. Eine .mdb auf einem Netzlaufwerk in die jeden Tag 400MB importiert werden (meine Erfahrung) ist ein Horror für denjenigen der sich darum kümmern darf.

ms

 

[Dagobert]

OMG
Was hab ich hier losgetreten.
Also für mein kleines vorhaben reicht Access locker aus, egal ob Preformance, Wartung o.a.
Wenn ich eine große DB brache würde ich softort wieder SQL nehmen...

 

[L-ectron-X]

...und immer noch wird um den heißen Brei geredet. Gibts nun eine Alternative, oder nicht?

Ich habe speziell das Problem, dass ich eine Anwendung mit Datenbankzugriff über Netzwerk schreiben soll, mir es aber nicht erlaubt wird, einen Server zu installieren (hab wegen PostgreSQL oder H2 angefragt). In die bestehenden Datenbänke darf ich auch nicht schreiben. Die Admins möchten eine oder mehrere Dateien, von einem Netzlaufwerk auf ein Netware-Server sichern. Ich brauche wohl also eine Datenbank, die ohne Server-Modus auskommt und in Dateiform irgendwo rumliegen kann. Lesend werden auf diese Datenbank nach bisherigem Stand etwa 15 - 20 Clients, schreibend (aber nicht gleichzeitig) etwa 8 - 10 Clients zugreifen. Access hat man abgenickt, aber wenn es sich vermeiden lässt, möchte ich lieber eine Alternative nutzen.
Hauptsächlich gehts den Admins nur um die Sicherung der Daten. Habt ihr da ein Tipp für mich?

 

[robertpic71]

Ich habe sowohl mit Access (noch von VBA-Zeiten), als auch mit H2 schon ein paar Projekte gemacht. Bevor auf Access "lostrete" noch ein paar Vorzüge von Access:

- einzig mir bekanntes DB-Produkt welches Daten über den Filezugriff sharen kann
- bei 1 PC Lösung, durch embedded schneller Programm mit ODBC/JDBC + lokale Datenbankserver (<500MB Daten)
- kein Server (aber aucht nicht möglich..)

Ich habe hier konzernweit einige Speditions-PC's im Einsatz (für das Einbuchen und Etiketten drucken). Bei der Access-Lösung ist alle paar Wochen die Datenbank defekt, obwohl darauf immer nur 2 PC's zugreifen.

Bei der anderen Lösung hatten wir auch regelmässig Probleme. Der Paketdienst (DHL) hat vor ca. 2 Jahren, die Accessdatenbank durch eine Firebird-DB eingetauscht, seither Null Probleme mit der DB.

Das waren jetzt Beispiele aus der MS-Welt. Bei Java spricht eigentlich noch weniger für Access.

Ich habe mit H2 im embedded, als auch im Serverbetrieb nur gute Erfahrungen gemacht. Das Ganze läßt sich übrigens auch kombinieren. D.h. ein Programm verbindet sich im Filemodus zu einer Datenbank und startet den TCP-Server für andere Clients.

Ich verwendete das z.B. für meinen Onlinekatalog. Der Webserver (+ Webuser) arbeitet mit der Datenbank im schnellen embedded Modus und stellt noch eine TCP-Anbindung bereits, damit z.B. Updates eingespielt werden können.

@ThE_29
Achja, die Datenbank umfasst mittlerweile 600MB und startet unter einer Sekunde. Bei den vielen Gemeinsamkeiten mit HSQL ist das ein wesentlich Unterschied der H2-Datenbank: Die Daten werden als Datenstruktur abgespeichert und nicht als SQL-Statements. Außerdem muss bei H2 nicht mehr alles in den Hauptspeicher passen.

@Dagobert
H2 bietet eine Jar/ZIP read-only Funktionalität, siehe auch: http://www.h2database.com/html/frame.html?features.html?highlight=jar#database_in_zip&main

Man könnte aber einfach beim Setup die Init-Datenbank(files) aus dem Jarfile mit ResourceAsStream hinauskopieren und auf die neuen Files mit h2 (h2:file:/pfad/db..) verwenden.

Nicht unüblich ist auch der Weg, sich die SQL-Befehle zur Datenbankerstellung inkl. Grunddaten in einem Textfile (im Jar) mitzunehmen und beim Setup SQL-Statements aus dem File auszuführen.

/Robert

 

[robertpic71]

Lesend werden auf diese Datenbank nach bisherigem Stand etwa 15 - 20 Clients, schreibend (aber nicht gleichzeitig) etwa 8 - 10 Clients zugreifen.

Bitte präzisier "nicht gleichzeitig schreiben". Heißt das wenig paralleler Betrieb oder es gibt den Zustand, dass jetzt nur ein Benutzer darf?

Folgende Strategie wäre mit H2 denkbar:
Man verwendet eine Read-Only-Connection (jdbc:h2:file:~/quickAndDirty;FILE_LOCK=NO) für alles lesenden Zugriffe. Für eventuelle Updates erstellt man eine eigene Connection mit Filelock. Zum Entsperren schließt man die Filelock-Verbindung.

Ob das so praktikabel ist hängt von der Anzahl Updates bzw. der Dauer der Updatesessions ab. Außerdem würde ich da im H2 Forum nochmal nachfragen.

/Robert

 

[L-ectron-X]

Möglicherweise werden höchstens 3 - 5 Clients gleichzeitig schreiben. Die parallen Schreibzugriffe werden recht selten vorkommen. Aber ich will mich da nicht festnageln lassen, was heute gesprochen wurde, kann morgen schon verhallt sein...

Derzeit werden mit der bestehenden Lösung jeden Tag etwa 20 - 30 Updates gemacht.

Kann man mit H2 eventuell festlegen, wo die DB-Dateien abgelegt werden sollen? Kann das dann auch ein Netzlaufwerk sein, welches für andere Clients ebenfalls erreichbar ist und somit die Netzwerkfähigkeit gewährleistet wird? Dann wäre das schon ausreichend. Die DB-Files könnten per Script verpackt und auf einem Netware-Server jeden Tag gespeichert werden.

 

[thE_29]

Die Daten werden als Datenstruktur abgespeichert und nicht als SQL-Statements. Außerdem muss bei H2 nicht mehr alles in den Hauptspeicher passen.

Woohoo! Das ist wirklich ein großer Vorteil

@ms: Ich habe hier lokal auf meinem PC eine Access DB um unsere Daten zu testen (unsere SW läuft entweder auf SQLServer 2005, Oracle XE oder Oracle Enterprise Serer 10) und es bucht eigentlich auch alles sauber ein! Problem ist nur, das mit den 1 GB. Dann muss man die DB komprimieren und sie hat nur noch 200MB!

 

[Gelöschtes Mitglied 5909]

Kann man mit H2 eventuell festlegen, wo die DB-Dateien abgelegt werden sollen? Kann das dann auch ein Netzlaufwerk sein, welches für andere Clients ebenfalls erreichbar ist und somit die Netzwerkfähigkeit gewährleistet wird?

Ich hab mit NFS shares bzw smb shares zum Teil schlechte Erfahrung gemacht, gerade auch was FileLocks betrifft, da nicht klar ist wer das regelt. Zusätzlich wird des bei nem Linux/Win Mix wohl Probleme geben => lieber als Server starten

 

[robertpic71]

Kann man mit H2 eventuell festlegen, wo die DB-Dateien abgelegt werden sollen? Kann das dann auch ein Netzlaufwerk sein...

Ja bei H2 kann man den Pfad angeben:
jdbc:h2:file:C:/Pfad/Datei
(ob auch ein UNC-Pfadg geht \\server\freigabe geht, habe ich noch nie probiert)

H2 arbeitet nicht mit Filelock des Filesystems sondern mit einer Lockdatei - das sollte etwas unempfindlicher sein.
Siehe auch H2 Doko Filelocks.

/Robert

 

[L-ectron-X]

D.h. also, wenn die Clients die Datenbankdateien an einer bekannten Position im Netz finden, können sie gleichzeitig darauf zugreifen, bzw. parallel die Datenbank auslesen und hineinschreiben?

 

[robertpic71]

D.h. also, wenn die Clients die Datenbankdateien an einer bekannten Position im Netz finden, können sie gleichzeitig darauf zugreifen, bzw. parallel die Datenbank auslesen..

Ja

und hineinschreiben?

Nein

Die Sperrlogik stellt nur sicher, dass nur einer die Datenbank mit Lock *Yes öffnen kann. Wie schon oben geschrieben, könnte man eine Verbindung für alle lesende Zugriffe (offen halten) und eine Verbindung für die Updates (mit Lock *YEs) öffnen und nach dem Update wieder schließen.

Alles in allem eher ein Plan B, wenn du sonst keine bessere Lösung findest. Offen sind noch die Fragen der Updateperformance und wie es um die Aktualität der lesenden Verbindungen steht wenn einer andere Job Updates seit dem Verbindungaufbau gemacht hat.

Aber vielleicht reicht für dich schon aus, wenn die Datei am Netzwerklaufwerk liegt und der Serverjob nicht am Server laufen muss.

/Robert

 

[Gelöschtes Mitglied 5909]

hab eben mal probiert 2 mal des gleiche mit einer h2 db im embedded mode auszuführen (2 mal die gleiche app mit h2 embedded auf gleiche file)->

Exception in thread "main" org.h2.jdbc.JdbcSQLException: Datenbank wird wahrscheinlich bereits benutzt: Locked by another process. Mögliche Lösungen: alle Verbindungen schliessen; Server Modus verwenden
Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-72]

ne andere möglichkeit wäre der read only mode, da würde es wohl gehn.