Mit NexusDB arbeiten wie mit der BDE

[Captnemo]

Hallo,

ich hab mir grad im Internet die NexusDB angeschaut. Bin mir aber nicht sicher, ob sie das, was ich machen will, so kann. Vielleicht weiß das ja einer von euch.
Ich möchte mit der NexusDB quasi so arbeiten, wie mit der BDE.

Also eine DB erstellen, die ohne Serverkomponente auskommt, wo von verschiedenen Rechner zugegriffen werden kann, und die Tables / Datensätze gesperrt werden können. Geht das so ohne weiteres mit der NexusDB? Oder ist da eine andere DB besser für geeignet?

Ziel ist es, eine DB zu haben, die
a) ohne große Installation auskommt, und am besten alles ins Prog implementiert werden kann.
b) das lokale Arbeiten mit einer DB möglich ist (Einzelplatz)
c) aber auch z.B. die DB auf einem Netzlaufwerk/UNC abgelegt werden kann, so dass mehrere Rechner zeitgleich darauf zugreifen können.

[mkinzler]

Ich würde Dir dazu abraten, eine Multiuserdatenbank ohne Server zu betreiben.
Den das ist weder performant noch sicher.
-Die embedded NexusDB-Engine ist nicht multiuserfähig.
-SQLite sollte gehen ist aber wegen dem very-pessimistic locking auch nicht das Gelbe vom Ei.
-Access funktioniert führt aber imho häufig zu defekten Datenbanken, wenn viele Client parallel Zugreifen/Schreiben.
-FireBird sollte mit Tricks funktionieren.

Aber wie gesagt -> mehrere Benutzer = (Datenbank-)Server.

[Jumpy]

Ich bin da jetzt auch nicht wirklich drin in dem Thema, aber was ich hier in anderen Threads zu Firebird gelesen habe, ist es auch vergleichsweise einfach zw. Embeded-Version für den Einzelplatz und Serverversion für Mehrbenutzer zu wechseln und ich meine u.a. Perlsau hat da auch schonmal Codeschnipsel geposted wie er seinem Programm über Startparameter mitteilt, ob es mit einer Embeded-DB oder mit der Serverversion connecten soll (hoffe ich hab das richtig erinnert und das war nicht ganz was anderes).

[Captnemo]

Dann scheidet Nexus schon mal aus.

SQLite könnte ich mal ausprobieren.

Die Performance spielt hier absolut keine Rolle, da die Datensätze klein sind, und nur 2-3 am Tag erfasst werden, bzw. bearbeitet werden. Die Erfassung passiert aber automatisch und die Bearbeitung dann an verschiedenen Arbeitsstationen.

Wenn's irgendwie geht, möchte ich nichts auf dem Server installieren. Zumal das DBS auf dem Server dann 23 Stunden und 59 Minuten am Tag nichts anderes macht, als sich selbst zu verwalten, Speicherplatz zu verbrauchen und zu warten.

[mkinzler]

Zitat:

Wenn's irgendwie geht, möchte ich nichts auf dem Server installieren. Zumal das DBS auf dem Server dann 23 Stunden und 59 Minuten am Tag nichts anderes macht, als sich selbst zu verwalten, Speicherplatz zu verbrauchen und zu warten.

Je nach DBMS und Konfiguration wäre das minimalst.

[Bernhard Geyer]

Also wir hatten früher ADS als Local Server im Einsatz.
Sehr stabil, aber Lizenztechnisch problematisch. Selbst ein Einsatz auf Remote Desktop wird als kostenpflichtiger Serverbetrieb gewertet.
Wenn aber die Anzahl der Installationen übersichtlich ist wäre das aber kein Problem

[mm1256]

Zitat:

Dann scheidet Nexus schon mal aus.

Sorry, falsch. Im Gegenteil, Nexus ist meines Wissens die einzige Datenbank die das kann, was der TE braucht. Man kann in die eigene Anwendung einen vollständigen Datenbankserver integrieren, der dann via TCP/IP alle Clients bedient. Das ist auch mit ein paar Mausklicks und ein paar Komponenten realisiert. Auf der Nexus-Homepage gibt's dazu sogar ein kleines Tutorial.

[arnof]

Zitat von Captnemo:

Hallo,

ich hab mir grad im Internet die NexusDB angeschaut. Bin mir aber nicht sicher, ob sie das, was ich machen will, so kann. Vielleicht weiß das ja einer von euch.
Ich möchte mit der NexusDB quasi so arbeiten, wie mit der BDE.

Also eine DB erstellen, die ohne Serverkomponente auskommt, wo von verschiedenen Rechner zugegriffen werden kann, und die Tables / Datensätze gesperrt werden können. Geht das so ohne weiteres mit der NexusDB? Oder ist da eine andere DB besser für geeignet?

Ziel ist es, eine DB zu haben, die
a) ohne große Installation auskommt, und am besten alles ins Prog implementiert werden kann.
b) das lokale Arbeiten mit einer DB möglich ist (Einzelplatz)
c) aber auch z.B. die DB auf einem Netzlaufwerk/UNC abgelegt werden kann, so dass mehrere Rechner zeitgleich darauf zugreifen können.

Ich habe ADO Componenten so umgeschrieben das ich auf MSSQL und MYSQL wie mit der BDE zugreifen kann, d.h. also TTABLE via Index und Setrange/Findkey usw. TQuerys übersetzt entsprechende Sachen in die jeweilige Datenbank z.B. True/False, Datumsformatierung, usw

[Daniel]

Wer von Euch bezahlt denn die Realisierung dieses Projekts und steht für das Endergebnis gerade?
Es ist in Ordnung, seine Bedenken anzumelden und auf andere - möglicherweise tragfähigere - Lösungen hinzuweisen. Aber sich gegenseitig die Kompetenz abzusprechen, ohne die kompletten Rahmenbedingungen eines Projektes zu kennen, ist zu kurz gegriffen. Ich habe mittlerweile genug Kundenprojekt gesehen, die fürchterliche Aspekte hatten und diese dennoch trotz besseren Wissens aus verschiedenen Gründen vorerst so beibehalten werden mussten.

Ich denke, dass Ihr den Fragesteller nun hinreichend für etwaige Schwächen seines Ansatzes sensibilisiert habt und mehr ist dazu auch kaum zu sagen.

[Dejan Vu]

Zitat von Captnemo:

Hallo,
Ziel ist es, eine DB zu haben, die
a) ohne große Installation auskommt, und am besten alles ins Prog implementiert werden kann.
b) das lokale Arbeiten mit einer DB möglich ist (Einzelplatz)
c) aber auch z.B. die DB auf einem Netzlaufwerk/UNC abgelegt werden kann, so dass mehrere Rechner zeitgleich darauf zugreifen können.

Darum geht es.
a) wird durch Firebird, SQL-Server Express mit Silent Install erschlagen, wobei ich 'ohne große Installation' wörtlich nehme. Vom Installationsaufwand ist Firebird sicherlich vorzuziehen (subjektiv)
b) Ist implizit, das geht mit jedem RDBMS, das lokal installiert ist.
c) Ja, wobei die genannten Einschränkungen ohne Server gelten (unsicher bei gleichzeitigem Zugriff per design)

Über die vorgeschlagene Lösung, eine DB-Engine in die Applikation mit einzubinden wurden alle Argumente ausgetauscht.

Vielleicht geht es jetzt wieder sachlich weiter.