Neues Datenbank-Backend für meine Anwedung - Welches?

[berens]

Hallo zusammen,
wie aus meinen vorherigen Beiträgen zu sehen ist, verwendet meine Software (CMS für Infobildschirme) als Datenbank die guten alten .mdb-Dateien: das Datenbankformat von Access 2003.

Dieses Format wird zwar viel belächet (auch in Anbetracht des abgelaufenen Supports und des Alters), aber bei sogut wie allen Kunden kam es gut an, dass wir unsere "Netzwerk"-Software direkt ohne Server und Portfreigaben in der Firewall in Betrieb nehmen können, einfach nur durch den gemeinsamen Zugriff auf die Datenbank über ein Netzlaufwerk. Bei vielen Kunden wäre die Installation eines *SQL-Servers für nur zwei Geräte [zu] viel Aufwand, bei anderen -großen- Kunden müssten erst intern Anträge geschrieben werden etcetc (Projektverzögerungen / -kosten), und mit dieser rein dateibasieren Lösung können eigentlich Alle ganz gut leben. Auch werden -im Vergleich zu den neueren Access-Datenbanken (.accdb) und MySqL keine Drittanbieterprogramme benötigt (Access Runtime blabla, MySQL ODBC Treiber (für TAdoConnection!), ...) Ein entscheidender Vorteil (war) auch, dass man die Datenbank mit einem USB-Stick auf einen Infobildschirm aufspielen kann, der über keinerlei Netzwerkanbindung verfügt.

Jedoch leben wir nun in 2020, und aktuelle Probleme zwingen uns, uns schon vor einer neuen Hauptversion mit der Migration auf ein neues Datenbanksystem zu beschäftigen.

Bei Access-Datenbanken treten gelegentlich folgende Probleme auf:

1) Datenbank ist nach dem Schreiben in inkonsitentem Zustand und kann nicht über MDAC/OLEDB/JET repariert werden, nur direkt über Access. Beim Kunden steht "alles still" weil bis zum Reparieren kein Infobildschirm mehr auf die Datenbank zugreifen kann.

2) Datenbank wächst rasant an (dazu gibt es auch Themen hier im Forum): Die Transaktionsprotokolle sorgen dafür, dass die Datenbank innerhalb eines Tages um ~60 MB anwächst, und das, obwohl in der konkreten Situation "nur" alle 15 Minuten ca. 100 Einträge gelöscht und neu geschrieben werden. Nach einigen Tagen erreicht Diese theoretisch 2GB und kollabiert dann (bekanntes Problem). Datenbank "reparieren und komprimieren" in Access hilft - bis zum nächsten Tag. Zudem kann die Datenbank nicht repariert und komprimiert werden, da/sobald ein weiteres Gerät über Netzwerk darauf zugreift, was aber eigentlich immer der Fall ist, da die Infobildschirm eigentlich den ganzen Tag laufen.

3) Aktuelles Problem mit den Mai 2020 Windows Updates, wobei auch auf Einzelplatzinstallationen Windows die Datenbank beim Schreiben einer einzigen Zeile komplett "zerschießt", weil irgendwass mit dem generellen Schreibzugriff von Anwendungen auf die Festplatte geändert wurde.

4) Problem, wenn die Netzlaufwerks-Freigabe (SMB) mit der Datenbank auf einem Windows 2008/2016 Server liegt: Es können nicht mehr als zwei Leute gleichzeitig die Anwendung geöffnet haben. Unbekannte Ursache / Lösung.


Ich höre schon eure Einwände: Access-Datenbank mit Multiuser gleichzeitig? Die AdoConnection den ganzen Tag geöffnet? Kunden arbeiten über Netzlaufwerk (ggf. sogar über VPN!) mit einer .mdb-Datei? "Ohje-Ohje". Ja, geht eindeutig professioneller, ist aber -ganz ehrlich-: Pflegeleicht und hat bis dato immer gut geklappt - Ausnahmen siehe Oben.

Hier im Forum wird ja im "pinned" Thema mehrere Datenbanksysteme für Delphi vorgestellt. Jetzt stehen natürlich auf den Webseiten und den Produktdatenblättern viele tolle Sachen drin. Ich brauche 4-5 Tabellen. In der Größten stehen max. 300 Zeilen mit ~10 String-Spalten, die meisten anderen Tabellen sind i.d.R. leer - das ist also wohl kein Kriterium für die Suche. Was mich interessiert ist der Erfahrungswert, den Ihr mit einem bestimmten Datenbanksystem habt, und wie sich das auf meine u.g. Punkte anwenden lässt.

Aktuell arbeite ich mit TAdoConnection und eigentlich nur TAdoQuery, keine Stored Procedures oder Ähnliches. Das Programm ist -sagen wir- "historisch gewachsen" und ich müsste nun natürlich an vielen Stellen Alles, was mit Datenbanken zu tun hat, auf eine neue Komponente/Abfragesprache anpassen. Sei es drum, muss halt.

Generell spiele ich ja mit dem Gedanken, einen Microsoft SQL Express Server zu verwenden. Die Ansteuerung im Programm wäre fast unverändert, die Migration bei den Kunden "machbar". Leider bin ich da ein wenig ein "gebranntes Kind" weil ich im Leben schon viele, viele Probleme mit SQL-Express hatte, z.B. wenn diese als Datenbanken für OnPremise-Virenscanner (Symantec, Sophos Antivirus) zu Einsatz kamen: Ein riesen Trara bis das Alles installiert ist, dann gibt es schon eine Instanz "SQL-Express", dann hat die neue Instanz andere Portnummern etc., Backup und Wiederherstellung -ohne weitergehende Beschäftigung damit- scheinbar auch größere Aktion. Zunächst Alles nur Vorurteile von mir für Versionen von vor > 10 Jahren, vielleicht kann man ja jemand dies bzgl. eines Besseren belehren?
Auch macht mir Sorgen, ob/wie einfach ich dann auch Daten mal von einem PC auf einen anderen Migrieren kann (eigentlich ja wieder nur das Backup/Restore "Problem" - wahrscheinlich heutzutage zwei Klicks und alles ist gut), bzw. falls der Kunde eine merkwürdige Situation in unserem CMS erreicht hat, wäre es auch gut, wenn er uns "mal schnell" die Datenbank zusenden kann (Aktuell: .mdb als .zip in den E-Mail Anhang, mit MS SQL Express denke ich mal ein wenig aufwändiger, aber machbar).

Generell bin ich auch offen für anderen Datenbanksysteme. Ich bin nach wie vor eigentlich tatsächlich ein Fan von dateibasierten Datenbanken, aber bei jedem Datenbankanbieter habe ich wieder gewisse Bedenken, und ich wäre euch sehr dankbar, wenn ihr sie ausräumen würdet:

1) Folgekosten: Hier muss ich den "Pinned" Thread im Detail durchlesen, speziell wegen Lizenzen etc. Mein zukünfiges Datenbanksystem sollte idealerweise mit dem Kauf von Delphi von für den Einsatz bei allen Kunden lizenziert sein ("Royality Free"?), oder generell so kostenlos sein, dass ich es mit meinem Installer ausliefern darf, ohne Verklagt zu werden, ohne meinen Quellcode komplett offenlegen zu müssen oder einen Betrag von X € pro Installation bezahlen zu müssen. Dito für die Delphikomponenten, die ich dann in meiner Anwendung einsetze. Einmaliger Kauf bis in den 4stelligen Bereich wäre in Ordnung.

2) Kompatibilität: Meine Software ist (und bleibt?) ein reines Windows Programm. Das Datenbanksystem muss also auf Windows laufen.

3) Stabilität: Siehe Probleme oben. Die Datenbank darf nicht so dermaßen anwachsen, dass ich Sie /nur/ im Exklusiv-Zugriff komprimieren kann. Auch sollte sie nie in einen "inkonsistenten Zustand" verfallen, den die Vermittlerkomponente von Delphi (Datenbankschicht) nicht von alleine -automatisch- reparieren kann. Könnte mir vorstellen, dass das für rein dateibasierte Datenbanken schon technisch nicht möglich ist. Reine XML-Dateien wäre für die paar wenigen Daten schon ne feine Sache, aber dort habe ich auch wieder "Angst", dass schon ein falsch interpretiertes "<" ausreicht, und die komplette Datenbank zu zerschießen.

4) "Threadsicherheit": Wenn ich in einem Thread eine Datenbankverbindung herstelle und etwas lese/schreibe, muss sich das in keiner Weise in Echtzeit auf Abfragen in anderen Threads und den Hauptsthread auswirken. Wenn ich im Thread was schreibe, erwarte ich eine ordnungsgemäß ge"post"ete Zeile, deren AutoIncrement-Wert für "ID" korrekt ist, und nach dem Schreibvorgang die Datenbank garantiert immernoch in einem konsistenten Zustand ist. Es sollen/dürfen keine Exceptions auftreten, wenn zwei Threads mit der selben Tabelle arbeiten (jeweils nur abgeschlossene Operationen, immer nur eine Zeile wird verändert, keine Änderungen an der Tabellenstruktur im Thread).

4) Administrator-Freundlichkeit: Interessenten und Administratoren möchten unsere Software natürlich auch mal auf dem eigenen PC schnell in Betrieb nehmen. Bei MS SQL Express stelle ich mich das schon aufwändiger -dennoch machbar- vor. Dennoch sollte der Server schnell installiert sein, ohne tiefergehende Konfiguration. In unserem Programm darf dann max. IP-Adresse/Port, User, Passwort angegeben werden; die Software legt dann Tabelle und Daten an. Sollte jede Software können? Brauchen manche MEHR Konfiguration?

5) Keine erzwungenen Callbacks: Mit Delphi 2010 asynchron zu der eigentlichen Prozedur selbsgebastelt JSON-Antworten auszuwerten, ist ein Graus. Ich sollte schon alles in einem rutsch schreiben können, z.B. eine Zeile schreiben, eindeutige ID auslesen, in der anderen Tabelle verweis auf diese ID machen etc. Sollte Standard sein, kann aber auch sein, dass das halt wie in diesem Beispiel nicht überall Standard ist? (Mit neuem Delphi dürfte auch JSON einfacher sein...)

6) Multi-User: Hier kommt nun ein Knackpunkt: Das Datenbanksystem sollte problemlos mit 15 Clients zurecht kommen, die exemplarisch 1x die Minute auf eine Abfrage 20 Zeilen zurückgeliefert bekommen. Idealerweise sollte das auch mit bis zu allerhöchstens 50 Clients gehen, die durchschnittliche Installation kommt auf 1-2 Clients. Auch sollte es es kein Weltuntergang sein, wenn ein (1) Client im Netzwerk über eine ~2 MBit VPN Leitung angebunden ist und etwas abfragen will (wie gesagt: ~20 Zeilen als Ergebnis der Abfrage).

7) Keine "Exoten". Das neue Datenbanksystem sollte "generell bekannt sein" und die Verwendbarkeit auch in 10 Jahren sicher sein (Ansteuerbarkeit mit Delphi --> Komponenten; Backend/Server installierbar auf dem dann jeweils aktuellen Windows OS).


Mir ist bewusst, dass Ihr mir mit Antworten zu dem Thema viele, viele Stunden Recherchearbeit zu den einzelnen Anbietern abnehmt, was eigentlich unverschämt von mir ist auszunutzen. Aber viele Sachen -gerade bei der Programmierung- stecken im Detail, und bevor ich jetzt "laut Prospekt" das scheinbar am Besten für mich passende heraussuche, und nachher -wenn die Probleme da es- es heißt "Hättest du mal vorher gefragt" - frage ich nun halt vorher. Vielleicht wisst ihr ja zu den einzelnen Punkten K.O. Kriterien, wo Datenbanksystem X schon generell rausfliegt.

Vielen Dank im Voraus! :thumb:

[Neumann]

Also ich würde Firebird nehmen. Ist kostenlos, einfach zu installieren, wartungsarm und auch der Zugriff über Netzwerk erfordert nur eine Freigabe in der Firewall. Mehrere Zugriffe sind auch kein Problem; natürlich können nicht zwei Clients gleichzeitig eine Datensatz bearbeiten aber das geht wohl in keiner Datenbank.

Weiter Infos findet man z.B. bei IBExpert.

[Blackpit]

Zitat:

Zitat von Neumann (Beitrag 1465684)

Also ich würde Firebird nehmen. ...

Schließe mich an, erfodert ein wenig Einarbeitung.
Bei der genannten Konstellation würde aber der Umzug auf einen MS-SQL(Express würde vmtl. reichen) möglicherweise weniger Aufwand machen.

Gruß BP

[mensch72]

Mein Vorschlag: Access Datenbank mit dem "SingleFile.MDB" einfach beibehalten!

Da wo das MDB File physisch liegt, arbeitet die Applikation mit aktiviertem "TMS-RemoteDB-Server".
Auf allen anderen Clients arbeitet die Applikation via TMS-RemoteDB-Connection (RemoteDatasets/Querys... logisch & funktional im Prinzip 1:1 austauschbar mit ADOconnection, ADOdataset, ADOquery).

Wirklich langsamen ext. Clients kann man via Batch basierter Autoreplikation ("TMS-Echo") eine quasi lokale DB zum arbeiten bieten, und diese die Replikation läuft via Push/Pull Commits oder extra SyncRequest bei Bedarf.

Speziell wenn es bisher durchaus möglich&üblich mal fix das komplette DB-File gepackt hin&her zu schicken oder im Support so selbst schnell zwischen verschiedenen Mandanten-MDB-Files wechseln zu können... bietet sich das TMS Zeug auch schon ohne Nutzung von deren ORM durchaus an.
(~400€ will TMS dafür als "TMS Business Subscription" fürs erste Jahr haben, ab 2. Jahr dann jeweils 30% für die Update&Support-Verlängerung. Keine weiteren sonstigen Lizenz oder Installationskosten.)


https://tmssoftware.com/site/remotedb.asp
https://tmssoftware.com/site/tmsecho.asp

[mytbo]

Ich traue mich mal, das Open Source Framework mORMot ins Spiel zu bringen. Eine ausführliche Hilfe findest du hier:
https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html

Weitere Informationen findest du hier:
https://synopse.info/fossil/wiki?name=Downloads
https://synopse.info/forum

mORMot musst du nicht installierten. Es reicht aus, die entsprechenden Bibliothekspfade einzufügen.

Deine Anforderungen sind so gering, dass du alles mit dem integrierte ORM und embedded SQLite3 locker erledigen kannst. Um die Einbindung der SQLite Engine musst du dich nicht kümmern, wird automatisch in deine EXE mit einkompiliert. Du kannst dann gleich auf eine RESTful/SOA architecture umsteigen (klingt viel schlimmer, als es in Wirklichkeit ist). Deine eigentliche Arbeit ist mit mORMot schnell erledigt, das Problem dürfte sein, dich in mORMot einzuarbeiten. Es steht eine ausführliche Hilfe, viele Beispiele und ein freundliches Forum zur Verfügung.

Bis bald...
Thomas

[berens]

Vielen Dank zunächst für die bisherigen Antworten.

Firebird klingt ja generell erstmal interessant, und die gemeinsame Geschichte mit Interbase und Delphi ist generell ein gutes Zeichen für die Integrierbarkeit in und Migriegbarkeit für meine Anwendung. Da beide ja den selben Ursprung haben dachte ich eben flux, dass ich dann lieber die "Professionelle" Lösung von Interbase nehme, die bei Delphi mit dabei ist (je nach Version?), aber dann habe ich erst gesehen, was für Kosten da schon schnell für eine einfache Installation beim Kunden entstehen können, da muss ja "alles" pro-Kunde dazugekauft werden. Somit denke ich ist InterBase raus, die Auswahl wird kleiner und übersichtlicher.

Firebird: Einfache Installation, direkte Verbindung über TCP/IP, Datenbanken als einfache (leicht sicher und tauschbare) Datei auf der Festplatte. Brauche dann entweder andere Komponenten in Delphi als die TAdoConnection, oder den ODBC-Treiber - den müsste ich dann mit meinem Installer mitliefern (sollte Lizenztechnisch nix kosten; aber was sagen die Admins zu dem zusätzlichen Programm auf jedem PC). "Sorge" macht mir in diesem Fall -leider!- das "OpenSource", weil gerade bei den großen Kunden manche Administratoren Nachweise für Wartungsverträge für /alle/ Softwaretitel im Haus liefern müssen. Gibt's hierfür bestimmt auch zu kaufen, wäre aber so ein "Naja-Punkt". Trotzdem erstmal ein großes Plus. Liegen hier Erfahrungswerte vor, "wie oft" schon mal eine Datenbank korrupt/inkonsisten geworden ist (nicht durch Hardwaredefekt, nur im "Normalbetrieb" von jetzt auf eben)? Wie einfach oder "möglich" ist eine Reparatur? Danke @Neumann

Die Idee von @Mensch72 finde ich super mitgedacht; von TMS setzte ich schon erfolgreich andere (nicht-Datenbank) Komponenten ein. K.O. Argument ist hier leider dann doch wieder die Access-Datenbank, die sich pro Tag um ~60 MB aufbläht, auch wenn nur lokal gearbeitet wird. Natürlich könnte man auf dem "Server" dann besser die DB mal kurz schließen und im Exklusivmodus komprimieren/reparieren aber ... wenn ich jetzt schon die Software grundlegend ändere, dann versuche ich wirklich die o.g. Punkte abzudecken (gerade auch das tagesaktuelle Patchday 05/2020 Problem wäre damit nicht gelöst, aber egal: bis -hoffentlich- Microsofts Update für das Update kommt, habe ich eh mein Programm nicht auf ein anderes System umgestellt. Ich denke aber, dass andere Datenbanken (SQL, ...) wohl von diesem Patchdayproblem nicht (so) betroffen sind, wie mdb-Dateien ...). Von der Idee her trotzdem sehr gut.

Die Idee von @mytbo ist auch nicht verkehrt. REST und SOAP hab ich ja jetzt auch schon öfters gehört, speziell in Verbindung mit meinem Delphi 2010 (neue Version kaufe ich mir noch in diesem Jahr irgendwann ...) stellen sich mit aber beim Gedanken an REST APIs mit selbstgebastelten Indy-Threads und zusammengestückelten JSON-Interpretern alle Nackenhaare. Wenn du das empfiehlst gehe ich davon aus, dass es für Delphi gute Komponenten gibt, die sich um das Alles kümmern, und ich mich wirklich nur mit dem eigentlichen Datenbank-Kram beschäfigen muss. Da wir jetzt leider zwischen zwei Hauptversionen diese Datenbankumstellung ungewollt "übers Knie brechen müssen" -zwar nicht als Schnellschuss, aber dennoch "als Feature mit höchster Priorität", hätte ich glaube ich ziemlich Bauchweh damit, schon alleine ein Backend einzusetzen, das ich nicht auf Anhieb verstehe. Firebird und *SQL ist klar: Server installieren, Datenbank anlegen, mein überarbeiteter Client verbindet sich drauf - fertig. Bei Synopse -und das kann ich jetzt nach kurzem Überfliegen der Dokumentation nur vermuten- schein ja (weil "Framework") /mehr/ dabei zu sein, (HTTP Client und Server, JS Enging, ein MongoDB Server, ...) als das was ich jetzt als klassischen Datenbankserver abstempeln würde. Sicherlich ist dieses Framework für die vorgesehenen Verwendungszwecke genial, aber ich stehe gerade davor wie k.a. ... ein Automechaniker der einen zweiwöchigen Lehrgang für die Reparatur von einer neuen Generation Autos haben möchte, und er ein Angebot für einen Lehrgang bekommt, der alle Themen für Autos, Züge, Luftfahr und Schiffe abdeckt. Dauer des Lehrgangs nicht absehbar; der Nutzen für die erweiterten Fähigkeiten verpufft, weil Arbeitgeber=Autowerkstatt. Long story short: Ich glaube, dieses Framework würde mich gnadenlos überfordern. Bei einer komplett neuen, sauber konzeptionierten Software mit ausreichend Zeitpuffer für die Einarbeitung könnte ich mir das durchaus vorstellen, hier in diesem konkreten Fall aber glaube ich würde zu viel Energie verpuffen, weil ich mich wahrscheinlich mit trivialen Problemen "von Null" beschäftigen müsste, die ich nun mit ADO nach vielen Jahren endlich halbwegs gemeistert habe. Zudem kommt: Ich muss ja ein wenig Support beim Kunden leisten können, falls mit der DB-Server Software was klemmt, und ich glaube da wäre ich bei dem Framework echt raus. Vielleicht finde ich mal auf Youtube ein kleines Tutorial zu diesem Server und 'ner beispielhaften Delphiimplementierung, aber ich denke ihr wisst was ich meine wenn das Bauchgefühl sagt "das passt nicht", auch wenn ich es fachlich nicht ordentlich begründen kann.

> zwischen verschiedenen Mandanten-MDB-Files wechseln zu können
In der Tat ist es so, dass wir projektbezogen auch [die Inhalte der] Datenbanken für Kunden vorbereiten und Ihnen dann die Daten schicken. Bis dato konnte das auch eine Sekretärin durch das austauschen der .mdb erledigen. Mit *SQL stelle ich mir das schwerer vor, da man einerseits auf die Serverkonsole Zugriff haben muss (nagut, nofalls über die MMC als externe Konsole, bzw. Remotedesktop mit Admin-Daten). In jedem Fall muss der Admin wieder bemüht werden.

Bei diesen ganzen Überlegungen hat @Blackpit natürlich auch recht: Die (ungeplante) Migration meiner Software wäre wahrscheinlich auf MS SQL Express am einfachsten umzusetzen. Sofern ich nicht falsch liege, hätten meine "großen" Kunden dann ja auch die Möglichkeit, die Datenbank auf "ihrem" eigenen richtigen SQL-Server zu hosten, so dass eine zusätzliche Instanz von SQL Express nicht notwendig ist. Zudem haben viele Administratoren zumindest grundlegende Erfahrungen mit Microsoft SQL (Express), so dass diese bei Datenbankproblemen besser agieren können, als jetzt mit dem mORMot Framework wo zwei Ahnungslose dann miteinander telefonieren würden. Ja, natürlich! Vor der Implementierung muss auch ich mich mit der neuen Serversoftware beschäftigen und mich "nicht nur" grundlegend damit auskennen, aber ich wisst was ich meine: Grundlegende SQL-Server Kenntnisse sind bei mir vorhanden, bei dem Framework würde ich bei "weniger als Null" anfangen. Auch der Bekanntheitsgrad und die Updates von Microsoft sollten eigentlich viele Bedenken zerstreuen, "der Admin weiß, was bei Ihm installiert wird", wenn ich's mal so sagen darf.

Mir ist bewusst dass ich mich gerade anhöre wie "Will er eigentlich uns überzeugen, oder sich selbst? Scheint als hätte er schon eine feste Meinung..." aber mehr oder weniger ist es das ja auch. Letztendlich will ich von Fachleuten aus dem Gebiet hören: "Ja, für dein Vorhaben ist das genau richtig.". Es muss nicht die beste Lösung sein die technisch möglich ist - es muss nur mind. genauso gut funktionieren wie vorher und ich darf jetzt nicht die nächsten Monate und Jahre mit dem neu-lernen anderer Datenbankgebilde verbringen...
Firebird wäre *echt* cool, aber für das gute Gelingen unseren Projekten spielt auch immer das Bauchgefühl vom Administrator des Kunden eine wichtige Rolle. Wenn ich auf dem "großen Server" eines neuen Kunden ein Programm/Dienst als Administrator installieren will, und der Admin fragt "Watt ist Firebört, und was macht das auf meinem Server?" wirkt das anders als wenn ich Frage: Haben Sie einen eigene SQL-Server, oder soll ich den auf dem Infobildschirm mit drauf machen (gnaaa, braucht dann feste IP oder Hostnamen etc....)? Klar, Firebird kann ich auch auf "meinen" Infobildschirm-PC drauf machen, aber es beruhigt -denke ich mal- den Admin sehr, wenn er schon die Drittanbieterprogramme /kennt/ die evtl. da einfach so mitinstalliert werden.


Wenn wir jetzt mal den direkten Vergleich Firebird <--> MS SQL Express angehen... Was muss ich beachten?

1) Können auf Beide -beispielhaft!- bis zu 50 Clients gleichzeitig zugreifen? Lizenztechnisch okay? Wird wohl nie passieren, ich will mich aber nicht vorab künstlich beschränken. (Kann des MS-SQL Server das? Soweit ich weiß gibt's dann dafür die CALs im 25er(?) Pack.)

2) Frage nach der Stabilität/Inkonsitenzen speziell Firebird unter den o.g. Aspekten, bzw. störungsanfälligkeit von MS SQL (Dienst/Agent startet nicht, Port nicht erreichbar, Datenbankdatei-Probleme, ...)

3) Wie einfach ist das Deployment des Server über meinen Installer? Rechtliche Probleme / Folgekosten / Lizenzierung bei Firebird <--> MS SQL Express?

Freue mich auf Antworten, danke soweit!

[Andreas13]

Hallo,
schau doch mal hier rein: http://www.componentace.com/bde_repl...e_database.htm
Vielleicht ist es was für Dich: Absolute Database als embedded Database. Relativ einfach zu benutzen, alles wird – ähnlich wie bei Access – in einer einzigen Datei gespeichert.
Gruß, Andreas

[scrat1979]

Also ich würde auch für Firebird plädieren. Da hast du auch lizenztechnisch keinerlei Probleme. Ob sich die Installation der Clients in deine Installation integrieren lässt (also nicht lizenztechnisch sondern rein technisch) kann ich dir nicht sagen. Als Zugriffskomponenten kann ich dir aus eigener Erfahrung IBDAC von DevArt ans Herz legen. Auch hier entstehen dir für die einzelnen Installationen keine weiteren Folgekosten. Preislich völlig okay, für etwas mehr Geld gibt es den Source auch dazu.

Viel Erfolg bei deinem Vorhaben.

Auch für FireBird sprechen die Cracks hier im Forum :)

[scrat1979]

Zitat:

Zitat von Andreas13 (Beitrag 1465707)

Hallo,
schau doch mal hier rein: http://www.componentace.com/bde_repl...e_database.htm
Vielleicht ist es was für Dich: Absolute Database als embedded Database. Relativ einfach zu benutzen, alles wird – ähnlich wie bei Access – in einer einzigen Datei gespeichert.
Gruß, Andreas

Sehr gut, verwende ich auch. Allerdings wird von ComponentAce das Ablegen der Datei auf einem Netzwerkordner nicht empfohlen. Ich verwende es für einen Terminplaner mit ca. 100 Einträgen pro Tag. Das einlesen über das Netzwerk von 90 Tagen geht ratz fatz. Allerdings habe ich mir einen eigenen Server geschrieben der sich um die Datenbank kümmert, der Server kommuniziert über ein eigenes „Protokoll“ mit den Clients. Das heißt die Clients greifen nicht direkt auf die Datenbank zu. Möchte auch mittelfristig auf FireBird wechseln (auch einfach aus Interesse). Da habe ich momentan allerdings weder Zeit noch Lust. Verwende es nur „privat“ bzw. im eigenen Geschäft.

Aber prinzipiell eine tolle Datenbank die ich - vor allem für lokale Projekte - uneingeschränkt empfehlen kann!!!

[berens]

Danke für hinzugekommenen Einträge.

Absolute Database scheint generell ein tolles Projekt zu sein, sich aber jetzt -bis auf Details- nicht viel mit FireBird zu geben, dazu gibt es ja hier im Forum auch einige Beiträge, u.a. https://www.delphipraxis.net/147300-...die-frage.html . Ich will auf keinen Fall ADB schlecht reden, aber das Bauchgefühl sagt mir, dass die Jungs&Mädels von FireBird sich -auch wenn OpenSource- komplett auf ihr Kerngeschäft konzentrieren können und alle Energie für den Datenbankserver zur Verfügung haben, wohingegen ADB -auf den ersten Blick- so wirkt, wie eine von vielen Komponenten von TMS oder LMD... Keine externen Tools/Schnittstellen, nur für Delphi, und "Know-How" für Administrator und Probleme "nur" bei den Entwicklern (Herausgeber und die Programmierer als "Nutzer"), nicht bei den Nutzern oder Administratoren der Kunden. Ich will das auf keinen Fall schlecht reden; lediglich, naja... bemerken. Wenn die Datenbankproblemlos läuft - alles gut. Wenn's ein Problem gibt kann einem der ein oder andere Admin eines Kunden bei SQL vielleicht weiterhelfen.

Was ich noch wichtiges vergessen habe zu erwähnen:
Windows hat immer noch einen netten Bug, wo trotz fortlaufender Recherchen Netzlaufwerke manchmal die Verbindung verlieren - rotes X vor dem Laufwerksbuchstaben. Im Windows Explorer hilft ein einfacher "Klick" drauf, schon wird der Inhalt geladen. Diesen "Klick" kann man programmiertechnisch nur durch sehr viel gemauschel nachstellen (unsichtbares Öffnen einer unsichtbaren Windows-Explorer instanz auf diesem Netzlaufwerk und dannach TaskKill), und das leider auch nicht immer zuverlässig, bzw. die TAdoConnection kann sich dann nicht unbedingt neu Verbinden lassen. DriveExists und FileExists liefern dann einfach immer False zurück, bis das Programm neu gestartet wird. Da dieses Problem unabhängig von dem Datenbanksystem auch in Zukunft immer wieder auftreten wird, würde ich schon sagen, dass ein Server via TCP/IP her muss, und dateibasierte Datenbanken /via Netzlaufwerk/ nun in der Entscheidungsfindung eher ein Ausschlusskriterium sind. Korrigiert mich...

Ich glaube, letztendlich wird es auf FireBird oder MS SQL Express hinauslaufen.

Zu meinen Fragen:

1) Können auf Beide -beispielhaft!- bis zu 50 Clients gleichzeitig zugreifen?
> Laut https://www.mcseboard.de/topic/14685...l-db-connects/ gibt es keine Beschränkungen bei der Clientzahl bei SQL Express (bzw. 32tausend). Somit sollten beide Systeme geeignet sein. Somit erledigt.

2) Frage nach der Stabilität/Inkonsitenzen speziell Firebird unter den o.g. Aspekten, bzw. störungsanfälligkeit von MS SQL (Dienst/Agent startet nicht, Port nicht erreichbar, Datenbankdatei-Probleme, ...)
> Erfahrungswerte? Irgendwer?

3) Wie einfach ist das Deployment des Server über meinen Installer? Rechtliche Probleme / Folgekosten / Lizenzierung bei Firebird <--> MS SQL Express?

> Lassen wir bei Microsoft mal die lizenzrechtliche Frage außen vor. Der SQL-Express Installer ist ausschließlich als Online-Installation (300MB Download) erhältlich, Offline-Installer gibt's afaik zwar auch im MSDN, aber das würde unser Installationspaket ja auch auf satte ~330 MB aufblähen. Entweder müsste man einen Assistenten für die Installations des SQL-Servers einprogrammieren (Link zum Download, Anleitung, ...) oder sich was anderes einfallen lassen. Eine kleine, und vor allem: schnelle Demo-Installation und Teststellung unserer Software wäre für technisch nicht versierte Interessenten dann schon ein großes Hindernis --> kein Kauf. Das wäre wiederum ein klarer Vorteil für FireBird. Ich muss das mal ne Nacht drüber schlafen und das mit dem Kollegen besprechen...

[IBExpert]

Wenn du dir mal konkret nahezu alles know how was man braucht, um die komplette firebird installation zu verstehen, in 2 stunden reinziehen möchtest, schau dir mal dieses video an https://www.youtube.com/watch?v=MIyA8xqTWi0

Große vorteile für dich bei firebird meiner Meinung nach:

-Installation als batch mit einer einzigen Zeile in dein setup integrierbar, erstellt dann sogar einen eigene instanz mit eigenem Namen und einem eigenen tcp ip port, kommt also mit bereits installierten älteren oder neueren Versionen überhaupt nicht in konflikt. ado kram benutz ich zwar nicht, aber aus der Delphi Welt heraus gibt es mit FireDAC oder devart.com unidac/ibdac sehr gute Bibliotheken, mit denen du nativ da dran kommst und auf dem Weg schnell potentielle ADO Probleme aufgrund von Microsoft updates oder sonstiger Gründe vermeiden kannst.

-Bei Firebird kannst du deine Installation wenn du willst auch komplett Ohne jegliches Setup laufen lassen, firebird im Applikationsmodus braucht gar nichts in der registry oder im Systemverzeichnis, deine eigene Firebird Instanz kann neben diversen anderen Firebird Versionen parallel laufen, ohne das deren Updates dein System zum Stillstand bringt. Sämtliche für Firebird erforderliche Dateien kannst du ohne irgendeinen regsvr32 schrott oder sonstwas an Registry Orgien zum laufen bringen und uneingeschränkt beliebig oft an jeden verteilen, es kostet niemals Geld und ist extrem einfach zu verstehen, daher extrem einfach zu warten. Eine komplette Applikation auch netzwerkfähig als ausgepacktes zip file zu verteilen ist mit Delphi exe, ein paar dlls für die nativen client libs firedac/ibdac und fb server im applikations modus technisch überhaupt kein Problem.

-50 User als Obergrenze von dir genannt ist weit davon weg, was Firebird als Obergrenze kann. Wir haben Installationen mit hunderten Usern und weit über einem Terabyte an Datenbankplatz in Benutzung. Wenn du deine SQLs und deine Datenbankmodel nicht völlig scheisse programmierst und die Firebird Hilfsmittel benutzt, um fehlende Indizes usw. zu erstellen, geht das alles auch ohne SPs, aber du wirst früher oder später sehen, das deren Vorteile doch immens sind. Weiter über eine Milliarde Datensätze in einer Tabelle sind sicherlich auch Limits, die du nicht so schnell erreichen wirst.

-Wie viele Datenbanken du einsetzt und wie groß deine Datenbanken sind, ist komplett unlimited.

-Bei entsprechender Programmierung ist Firebird komplett wartungsfrei, auch 24/7 , soweit das unter Windows überhaupt irgendeine Software ist, weil du bei aktuellen Windows Version gerne mal ungefragte Reboots wegen Zwangsupdates untergejubelt bekommst.

-Auch auf alle aktuellen Windows Versionen bekommst du noch eine 15 Jahre alte Firebird 1.5 Version zum laufen, wenn du es aus welchen Gründen auch immer mal brauchen solltest.




Was meiner Meinung nach deutlich gegen MSSQL Express spricht

-nach meiner Kenntnis haben alle mssql Express Editions ein Datenbank größen Limit von 10 GB, siehe https://docs.microsoft.com/en-us/sql...BoxScaleLimits

Wenn dir das reicht, dann ok, aber wenn du deinem Kunden bei 9,9 GB so langsam erklären musst, das er langsam mal den Geldbeutel öffnen muss, würde für mich nicht in frage kommen, weil das immer das negative Marketing ist, du bist schuld weil du das nicht gleich von anfang an gesagt hast usw. (auch wenn dem nicht so ist).

-Wenn Irgendein Kunde dann deine Software einsetzt und von server A auf Server B umziehen will, server B aber die neueste OS Version hat und nicht die, die deine Software bisher als einzige unterstützt, wird es ganz schnell passieren, das dein Support sich ohne Ende damit beschäftigen muss, den Kram bei diesem Kunden zum laufen zu bringen. Dafür wird er garantiert wenig bis gar nicht zahlen wollen.

[TurboMagic]

Bei der Nutzung von Firebird könntest du die in Delphi enthaltenen FireDAC Zugriffskomponenten benutzen. Die kapseln auch das DB Backup/Restore von Firebird. Davon gibt's inzwischen eine alte und neue Variante. Ich habe mich bisher nur mit der alten auseinandergesetzt und Backup/Restore sind dabei recht einfach.

Den Firebird Installer kann man auch "silent" aufrufen. Meine Anwendung benutzt einen Inno Setup Installer (FB vermutlich auch) und der enthält das Setup von FB und führt es "teilweise silent" aus. Einziges Problem ist die erkennung ob ein Neustart nach der Installation nötig ist. In 99% der angezeigten Fälle scheint das nicht der Fall zu sein, in 1% wohl schon...

Es ist auch zu beachten, dass auf dem Zielrechner nicht schon ein FB Server von einer anderen SW läuft (habe in der Arbeit genau einen Rechner mit einer speziellen anderen gekauften SW), dann gibt's mit dem Port des Dienstes ein Problem. Da hab' ich mich bisher aber noch nicht gekümmert.

FB gibt's auch in einer Embedded Variante, dann liefert man einfach die nötigen Dateien so mit und inzwischen kann das glaube ich sogar mehrere Verbindungen unterstützen, was dieser embedded Variante aber fehlt ist der Login soweit ich mich erinnere.

[TigerLilly]

Ich kann nur über meine Erfahrungen mit MSSQL Express reden. Und das hat sich für uns sehr bewährt. Unsere Software wird als Einzelplatzversion (Server+Client auf einem Gerät) oder eben im Netz betrieben. Das ist gut skalierbar, und nahezu ohne Probleme, eigentlich tauchen nur 2 Dinge auf: Der Versuche, den SQL Server zu installieren, wenn noch Updates "pending" sind. Und manchmal dreht Windows den Dienst einfach ab + er muss einmal manuell gestartet werden. Unsere Kunden sind von Studenten bis hin zu 50 User Firmen alles dabei. Das Setup ist von uns automatisiert + läuft eigenständig durch. Unsere Software wird auch an Fachschulen eingesetzt, da installiert dann ein ganzer Jahrgang die Software auf den Privat-PCs. Bei ca 1% gibt´s Handlungsbedarf + dann ist es zu 99% ein fehlender reboot wg der Updates.

Die Größenbeschränkung gilt pro DB, im schlimmsten fall macht man weieter DBs, lagert Tabellen dorthin aus + bindet die über SYNONYM ein. Das geht völlig transparent + ohne die APP ändern zu müssen.

Express ist kostenfrei + kann genauso gut im Netz eingesetzt werden.

[Delphi.Narium]

Auf FireBird kann man (wenn's denn sein muss) auch über ODBC zugreifen. Dann muss man im Programm nur den Connectionstring ändern. Ist der konfigurierbar hinterlegt, muss man nur die Konfiguration ändern.

Neben der Installation von FireBird muss dann auch der ODBC-Treiber installiert werden.

Man kann sich dann damit erstmal um die "Baustelle" Datenbankwechsel von Access auf Firebird kümmern und später, wenn es dann doch erforderlich sein sollte, um den Austausch der Datenbankkomponenten im Programm.

'ne MDB kann man auch ohne Access packen, einfach 'ne passende Prozedur ins Programm einbauen: Delphi-Praxis: Access datenbank komprimieren und reparieren

Du schreibst weiter oben, dass den ganzen Tag auf die MDB zugegriffen wird. Auch die ganze Nacht? Das ganze Wochenende?

Wenn es irgendeinen "Wartungszeitraum" gibt: 'nen Service schreiben, der den Job übernimmt oder ein Programm, das das per Taskplaner erledigt.

Achso: Ist der Connectionstring konfigurierbar hinterlegt, müssen nicht alle Kunden gleichzeitig wechseln und Du musst nicht für die Zeit des Wechsels zwei Programme vorhalten: Eins für Access, eins für FireBird.

Solange in den SQL-Statements nix absolut accessspezifisches genutzt wird, sondern nur Standard-SQL, sollte das transparent sein. Klar: Tabellenstruktur, Spaltennamen, ... müssen identisch sein.

[Billa]

@Service: wir haben das mal flexibel gelöst.
Jeder erfolgreiche Aufbau einer Verbindung erhöht einen Zähler, jeder Abbau verringert ihn. Wenn der Zähler 0 ist, darf man bei Bedarf den Service anschmeißen. Das setzt ein anderes Flag in der DB. Dann darf sich kein Client verbinden. Nach Beeden des Service wird das Flag wieder entfernt und man kann weiter arbeiten.
Das war nur eine Zwischenlösung bei einem "24/7"-Programm (es gab keine vorhersehbaren Zeiträume) vor der Umstellung auf Firebird....

[Hobbycoder]

Zitat:

Zitat von Billa (Beitrag 1465772)

@Service: wir haben das mal flexibel gelöst.
Jeder erfolgreiche Aufbau einer Verbindung erhöht einen Zähler, jeder Abbau verringert ihn. Wenn der Zähler 0 ist, darf man bei Bedarf den Service anschmeißen.

Das haben wir in einer Anwendung zwar ähnlich, aber doch etwas anders gelöst. Denn wenn ein Client abstürzt, dann kann er seinen Zähler nicht mehr rausnehmen.
Wir haben extra ein Tabelle mit den Felder Clientname, Datum/Zeit. Startet ein Client, so trägt er sich mit Namen und Zeit ein. Alle 5 Minuten aktualisiert er seine Zeit in dem Datensatz. Wenn er sich anmeldet, löscht er seinen Datensatz.
Stürzt er ab, prüft er beim Eintragen ob noch ein alter Datensatz vorhanden ist und übernimmt diesen.

Schaut nun der Service drauf, kann man a) sofort die Toten Datensätze erkennen (Zeit ist älter als 5 Minuten) und b) gezielt die User ansprechen, die noch drin sind.

[berens]

Hallo zusammen und nochmal herzlichen Dank für die zahlreichen -sehr hilfreichen- Antworten.

Zur allgemeinen Erheiterung möchte ich noch das Best-Of der Besprechung mit meinem Kollegen (Vetrieb) zu den nun zur Verfügung stehenden Alternativen (bei Access bleiben, MS SQL (Express), Firebird) wiedergeben: "Dann implementier doch einfach alle Drei. Bei jeder Datenbankabfrage vorher ne kleine if-then Abfrage für die jeweils benötigten Komponenten - kann auch nicht mehr Arbeit sein als nur die eine neue Komponente zu implementieren.". Ja ne is klar.

Ich meine vom Grundgedanken hat er ja nicht unrecht: Kleine Kunden könnten auf "Einzelplatzlösungen" (1 Infobildschirm, 1 Redaktions-PC) ja auch in Zukunft -mit den bekannten Mankos- schon noch auf .mdb-Dateibasis weiterarbeiten. Auch die Demoinstallationen bei Interessenten wären auch hier noch schnell und einfach möglich. Und die Ansteuerung von MS SQL und Firebird über den ODBC-Treiber (danke @Delphi.Narium , nochmal gute Idee) würde ja die Änderungen (größtenteils) auf die TAdoConnection beschränken. Der Benutzer könnte ja dann mit der klassischen Installation anfangen (lokale Datenbank), und -auf Wunsch oder Anraten von unserem Support (mir :stupid:) auf ein größeres System migrieren. Den FireBird Server könnte man ja als optional installierbaren Punkt in unserem Installer anbieten, oder als zusätzliches Stand-alone Downloadmodul (oder natürlich den offiziellen Download verlinken). Den ODBC-Treiber für Firebird würde ich dann wahrscheinlich bei allen Installationen zwangs-mitinstallieren.

Wahrscheinlich würde ich die Migration so planen:
1) Einen Assistenten anbieten, um die Datenbankverbindung auswählen zu können (.mdb / MS SQL / Firebird), also entweder Dateipfad oder Server/IP, User/Pass (wie speichert man das wieder sicher?) , der dann zukünftig von der TAdoConnection verwendet wird.
2) Einen Upscaling-Assistenten anbieten, der in der leeren Datenbank auf dem Firebird/SQL Server alle notwendigen Tabellen erzeugt bzw. auf den aktuellen Stand bringt, und -nach Möglichkeit- direkt alle Daten 1:1 rüber kopiert.
3) Auslagern aller direkten Datenbankzugriffe von den jeweils Themenbezogenen Units in eine (oder mehrere) Datenbank-Units, wo situationsbezogen (als Prozeduren mit entsprechenden Parametern) der SQL-String und die Parameter vorbereitet werden, so dass ich in den themenbezogenen Units nur mit (q = TAdoQuery --> q.First, q.Next, q.EOF, q.FieldByName('Text1').AsString := 'Test'; q.Post, q.Close etc.) arbeite, aber alle Datenbank-nahen Befehle (q.SQL.Add('...'); q.Parameters.ParamByName(...) ) in dieser einen(?) Datenbankunit bleiben. Das hätte den Vorteil, dass ich recht einfach und übersichtlich hierfür dann Unit-Tests schreiben kann, die man ggf. auch zur Laufzeit beim Kunden laufen lassen kann, um eventuelle Inkompatibilitäten zu verschiedenen MS SQL / FireBird Versionen aufdecken zu können, die ggf. beim Kunden auftreten können. Ich rede hier nicht von eventuellen Bugs, aber von Erfahrungswerten nach dem Motto: Bei Access-SQL müssen/können bei Abfragen Tabellen/Feldnamen in [eckigen].[Klammern] stehen, WHERE TEXT1="" muss in FireBird-SQL evtl. WHERE TEXT='' lauten etc.etc. Halt diese kleinen Spitzfindigkeiten, bei denen ich mich auch gerne früher schon and den SQL92 Standard gehalten hätte, aber Access manche Sachen eben doch explizit anders haben will... Beispiel: Eine Tabelle nennt sich "Layout". Böses Wort, könnte als systemreserviert Interpretiert werden. Wenn ich nun "alle" meine SQL-Abfragen/Befehle/Unit-Tests beim Kunden nacheinandere ablaufen lasse(n kann), sehe ich z.B. falls

Code:

CREATE TABLE [Layout] ...

auf dem einen System fehlschlägt, und

Code:

CREATE TABLE "Layout" ...

auf dem Andern, und entsprechend darauf reagieren.

Somit wären denke ich mal gute Voraussetzungen für die neue Hauptversion geschaffen, und man kann diese ganzen Schritte auch wirklich Schritt für Schritt gehen, ohne das komplette Programm von jetzt-auf-eben "anders" zu haben. Die [zusätzlichen] Firebird-Komponenten wären das Sahnehäubchen, aber ich glaube die paar (Milli-) Sekunden leistungssteigung stehen -im Moment zumindest- in keinem Verhältnis zur der vorteilhaften Dreigleisigkeit über ADO/ODBC. Später aber gerne!

@Delphi.Narium: Danke für den Link zum komprimieren und reparieren der Datenbank. Dieses Verfahren setzen wir afaik bereits ein, dies scheitert jedoch tatsächlich in der Praxis daran, dass TADOConnection die Datenbankverbindung zum Reparieren nicht aufbauen kann, weil die Datenbank gerade defekt ist. Naja, Offtopic, anderes Thema. :)

Delphi-Quellcode:

    v := CreateOLEObject('JRO.JetEngine');
    try

      try
        // Datenbank komprimieren, diese wird unter neuem Dateinamen gespeichert
        V.CompactDatabase('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + _DB,
                          'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + CompressedFileName);
      except
        Result := False;
      end;

Zur Offline-Erkennung der Clients hatte ich ein ähnliches System wie @Hobbycoder, allerdings war es zuletzt am häufigsten vorgekommen, dass genau eben DURCH das Schreiben dieses "Status" in die Datenbank diese "zerstört" wurde. Gefühlsmäßig behaupte ich mal, dass die Existenz der MeineDatenbank.ldb - Datei schon ein guter Indikator ist, ob die Datenbank gerade gewartet werden kann (wenn sie existiert, dann nein). In der Regel läuft das Löschen der Datei -soweit ich mich erinnere- auch relativ zuverlässig. Klar kann "mal" ein Client abstürzen und sie wird nicht gelöscht (?), aber der nächste Client korrigiert das afaik, sobald dieser sich dann trennt. Somit sollte zumindest 1x die Woche eine "Offline-Wartung" technisch erkennbar und machbar sein - mit MS SQL oder Firebird hoffentlich wirkliche nie mehr notwendig!


Ich hake jetzt mal "offene Frage" ab, und bedanke mich herzlich bei allen Teilnehmern für die guten Beiträge, die meiner Meinung nach sehr gut zu einer klaren Richtung mit einem umsetzbaren Fahrplan geführt haben!

Zu der "Problematik", dass ich mir den Connection-String nun pro Benutzer/PC mit ggf. ServerIP, Name und PASSWORT merken muss, gibt es ja im Forum zahlreiche Beiträge, ebenfalls mit dem Verweis auf den Mixed-Mode, Trusted-Login etc., bei denen Windows ja einfach die Anmeldedaten (bzw. das Token) des aktuellen Benutzers verwendet. Falls ihr gerade ein "Best-Practise" zur Hand habt, wie der Benuzter die Datenbankverbindung an sinnvollsten (einfach!) konfiguriert,
1) ohne den kompletten TAdoConnection.ConnectionString-Assistenten zu verwenden
2) (Sicheres?) abspeichern dieses Strings trotz/mit Benutzername/Passwort?
bin ich natürlich total dankbar dafür, ich scheue mich aber natürlich auch nicht davor, brav die SuFu zu verwenden. :stupid:

Nochmals Danke!

[Blup]

Wir haben die Verbindungsinformationen in einer zentralen Konfigurationsdatei auf einem Server abgelegt. Diese Datei ist verschlüsselt, der Schlüssel ist nur der Anwendung bekannt. Auf den Arbeitsstationen wird nur der Pfad (bzw.Link) zu dieser Konfigurationsdatei ausgewählt und gespeichert. Die Konfiguration muss so nur einmal vorgenommen werden.

Wir unterscheiden zwischen Datenbankbenutzer und Anwendungsbenutzer. Datenbankbenutzer gibt es für die Installation nur einen (Name und Kennwort muss nur die Anwendung wissen). Die Anwender und deren Passwörter(bzw. Hashwert) sind in der DB gespeichert und werden durch die Anwendung verwaltet.

[Rolf Frei]

Ich nutze seit vielen Jahren ElevateDB. Diese ist in Delphi geschrieben und ist daher eigentlich die beste Lösung in der Delphi Welt. Je nachdem wie man es einsetzt (File oder C/S), braucht es keine Installation. Alles ist in der EXE enthalten, also die ganze Engine. Die DB bietet das meiste was auch die "grossen" DB's bieten, also z.B. Replikation, Backup, Stored Procedures/Functions, Einbindung eigener Funktionen über DLL's, die nicht per Stored Procedures zu machen sind.

www.elevatesoft.com

Ich nutze das seit Jahren und bin super glücklich damit, weil ich da alles habe, was ich brauche und ich da keine komplizierte Einrichtung der DB benötige.

[mytbo]

Wenn du die ORM Funktionalität von mORMot verwendest würdest, müsstest du beim Zugriff auf eine bestimmte Datenbank nur die jeweilige Connection anpassen. Um den Rest kümmert sich das Framework. Im Samples Verzeichnis findest du unter "12 - SynDB Explorer" die Implementierung eines Datenbank Explorers. Im Beispiel stellst du eine Verbindung mit dieser Funktion her:

Delphi-Quellcode:

function TryConnect(C: TSQLConnection; ...): boolean;
const 
  CONN_CLASSES: array[TExpConnectionType] of TSQLDBConnectionPropertiesClass = (
    TSQLDBOracleConnectionProperties,
    TOleDBOracleConnectionProperties,
    TOleDBMSOracleConnectionProperties,
    TOleDBMSSQLConnectionProperties,
    TOleDBConnectionProperties,
    TSQLDBSQLite3ConnectionProperties,
    TOleDBJetConnectionProperties,
    TODBCConnectionProperties,
    TSQLDBWinHTTPConnectionProperties,
    TSQLDBZeosConnectionProperties);
...   
begin
  ...
  Props := CONN_CLASSES[C.Connection].Create(C.Server, C.Database, C.UserName, Pass);
  ...
end

Und mit einfachen Funktionsaufrufen kannst du einen Datensatz in der DB anlegen, aktualisieren oder löschen. Das Schöne ist, man muss sich um nichts kümmern. Und wenn handgeschriebenes SQL erforderlich ist, steht das Framework nicht im Weg.

Delphi-Quellcode:

type
  TSQLMeineDaten = class(TSQLRecord)
  ...
  published
    property Aktiv: Boolean read FAktiv write FAktiv;
    ...
  end;

var
  dataObj: TSQLMeineDaten;
begin
...
  .AddOrUpdate(dataObj);
  .Delete(TSQLMeineDaten,  dataObj.ID);
  .RetrieveList<TSQLMeineDaten>('Aktiv = ?)', [isAktiv]);

Bis bald...
Thomas