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.

[mkinzler]

Zitat:

Zitat von mm1256 (Beitrag 1264036)

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.

Nexus sagt selber aber was anderes:

Zitat:

Zitat von http://www.nexusdb.com/forums/showthread.php?t=293

The NexusDB Embedded Server Edition contains the same high-speed database
engine as the full version, and comes with full source. It is intended for
situations where multi-user capabilities are not needed

[mm1256]

Was soll das jetzt werden? Ich arbeite seit 14 Jahren mit Nexus, und du weißt das besser?

Solltest dich mal informieren, und nicht einzelne Kommentare aus einer Homepage zitieren, aus denen der Zusammenhang nicht hervorgeht. Zudem braucht der TE eine Netzwerklösung und keine Embedded Single-User-Version.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1264036)

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.

Also ich kann Dir auch einen kleinen Server basteln, der sich auf eine Access-DB setzt (oder einen Haufen von Textdateien) und per TCP ermöglicht, diese Daten zu lesen und zu schreiben. Das ist eine interessante Aufgabe, zwar vollkommen nutzlos, aber interessant. Hast Du mal überlegt, was passiert, wenn Du deinen NexusDB-Server in deiner Anwendung integrierst und die schmiert ab, weil Du (wie alle anderen auch) nicht der 100% perfekte Programmierer bist, der immer alles richtig macht? Was ist das also für ein Feature. Man muss sich -ehrlich gesagt- nicht wundern, wenn NexusDB der einzige Hersteller ist, der das anbietet. Weil es Blödsinn ist.

Es führt kein Weg an einem separaten RDBMS vorbei. Wenn das Geld nicht reicht, einen eigenen Server-PC zu plazieren, dann nimmt man eben einen der Arbeits-PC. Natürlich muss der immer an sein, aber wenn man kein Geld für einen Server-PC hat (also so ca. 600 Euro, reicht ja), dann hat man auch nicht den Traffic.

Ich verstehe einfach nicht, wieso man sich dagegen sträubt, den einzig richtigen Weg zu gehen. Installier Dir FireBird/SQL-Server oder welchen auch immer, richtige den Zugang ein und Du hast in Zukunft 100 mal *weniger* Arbeit und Probleme.
Nimm hier Mainstream, auch wenn Du sonst lieber eine Sonderlocke fahren willst. Nimm den langweiligsten, am weitesten verbreitetsten Schmuh, denn da bekommst Du auch den besten Support in Foren wie diesen (ist das nicht ein Titel von den Toten Hosen?

Zitat:

Zitat von Captnemo (Beitrag 1264027)

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.

Na und? Es muss ja nur irgend ein Dumpfbacken-PC sein, der in der Ecke werkelt (das kann auch ein ausrangierter sein). Stromkosten.. Ja. Das ist ein Argument, das *einzige*.

Ich persönlich würde einem Kunden, der kein Geld für einen Server-PC ausgeben will, sogar einen hinstellen, denn die paar Kröten (2 Tagessätze) habe ich durch den fehlenden Ärger sofort wieder drin.

Ach, und allgemein: Ich hab 30 Jahre Erfahrung und lass mir (speziell hier im Forum) gerne zeigen, wie sehr mir mein Inseldenken (Ich bin der Größte) die Weiterentwicklung behindert (hat).

[Zoot]

Aha.

[Dejan Vu]

Welche metaphysischen Astralerkenntnisse möchtest Du uns mit diesem minimalistischen Kleinod deutscher Dichtkunst vermitteln?

[mkinzler]

Zitat:

Zitat von mm1256 (Beitrag 1264045)

Was soll das jetzt werden? Ich arbeite seit 14 Jahren mit Nexus, und du weißt das besser?

Nein, ich habe nur eien Aussage eines Nexus Mitarbeiters zitiert. Ich weiss garnix bin ein Dumpfkopf!

Zitat:

Solltest dich mal informieren, und nicht einzelne Kommentare aus einer Homepage zitieren, aus denen der Zusammenhang nicht hervorgeht. Zudem braucht der TE eine Netzwerklösung und keine Embedded Single-User-Version.

Ich habe nicht nur zitiert, sondern auch verlinkt.

Er wollte ein serverlose Lösung. da ist es imho egal, ob der Server nun eine eigene Anwendung, ein Dienst oder ein Client mit einer (embedded) Serverlösung ist!

Wenn Du gute Erfahrungen mit einer solchen Lösung hast, dann ist es ok, ab ich würde mich (persönlich) nicht auf ein deartiges Experiment einlassen.

[mm1256]

Zitat:

Hast Du mal überlegt, was passiert, wenn Du deinen NexusDB-Server in deiner Anwendung integrierst und die schmiert ab, weil Du (wie alle anderen auch) nicht der 100% perfekte Programmierer bist, der immer alles richtig macht?...

Nein, diese Überlegung habe nicht ICH angestellt, sondern der Programmierer von NexusDB, Thorsten Engler, der wie wohl Nexus-User wissen Deutscher ist, und damals nach dem Ende von Turbopower nach Australien ausgewandert ist, und zusammen mit Geoff Harris die Nexus Ltd gegründet hat.

Den Nexus-Server - egal ob die externe Version als Dienst, oder die in die Anwendung integrierte Server-Engine - unterstützt den Failsave-Mode. D.h. wenn zum Beispiel eine Transaktion aufgrund eines Stromausfalles während des Schreibvorganges nicht fertiggestellt werden kann, dann wird diese Transaktion beim nächsten Start automatisch (oder manuell, ist einstellbar) fertiggestellt.

Insofern hinkt dieser Vergleich mit Access gewaltig! Du kannst nicht eine primitive Desktop-Datenbank wie Access mit einer Client-Server-Datenbank vergleichen.

Zitat:

Ich habe nicht nur zitiert, sondern auch verlinkt.

Er wollte ein serverlose Lösung. da ist es imho egal, ob der Server nun eine eigene Anwendung, ein Dienst oder ein Client mit einer (embedded) Serverlösung ist!

Das ist das Problem: Man muss NexusDB prinzipiell schon kennen, um beurteilen zu können, was geht und was nicht geht.

Zitat:

Wenn Du gute Erfahrungen mit einer solchen Lösung hast, dann ist es ok, ab ich würde mich (persönlich) nicht auf ein deartiges Experiment einlassen.

Es ist ganz einfach so, dass ich in eine Anwendung mit den entsprechenden Komponenten einen vollständigen Client-Server-Datenbankserver integrieren kann. Das Modell ist weltweit 1000-fach im Einsatz. Sorry, aber wenn du das als Experiment bezeichnest rate ich dir dringend, sich erst mal mit der Materie NexusDB zu beschäftigen.

[mkinzler]

Und du solltest unsere Beiträge genauer Lesen, dann würdest Du verstehen, dass wir nicht Nexus, sondern den grundsätzlichen Ansatz kritisiert haben.

Btw.: In welcher Beziehung zu Nexus stehst Du, dass Du Dich hier extra anmeldest um ein Produkt in dern Himmel zu loben?

[mm1256]

Zitat:

Und du solltest unsere Beiträge genauer Lesen, dann würdest Du verstehen, dass wir nicht Nexus, sondern den grundsätzlichen Ansatz kritisiert haben.

Das lenkt vom Thema ab und entspricht nicht den Gegebenheiten. Der TE hat eine Frage gestellt, jemand hat darauf eine aus welchen Gründen auch immer unrichtige Antwort gegeben, und ich habe mir erlaubt darauf hinzuweisen, dass diese Antwort nicht den Tatsachen entspricht.

Zitat:

Btw.: In welcher Beziehung zu Nexus stehst Du, dass Du Dich hier extra anmeldest um ein Produkt in dern Himmel zu loben?

Auch dise Frage habe ich schon beantwortet. Aber gerne nochmal: Die NexusDB ist aus dem vormaligen Flash-Filer-Server von Turbopower Software entstanden. Das kann man auch auf der Homepage nachlesen. Ich hatte damals schon den FF-Server im Einsatz, und dann logischerweise auch den Nachfolger NexusDB. Weil beide sehr gute Datenbanken sind, und ich damit mit hunderten von Kunden keine Probleme habe. ich bin also langjähriger FF-DB und NexusDB-User, sonst nichts.

Und als Mod solltest du auch sehen können, dass ich mich nicht erst jetzt angemeldet habe um irgend ein Produkt in den Himmel zu loben. Ich habe nur ein paar Informationen mitgeteilt, die dir offensichtlich fremd sind. Aber, wenn Hilfe nicht gewünscht ist, werde ich mich wieder zurückziehen und wie bisher nur noch lesen. Herr Kinzler, damit hab ich kein Problem.

[mkinzler]

Zitat:

Aber, wenn Hilfe nicht gewünscht ist, werde ich mich wieder zurückziehen und wie bisher nur noch lesen. Herr Kinzler, damit hab ich kein Problem.

Nein sollst Du nicht.

[mm1256]

Werde ich aber, denn ihr diskutiert in diesem Thread eine Thematik, nach welcher der TE überhaupt nicht gefragt hat. Die Frage war ja "Mit NexusDB arbeiten wie mit der BDE". Aber, dazu muss man erst mal Ahnung von NexusDB haben.

[mkinzler]

Wir lassen uns auch nicht den Mund verbieten. Und aus meiner ( für Dich vielleicht unterbemittelten ) Sicht macht es gar keinen Sinn, wie mit der BDE arbeiten zu wollen!
Wenn jemnad fragt, wie er mit dem Fahrrad am Besten nach China kommt, kann man im Raten das Flugzeug zu nehmen ( unser Vorschlag) oder man kann ihm Helfen, das Ziel mit dem von ihm vorgeschlagenen Mitteln erreichen.

Es geht nicht um Nexus oder nicht, sondern dedizierter Server ( von mir aus mit NexusDB) oder nicht!

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1264049)

Ach, und allgemein: Ich hab 30 Jahre Erfahrung und lass mir (speziell hier im Forum) gerne zeigen, wie sehr mir mein Inseldenken (Ich bin der Größte) die Weiterentwicklung behindert (hat).

1..50 Jahre in einem Beruf zu arbeiten heißt ja nicht, in der selben Zeitspanne auch Erfahrungen gesammelt und auch verarbeitet zu haben.

Es gibt einfach zu viele, die es nicht schaffen (oder wollen) über den Tellerrand Ihrer Erlebnisse hinaus zu schauen.
("Jeder ist eine Insel")


Zurück zu CaptNemo wofür soll das denn gut sein, bzw. was willst Du damit erreichen?

Gruß
K-H

[mm1256]

Zitat:

Es geht nicht um Nexus oder nicht, sondern dedizierter Server ( von mir aus mit NexusDB) oder nicht!

Und genau das ist der Irrtum: Es geht eben genau darum, NexusDB oder nicht! Weil NexusDB - wie bereits von mir erwähnt - meines Wissens die einzige DB ist, die in einer einzigen ausführbaren Datei sowohl Client-Server-Datenbankserver sein kann, als auch ganz normales Anwendungsprogramm. Im Einzelplatzmodus und im Netzwerkmodus, ohne Installation, genauso wie vom TE gewünscht.

Um Ihren Sprachgebrauch zu verwenden: Der TE wird Gründe haben, nicht mit dem Flieger zu fliegen, sondern mit dem Fahrrad fahren zu wollen. Es gibt einen sehr gut ausgebauten, sicheren und komfortablen Radweg nach China. Wenn dieser auf Ihrer Landkarte nicht eingezeichnet ist, macht es dann Sinn, mit Ihnen diesen Weg diskutieren?

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1264086)

Und genau das ist der Irrtum: Es geht eben genau darum, NexusDB oder nicht! Weil NexusDB - wie bereits von mir erwähnt - meines Wissens die einzige DB ist, die in einer einzigen ausführbaren Datei sowohl Client-Server-Datenbankserver sein kann, als auch ganz normales Anwendungsprogramm. Im Einzelplatzmodus und im Netzwerkmodus, ohne Installation, genauso wie vom TE gewünscht.

Und genau deshalb scheidet doch NexusDB aus: Wer so eine Architektur anbietet, *kann* einfach nichts taugen. Es wäre sinnvoller, sich an einer offenen Diskussion um robuste, vernünftige und nachhaltige Architekturen zu beteiligen und den TE eventuelle von dieser absurden Idee abzubringen.

Zitat:

Der TE wird Gründe haben, nicht mit dem Flieger zu fliegen, sondern mit dem Fahrrad fahren zu wollen.

So, wie es aussieht, fällt ihm außer dem Flieger nichts ein, das Fahrrad bekommt er ja von Dir eingeredet. Es ist nicht sinnvoll, ihm das einzige Fahrrad schmackhaft machen zu wollen, das ein Zelt und Kocher auf dem Gepäckträger montiert hat und mit dem es möglich ist, auch während der Fahrt eine warme Mahlzeit zu sich zu nehmen, während man Fussi gucken kann. Du musst zugeben, das ein derartiges Fahrrad zwar ein Alleinstellungsmerkmal besitzt und durchaus fahren kann, aber im realen Einsatz starke Defizite aufweist: Ist das Zelt kaputt, wird man nass. Fällt der Kocher aus, verhungert man (oder isst trocken Brot mit Schmalz). Und geht der Fernseher hopps, ist eh alles egal. Und wenn das Fahrrad mal kaputt geht, wird man pitschnass, erfriert, verhungert und kann -was besonders grausam ist- die weiteren Spiele der dt. Mannschaft nicht erleben.

Ist es nicht praktischer, die einzelnen Komponenten *separat* zu verwenden? Also ein (austauschbares) Zelt, einen (upgradefähigen) Kocher und einen (nach der WM vertickbaren) Fernseher?

Also: NexusDB kann das. Middleware+AccessDB auch, nebenbei bemerkt. Aber man macht es nicht, Stichwort: "SOA" in seiner allgemeinsten Form.

[mm1256]

Zitat:

Und genau deshalb scheidet doch NexusDB aus: Wer so eine Architektur anbietet, *kann* einfach nichts taugen.

Ich bin begeistert von so viel Fachkenntnis

[Zoot]

Zitat:

Zitat von Dejan Vu (Beitrag 1264097)

Wer so eine Architektur anbietet, *kann* einfach nichts taugen.

Ich wiederhole mein "Aha".

Dogmen können die Welt vereinfachen.

[Sherlock]

Zitat:

Zitat von mm1256 (Beitrag 1264100)

Zitat:

Und genau deshalb scheidet doch NexusDB aus: Wer so eine Architektur anbietet, *kann* einfach nichts taugen.

Ich bin begeistert von so viel Fachkenntnis

Würdest du Deine Kommentare mit etwas weniger Bissigkeit von Dir geben, würde man eventuell vernünftiger miteinander reden können.

<SARKASMUS>Wenn man wirklich Ahnung hat, nimmt man ohnehin Oracle.</SARKASMUS>

Sherlock

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1264100)

Ich bin begeistert von so viel Fachkenntnis

Ich wusste, ich kann dich überzeugen. Vielleicht denkst Du ein wenig über das Beispiel mit dem Übernachtungskochfernsehfahrrad nach, vor allen Dingen hinsichtlich der Robustheit gegenüber dem Ausfall einzelner Komponenten.
Und dann würde ich mir einfach mal auch darüber Gedanken machen, warum diese Architektur nicht weit verbreitet ist. Eigentlich gar nicht.

Zitat:

Zitat von Zoot (Beitrag 1264101)

Ich wiederhole mein "Aha". Dogmen können die Welt vereinfachen.

Wenn es welche wären. Die naheliegende Interpretation wäre jedoch: 'Rethorische Übertreibung', aka 'Hyperbel'. Übrigens wäre der zweite erhellende Satz im ersten Post wirklich brauchbar gewesen, denn für ein Dogma hätte ich auch nur ein 'Aha' bzw. ein 'So so' übrig ;-)

[arnof]

Zitat:

Zitat von Captnemo (Beitrag 1264021)

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]

:thumb:

Zitat:

Zitat von Captnemo (Beitrag 1264021)

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.

[Sir Rufo]

Ich möchte mich in das HickHack hier nicht einmischen (ist aber lustig zu lesen :mrgreen:), aber sollte es einer Anwendung bei der Persistenz-Schicht nicht völlig egal sein wie das da passiert und wer das mit wem wo speichert - Hauptsache es wird?

Ok, irgendwann geht man da dran, aber dann wird nur noch die eine oder andere oder mehrere (je nach Einsatzgebiet) konkrete Persistenz-Schicht implementiert und je nach Gusto, Vorliebe und Geldbeutel wird das eine oder andere System genommen.

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1264124)

... aber sollte es.. nicht völlig egal sein wie das da passiert und wer das mit wem wo speichert - Hauptsache es wird?

Stimmt. Aber irgendwann muss man sich festlegen, 'wie das da passiert'. Und die Problematik ist schon erstens der normale Alltag, aber zweitens auch eine Herausforderung, da offensichtlich viele Wege zum Ziel führen und keine (ach so blödsinnige) Lösung bisher den dritten Weltkrieg ausgelöst haben.

[p80286]

Ich hab die Gelegenheit ergriffen und mich mal -oberflächlich- über NexusDB informiert.
Da ist immer ein "Server" im Spiel der sich um die DB kümmert (so wie bei FB). Also vom Grobkonzept her genau das gleiche. Bleibt die Frage BDE-Ersatz (als solcher ist NexusDB wohl konzipiert) und "eine Datei auf die gaanz selten zugegriffen wird". Diese Anforderung kann man nur dann ruhigen Gewissens umsetzen, wenn sichergestellt ist, daß nur ein "Client" zu einem Zeitpunkt schreibend zugreift.
Und das diese Anforderung hier sehr kritisch gesehen wird ist für mich sehr gut nachvollziebar.

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1264128)

Zitat:

Zitat von Sir Rufo (Beitrag 1264124)

... aber sollte es.. nicht völlig egal sein wie das da passiert und wer das mit wem wo speichert - Hauptsache es wird?

Stimmt. Aber irgendwann muss man sich festlegen, 'wie das da passiert'. Und die Problematik ist schon erstens der normale Alltag, aber zweitens auch eine Herausforderung, da offensichtlich viele Wege zum Ziel führen und keine (ach so blödsinnige) Lösung bisher den dritten Weltkrieg ausgelöst haben.

Nein, man muss sich eben nicht festlegen. Es reicht wenn die Persistenz-Schicht sich so verhält, wie vereinbart. Wie diese Schicht das dann macht und erledigt ist (der Anwendung) egal.

Heute finde ich SQlite toll, morgen aber vielleicht NexusDB und übermorgen kommt ein Kunde und will die Ultra-Trallala-DB verwenden. Dann wird genau dafür eine konkrete Persistent-Schicht gebaut, durch den Persistenz-Interface-Unit-Test gejagt und der Drops ist gelutscht.

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1264130)

Wie diese Schicht das dann macht und erledigt ist (der Anwendung) egal.

Installieren (siehe Punkt a,b,c) muss man schon irgend etwas. Und dann muss man sich festlegen. Denn eine Mehrbenutzerumgebung mit Netzdateien, bei denen das OS die Konsistenz nicht versichern kann, sind keine ernsthafte Lösung.

Zitat:

Dann wird genau dafür eine konkrete Persistent-Schicht gebaut, durch den Persistenz-Interface-Unit-Test gejagt und der Drops ist gelutscht.

Wenn man mit 08/15-Performance und -Möglichkeiten leben kann, dann ist der Drops gelutscht. Ansonsten muss man sich schon festlegen (Stichwort Massenupdates, ETL usw.). Aus Kundensicht ist es -im Gegenteil- sehr sicher, das sich da nix mehr ändert, wenn man vorher einmal nachgedacht hat. Und es ist auch besser so.

Aus Anwendungssicht hast Du ja Recht, aber hier geht es imho ausnahmsweise nicht um ORM. Obwohl.... wieso eigentlich nicht? :gruebel:

[Captnemo]

Also, dass ihr euch hier bekriegt lag natürlich nicht in meiner Absicht :-) Dient auch nicht Zweck. Also....keep cool 8-)

Zurück zum Thema:

Tatsächlich war mein Anspruch der, dass ich wirklich ähnlich der BDE auf eine Filebased-DB zugreifen möchte. Ob das letztlich über vollständig Embedded in der EXE geschehen muß ist ja noch mal was anderes (ist ja bei der BDE auch nicht so). Aber ich möchte in dem Projekt ohne Server-DBS, Serverprozess oder sonstiges auf dem Server auskommen.
Nennen wir mal ein anderes Beispiel, z.B. VoxPro. Das ist ja ähnlich, und auf dem Server läuft auch keine Serverengine.

Was jetzt die Performance, Datenbankgröße oder Datensicherheit angeht, so sind mir die Nachteile durchaus bewußt. ABER: bei dem Projekt handelt es sich 1.) um eine Programmierung für einen Kunden und auch ausschließlich nur für diesen Kunden, 2.) die Datenmenge wird sich nicht verändern, die Anzahl der Clients wird sich nicht verändern und 3.) das Budget für dieses Projekt ist sehr klein, und läßt keinen Spielraum für zusätzliche Anschaffungen.
Weiterhin sollte es möglich sein, ohne Serverzugriff die DB auf andere Pfade zu verschieben (was ja bei der BDE oder VoxPro auch ohne Probleme möglich ist).

Was den Server angeht, so gibt es durch aus Unternehmen, die z.B. den Server von Vertragspartnern aufgestellt bekommen. Und es gibt dort tatsächlich Wartungsverträge, die Fremdprodukte untersagen, was dann heißt, dass das Unternehmen auf diesem Server nichts installieren dürfen, sonst verlieren sie ihren Supportanspruch. In solchen Fällen sind solche Sachen durchaus sinnvoll. Deswegen gleich einen anderen Server daneben zu stellen, kann man machen....muß man aber nicht. Will der Kunde ggf. auch nicht. Denn dieser muß auch wieder gesichert werden. Und wenn man dann das DBS auf einem Client realisiert, dann sind wieder alle davon abhängig, dass keiner zum Feierabend aus versehen diesen herunterfährt.
Also ich finde ja, dass BDE o. ä. durchaus ihre Daseinsberechtigung hat.
Ich bin jetzt tatsächlich nicht ganz sicher, aber wird die BDE unter Win 8.1 64-bit überhaupt unterstützt? Ich glaube nicht.

[Sir Rufo]

Kann man zwar nachvollziehen ändert aber nichts an der Realität und die sieht nun mal so aus, dass ein Filelock auf einer Datei im Netzwerk nicht zuverlässig funktioniert. Funktioniert zwar meistens aber eben nicht zuverlässig immer. Das ist und bleibt der Knackpunkt bei allen Systemen, die gleichzeitig auf eine Datei im Netzwerk zugreifen möchten.

Wenn man das weiß, und der Kunde das so wünscht, dann ist es nur fair den Kunden darauf hinzuweisen um das Thema Datensicherheit/Datensicherung entsprechend hervorzuheben.

[Captnemo]

Naja, du hast wohl recht, dass will ich nicht bezweifeln.

Aus meinem Kundenkreis kenne ich einige Beispiele, die mit BDE/Paradox bzw. VoxPro arbeiten. Und das sehr erfolgreich, performant und fehlerfrei. Da wäre z.B. ein Kfz-Programm, welches von einem großen Teilelieferanten vertrieben wird. Als DB wird VoxPro verwendet. Läuft im Netzwerk absolut problemlos, und in meinem Fall mit ca. 20 Usern. Datenbestand ist auch nicht gerade klein mit ca. 5000 Kunden, 25000-30000 Artikelstamm und ca 3000-4000 Rechnungen im Monat. Das ist jetzt ein halbes Jahr in Betrieb ohne Geschwindigkeitseinbußen und ohne irgendwelche Probleme. Da ist schon ganz schön Bewegung drin. Wenn die das könne.....:gruebel:
Und ich war bei der Erstinstallation dabei...keinerlei Installation auf dem Server, lediglich ein gemeinsames Netzlaufwerk wird benötigt.
Klar, dort werden neben dem entsprechenden Programm auch noch Runtimes installiert, aber mit sowas könnte ich ja leben.

Ich hätt auch noch ein anderes Beispiel mit einer Zahnarztsoftware, die was ihren Marktanteil angeht, ihres gleichen sucht. Arbeiten komplett mit DBase oder Paradox (weiß ich jetzt nicht ganz genau), aber vollständig Filebase ohne jedliche Serverinstallation.

Selbst mit einer gewissen Fehlertoleranz könnte ich noch leben.

Es gibt ja auch z.B. Absolut Database von ComponentACE. Bieten auch Multiuser und Filebased. Ich hatte gehofft, dass es evtl. auch was Free gibt, was ähnliche Anforderungen unterstützt.

Mir ist vollkommen klar, dass solche Datenbanken nicht das Optimum darstellen, aber in oben genannten Beispiel war vorher ein Pervasive-SQL-Server in gleichem Umfeld in Betrieb, der in keinster Weise schneller war.

Es gibt eben nicht nur große Unternehmen, die mit eigener EDV-Abteilung ihre eigene Server-Farm betreiben. Es gibt auch viele, viele Kleinunternehmen, die eben nur einen Server (wenn überhaupt) stehen haben, mit dem Hintergrund "Der war schon teuer genug". Und über die Zeit laufen auf diesem diverse DBS. Die eine Software bringt ihren Microsoft SQL Express mit, die nächste ihren SQL Anywhere, dann kommt der nächste Teilekatalog mit einer MySQL, oder Postgre um die Ecke und Schwups laufen auf dem Ding drei, vier SQL-Engines. Da wird schon mal der Speicher eng.
Meist habe diese Firmen keinen eigene Admin, manchmal auch nicht mal einen Admin, da macht das irgendein Kollege, der sich etwas auskennt.

Ich will mit meinem Projekt ein paar Daten erfassen, wie gesagt nix großes. Es soll einfach, klein und billig sein. Wenn das bei großen Projekten läuft, warum sollte ich das nicht in Betracht ziehen?

[Dejan Vu]

Zitat:

Zitat von Captnemo (Beitrag 1264158)

Nennen wir mal ein anderes Beispiel, z.B. VoxPro. Das ist ja ähnlich, und auf dem Server läuft auch keine Serverengine.

Also wenn Du mit VoxPro Visual FoxPro vom Microsoft meinst, dann muss ich da widersprechen: VoxPro arbeitet mit ODBC und damit mit jedem RDBMS.

Zitat:

Also ich finde ja, dass BDE o. ä. durchaus ihre Daseinsberechtigung hat.

Ja, aber (ich sage es mal sehr laut) DIE DATENBANKEN/DATENDATEIEN WIRST DU DIR REGELMÄßIG ZERSCHIESSEN!. Dein Beispiel mit 'VoxPro': Bei einem meiner Kunden hat es die DB so 2x im Jahr zerschossen. Lustigerweise merkt man das nicht immer, es fehlen einfach nur Daten. Das ist dann umso lustiger, je geringer die Rechnungen infolge Datenverlust ausfallen. Deine Argumentation ist so wie die des Autofahrers, der sagt: 'Ich fahre schon immer ohne Gurt und lebe noch, also taugt er nichts'.

Edit: Man fragt sich, wieso immer noch Programme in der Architektur, wie von dir beschrieben, verkauft werden.

Zitat:

Ich bin jetzt tatsächlich nicht ganz sicher, aber wird die BDE unter Win 8.1 64-bit überhaupt unterstützt? Ich glaube nicht.

Mit seeehr viel Knowhow und unter bestimmten Umständen: Ja. Aber wozu? Die BDE ist doch eh totaler Müll.

Ich behaupte mal; Es gibt keine Desktop-DB, die eine Datei im Netz zuverlässig vor Inkonsistenzen und allgemeiner Zerschrotung schützt. Und deshalb raten dir hier alle zu einem richtigen RDBMS, welches sich auf die Datei setzt und exklusiv den Zugriff steuert.

Wenn Dir das egal ist, und die Daten sowieso nur sehr sehr selten parallel von mehreren Clients beschrieben werden, dann nimm Access oder SQLite, das knallt nur bei hoher Last, also wenn die DB sehr oft parallel bearbeitet wird.

Übrigens: Das alles hat mit 'der BDE' nun wirklich überhaupt nichts zu tun. Die war nur ein ziemlich grausliger Versuch, die unterschiedlichen Provider unter einen Hut zu bringen. Fälschlicherweise wird die BDE mit Paradox in Verbindung gebracht, einer noch größeren Krankheit als die BDE.

[jobo]

[OT]

Zitat:

Zitat von Sherlock (Beitrag 1264107)

<SARKASMUS>Wenn man wirklich Ahnung hat, nimmt man ohnehin Oracle.</SARKASMUS>
Sherlock

Hab ich da Oracle gelesen?
Und war das jetzt quasi doppelte Verneinung?!
:)
[/OT]

[Captnemo]

Zitat:

Zitat von Dejan Vu (Beitrag 1264202)

Also wenn Du mit VoxPro Visual FoxPro vom Microsoft meinst, dann muss ich da widersprechen: VoxPro arbeitet mit ODBC und damit mit jedem RDBMS.

Wie VoxPro arbeitet weiß ich nicht, hab ich mich noch nie mit beschäftigt. Ich hatte lediglich seinerzeit mal mit einem DB-Viewer eine der Dateien geöffnet, weil wir wissen wollten welche Daten darin beherbergt werden, und damals nannte der Viewer als DB-Typ VoxPro. Deswegen bin ich davon ausgegangen.

Zitat:

Zitat von Dejan Vu (Beitrag 1264202)

Dein Beispiel mit 'VoxPro': Bei einem meiner Kunden hat es die DB so 2x im Jahr zerschossen. Lustigerweise merkt man das nicht immer, es fehlen einfach nur Daten. Das ist dann umso lustiger, je geringer die Rechnungen infolge Datenverlust ausfallen.

Kann ich so nicht bestätigen. In meinen beiden Beispielen laufen die sehr stabil und definitiv Datenverlustfrei. Im Falle des Zahnarztes seit 9-10 Jahren mit 0 Ausfällen, Dateninkonsistenzen oder Datenverlusten. Und die prüfen ihre Daten sehr akribisch.

Ich hatte auch mal einen Kunden, der so alle paar Monate seine Exchange-Datenbank komplett zerschossen hatte. Wir haben lange nach einem Fehler gesucht, aber keinen gefunden. Das war noch zu den Exchange 5.5 und NT4-Zeiten. Nach dem vierten mal haben zufällig herausgefunden, dass ein Mitarbeiter (im Auftrag des Chef's) alle 3 Monate den Server mit einem Defragmentierer bearbeitet hat, natürlich wärend der Exchange online war. Der Chef hatte das natürlich vergessen.
Aber das gehört hier nicht hin :-)

Zitat:

Zitat von Dejan Vu (Beitrag 1264202)

Edit: Man fragt sich, wieso immer noch Programme in der Architektur, wie von dir beschrieben, verkauft werden.

Naja, was soll ich sagen....scheint bei denen wohl doch gut zu funktionieren. Ich könnt noch mehr Beispiele aus der Praxis aufzählen, wo derartige System im Einsatz sind. Und merkwürdigerweise laufen die Dinger und laufen. Warum kann ich dir nicht sagen. Ich kann aber nur von meinen Kundenkreis sprechen.

Zitat:

Zitat von Dejan Vu (Beitrag 1264202)

Wenn Dir das egal ist, und die Daten sowieso nur sehr sehr selten parallel von mehreren Clients beschrieben werden, dann nimm Access oder SQLite, das knallt nur bei hoher Last, also wenn die DB sehr oft parallel bearbeitet wird.

Darauf wird es wohl hinauslaufen.