Was soll den bitte eine große Datenbank sein? Definiere "groß". Das war eine rethorische Frage, eine Antwort wird definitiv nicht erwartet.
Wie schon hier steht, solltest Du dich um eine "echte" Datenbank bemühen, sobald Du eine Multiuser-Umgebung hast. Es gibt Workarounds, die sich allesamt nicht als Handhabbar erwiesen haben.
Eine "echte" Datenbak ist immer mit einem Dienst (Service) verbunden, die diese DB verwaltet. Was Du da mit deiner Fritzbox vorhast und absolut nicht ideal für SQLite, um es vorsichtig auszudrücken.
Wenn es wirklich nicht anders geht, dann mach das so, aber programmiere Dir irgendwas womit Du sicherstellst, dass nur eine Anwendung /Rechner gleichzeitig die DB benutzt bzw. benutzen kann.

Ich hoffe mal nicht, dass du dBASE meinst. Ich wußte nicht mal, dass es das Zeugs noch immer gibt....
Zudem, selbst das alte dBASE Classic ist ein komerzielles Produkt. Und ich glaube nicht, dass du hier viel Hilfe zu so einem DBMS erhalten wirst.
Warum nicht SQL Server Express von MS? Oder eine der Open Souce Datenbanksysteme?
Ob es Connectoren gibt, die du in Visual Studio einbinden kannst, musst du nachforschen.

Den MS SQL-Server kannst du auch auf einem der Clients laufen lassen. Der muss dann halt an bleiben.

dema schrieb:

Ich habe mal gehört das es eine Datenbank ähnlich wie SQLite gibt die auch mehrere Benutzer gleichzeitig erlaubt zum Lesen und Schreiben.

Ja. Heißt SQLite

SQLite kann sehr wohl für mehrere Benutzer concurrent eingesetzt werden.
Parallele Lesezugriffe sind sogar sehr schnell.
Nur bei vielen parallelen Schreibzugriffen auf dieselbe Tabelle geht die Performance in die Knie.

dema schrieb:

für 3 oder 5 Benutzer

Das ist jetzt nicht besonders viel. Da würde ich einen Versuch mit SQLite durchaus wagen.

dema schrieb:

Die Datenmenge wird groß sein.

Ich habe hier eine DB mit 10TB Daten und ein paar Billionen Records.
Das ist für mich zumindest groß.
Google wird so was als klein betrachten.
Was bedeutet "groß" bei dir?
Und wie hoch ist deine Schreibfrequenz?

Multi-User ist ohne zentralen Server einfach nicht möglich. Und selbst mit zentralem Server ist multi-User dennoch nicht einfach. Stell dir folgendes Szenario vor:

User 1 meldet sich an, öffnet eine Form, die mit einer bestimmten Tabelle verknüpft ist, und beginnt diese zu bearbeiten.

In der Zwischenzeit meldet sich User 2 an, öffnet denselben Datensatz, ändert ein oder zweio Details, und speichert den Datensatz ab.

Nun ist User 1 mit seinem Bearbeiten fertig, und speichert ebenfalls den Datensatz ab.

Nun hast du effektiven Datenverlust, da die Änderungen, die User2 vorgenommen hat, verloren sind, ohne dass jemand (außer User2 natürlich) mitbekommen hat, dass die Änderung jemals da war.

Natürlich gibts dafür Lösungen, die einfachste davon, die auch mit Dateibasierten DBs einigermaßen funktioniert, dass man immer eine spalte update mitführt, die die Anzahl an updates die an jedem Datensatz vorgenommen mitzählt. in deinem Update-Befehl baust du die dann in den WHERE part ein, und inkrementierst im SET um eins. Wenn dann jemand bereits dran gearbeitet hat, wirft dir SQL nen Fehler, und du kannst dem User sagen "Yo, es hat schon jemand dran gearbeitet."

EaranMaleasi schrieb:

Multi-User ist ohne zentralen Server einfach nicht möglich

Ja. Einen DB-Server oder ein File-Server. Im Netzwerk oder in der Cloud. Varianten gibt's viele.

Die Problematik konkurrierenden Schreibzugriffs hast du immer, ob du eine serverbasierte DB oder eine filebasierte DB verwendest.
Der einzige Unterschied ist die zentrale oder verteilte Nutzung der CPU.
Die Datenzugriffs- und Lockmechanismen sind ähnlich.
Nur benötigst du weniger lokale Ressourcen, wenn du diese Mechanismen auf einem Server rechnen lässt.