Offline Ein-Datei Datenbank

Diskutiere das Thema Offline Ein-Datei Datenbank. Hallo, ich bin auf der Suche nach einer besseren Lösung, als es momentan mit Excel umgesetzt...

theuser

Mitglied
Thread Starter
Mitglied seit
02.12.2005
Beiträge
837
Hallo,

ich bin auf der Suche nach einer besseren Lösung, als es momentan mit Excel umgesetzt ist:
Ich habe in Excel eine Login-Maske mit Benutzer programmiert, so dass je nach Benutzer Bestimmte Tabellenblätter sichtbar sind, bzw. Einträge in den Tabellen abhängig vom Login gefiltert sind. Zusätzlich ist dort auch ein Timer drin, der die Datei automatisch beendet, wenn längere Zeit kein Zugriff erkannt wurde, um zu vermeiden, dass ein Benutzer vergisst die Datei zu schließen. In der Aktuellen Umsetzung kann ich damit aber keine zwei Excel-Dateien parallel offen haben.
Die Datei ist auf einem Netzlaufwerk, jedoch wird diese auch mit externen Kunden geteilt, so dass diese per mail verschickt wird, in der Zwischenzeit auf dem Laufwerk gesperrt und dann wieder eingespielt.

Ich möchte gerne eine Datenbanklösung erstellen, die jedoch 'in einer Datei' umgesetzt ist, so dass diese auch per Mail verschickt werden kann. Letztlich wird nur Text und Verknüpfungen zu anderen Dateien eingefügt, keine Bilder oder dergleichen. Gebe es dazu eine Lösung?
Ich kenne die Lösungen mit Apache und Webserver etc. aber das wäre 'zu viel' da ich nicht bei jedem einen lokale installation durchführen kann. Auch eine Online-Lösung scheidet auf Grund Sicherheitsrichtlinien aus.

Die Anwendung soll primär unter Windows laufen, jedoch gebe es ev. auch Mac Nutzer.

Bin für jeden Vorschlag offen.

Gruß
 

ruerueka

Mitglied
Mitglied seit
04.04.2004
Beiträge
1.460
Bitte sei mir nicht böse, aber der von dir geschilderte Prozess erscheint mir etwas "merkwürdig".
Eigentlich "schreit" dein Anwendungsfall nach einer Onlinelösung. Aber das ist natürlich nur meine private Meinung:
Bis du alle Konfliktfälle und Sicherheitsprobleme mit einer 1-Datei-die-durch-die-Gegend-geschickt-wird-Lösung abgebildet hast, ist eine Menge zu programmieren.
Leider gibt es ja kein Access für Mac, aber eine Eigenentwicklung mit Filemaker oder LibreOfficeBase oder was komplett selbst programmiertes mit Derby oder SQLite könnte eine Lösung sein. Aber wie gesagt: Das sicher und robust hinzubekommen, ist viel aufwändiger, als einen lokalen Webserver bei dir zu betreiben und die Kunden über VPN verschlüsselt über ein Webinterface darauf zugreifen zu lassen. Wenn man das ordentlich umsetzt, ist das sicher, frag deine Bank, die betreiben dein Konto auf diese Weise ;-)
Die Sicherheitsrichtlinien, die zulassen, eine ausführbare Datei per Mail zu empfangen und zu starten, aber keinen verschlüsselten Webzugriff zu einem eindeutig identifizierten Partner nach außen zulassen, halte ich auch für fragwürdig.
 

tom555

Mitglied
Mitglied seit
18.10.2004
Beiträge
1.696
Du kannst zum Beispiel SQLLite nehmen, das erstellt die Datenbank in einer Datei. Wie es genau funktioniert musst du dir aber selber noch anschauen :). Ist auch etwas aufwändiger als Excel, da du die Tabellen usw. erst anlegen und neu befüllen musst. Ausserdem solltest du halt mit SQL Queries einigermassen zurechtkommen.

Loginmechanismen gehen da glaub ich nicht aber eventuell kann man Rechte für verschiedene User vergeben. Bei SQL Server gehts jedenfalls. SQLLite hab ich bisher nur sehr wenig benutzt.
 

theuser

Mitglied
Thread Starter
Mitglied seit
02.12.2005
Beiträge
837
@all: Danke für die Antworten. SQLite schaue ich mir an, wie es damit umgesetzt werden könnte, bzw. welche weiteren Anforderungen notwendig sind.
@roedert : ja mir ist der Widerspruch offensichtlich, wobei das Extern Kunden 'extern' im Sinne von anderen Abteilungen sind, die nicht am gleichen Standort sind aber dennoch vertraglich mit der Firma verbunden sind und Dienstleistungen durchführen.
 

kenduo

Mitglied
Mitglied seit
27.07.2017
Beiträge
1.343
Gibt es für SQLite auch Tools, die helfen, Formulare und die DB dahinter aufzubauen?
 

Lor-Olli

Mitglied
Mitglied seit
24.04.2004
Beiträge
8.993
Datenbankprogrammierung ist immer etwas komplexer, die Masken und Formulare sind in der Regel das kleinste Problem… Wer sich von den "ganz alten USern" noch an Hypercard erinnert (einfach zusammenklicken, allerdings keine Netzwerkfähigkeit) und es nur für Mac, iPad, iPhone nutzt, kann auch mal nach Ninox schauen. Es gibt eine standalone Lösung aber auch eine cloudbasierte (die man auch mit anderen System abfragen kann - mit letzterem habe ich aber keine Erfahrung). Meine Frau nutzt es als Access Ersatz für den Eigengebrauch auf dem Mac und obschon leistungsstark lassen sich Projekte sehr schnell umsetzen, vieles ist mit "klicken" erledigt. Der Preis ist auch fair. (38€ habe ich in Erinnerung für die Standaloneversion)
 

kenduo

Mitglied
Mitglied seit
27.07.2017
Beiträge
1.343
Ninox sieht nice aus, ist aber kein SQL, oder?
wie schnell kann man da Datenbanken erstellen?
Gibt es viele Vorlagen?
(oder nur die paar genannten auf der Website?)

SQLite hat den Vorteil, dass es 4free ist. Dachte mir, damit mal rumspielen hätte was, aber stimmt schon. Ninox bietet fertige Formulare, etc. Aber auf der anderen Seite hätte ich auch spass da mal rumzuspielen. Access ist schon etwas lange her :D
 

LoBulli

Mitglied
Mitglied seit
16.10.2019
Beiträge
195
Warum brauchst du SQL. Das ergibt doch eigentlich nur Sinn, wenn du auch z.B. über ODBC darauf zugreifen willst. Wesentlicher ist, dass eine DB relational ist und da bist du mit NINOX bestens bedient. Meines Erachtens gibt es z.Z. nichts Besseres unter macOS. Ich habe es mir besorgt, nachdem meine Filmaker Lizenz nicht mehr lauffähig war und meine DBen 1:1 umsetzen können. Und für dich wohl wichtig; anders als in Access besteht eine Ninox-DB nur aus einem einzigen File (Archiv), das du jederzeit exportieren und versenden kannst ohne ein Runtime erzeugen zu müssen.
 

kenduo

Mitglied
Mitglied seit
27.07.2017
Beiträge
1.343
Also quasi wie eine SQLite.
SQL deshalb, falls man irgendwann mal die Daten aus Ninox auslesen will oder es Ninox nicht mehr gibt und man die DB behalten will, und und und..
 

LoBulli

Mitglied
Mitglied seit
16.10.2019
Beiträge
195
Wenn das wirklich jemals passieren sollte, dann kannst du doch alle Daten oder eine Auswahl einfach als CSV-Datei exportieren. Ninox bietet dir die entsprechenden Funktionen.
 

Phrasenbieger

Mitglied
Mitglied seit
15.04.2008
Beiträge
822
Kann man da nicht vielleicht in 20 Minuten was in SharePoint basteln?
 

kenduo

Mitglied
Mitglied seit
27.07.2017
Beiträge
1.343
Wenn das wirklich jemals passieren sollte, dann kannst du doch alle Daten oder eine Auswahl einfach als CSV-Datei exportieren. Ninox bietet dir die entsprechenden Funktionen.
Kann man, aber dann alles neu machen.
Aber ja, Ninox ist schon ziemlich nice. Kann man definitiv ausprobieren.
 

kenduo

Mitglied
Mitglied seit
27.07.2017
Beiträge
1.343
Oder das Datenbankmodul des plattformübergreifenden kostnix LibreOffice nutzen.

https://de.libreoffice.org/discover/base/

Das ist allerdings keine DAU Ein-Klick-Lösung und muß erst zB. mithilfe von YouTube Tutorials erlernt werden.
Auch eine Idee, da zum Beispiel MySQL unterstützt wird. Kann man sicherlich auch dann auch mit PHP/HTML/CSS auslesen, beschreiben und sich so schöne Formulare auf localhost machen (oder?)
 

Schiffversenker

Mitglied
Mitglied seit
25.06.2012
Beiträge
10.688
Das ist allerdings keine DAU Ein-Klick-Lösung und muß erst zB. mithilfe von YouTube Tutorials erlernt werden.
Eine DAU-Ein-Klick-Löung bei a. einer Datenbank und b. Mehrnutzerlösung und c. übers Netz?
Das kann nie und nimmer was werden, spätestens bei c. wird es massive Probleme geben.

Und wer DAU-Einklick-Lösungen sucht, sollte sich sowieso nie und nimmer ins öffentliche oder halböffentliche Umfeld wagen, nie weitere Benutzer zulassen. Das war schon vor dem Horror der DSGZO so.
Datenbanken für zuhause sind eine Sache, Datenbanken für viele Nutzer und übers Netz, das ist eine völlig andere Kategorie.
Datenschutz? Gleichzeititiger zugriff mehrerer Benutzer auf einen Datensatz? Nur mal als wichtigste Probleme.
 

kenduo

Mitglied
Mitglied seit
27.07.2017
Beiträge
1.343
Na gut, dass der Threadersteller das garnicht wollte ;)
 
Oben