Portable Datenbank in einer Datei

[lydec]

Hallo,

ich habe bisher ein Protokollblatt in Excel mit mehreren Funktionen programmiert, würde aber aufgrund gestiegener Anforderungen lieber auf eine Datenbank umsteigen. Jedoch gibt es nicht die Möglichkeit per Web zuzugreifen, sondern es sollte alles in einer Datei sein, so dass diese per e-Mail auch verschickt werden kann. Grundsätzlich liegt diese im Netzwerk von Firma A und dort haben mehrere Personen Zugriff, aber es gibt auch externe Firma B und Firma C, die keinen Zugriff auf das Netzwerk von Firma A hat, so dass diese per e-Mail verschickt wird. Um nicht versehentlich Stände zu überschreiben, ist die Datei solange nicht im Netzwerk von Firma A verfügbar, bis es von Firma B oder Firma C wieder per e-mail zurückgeschickt wird.

Anforderung ist, dass sich verschiedene Benutzer sich einloggen können, und entsprechen dem, die 'Tabelle' mit vordefinierten Filtern sehen. In der Tabelle wird nur Text eingetragen, bzw. Verknüpfungen zu anderen Dateien.

Hat jemand einen guten Vorschlag mit welchem Programm das am besten Umsetzbar wäre? (Es sind nur Windows-Rechner die eingesetzt werden).

Gruß

 

[Old Knitterhemd]

Eine Datenbank per Mail verschicken?

Und diese in der Zwischenzeit lokal löschen?!


Bitte sucht euch einen Profi...

 

[michi.o]

Da würde mir auf Anhieb SQLite einfallen. Allerdings ist das nur eine Bibliothek. Die Benutzeroberfläche müsstest Du selber programmieren, z.B. in C#. Ich weiss aber nicht wie es da mit parallelem Zugriff aussieht.
Ansonsten MS Access.

 

[Harry2k]

joa access sollte das mittel der wahl sein, Vorteil ist auch das du die makros leichter anpassen kannst weil vba wissen scheint ja vorhanden zu sein

 

[Aslo]

Datenbank in einer VM installieren und diese hin- und herschicken

 

[Raijin]

Da würde mir auf Anhieb SQLite einfallen.
[..]
Ich weiss aber nicht wie es da mit parallelem Zugriff aussieht.

SQLite ist nicht auf Parallelität ausgelegt und kann daher zB auch nicht über das Netzwerk eingesetzt werden. Wobei.. können schon, aber wenn zwei Prozesse - sei es lokal oder über Netzwerk - gleichzeitig auf die SQLite-DB zugreifen, is Schicht im Schacht, weil die SQLite-DB eine stinknormale Datri ist, die nur von einem Prozess exklusiv genutzt werden kann. Der zweite Prozess sähe sich also einer gesperrten, weil bereits exklusiv geöffneten Datei gegenüber und hätte das Nachsehen.

So wie ich den Thread aber verstehe ist das auch gar nicht das Ziel. Die komplette Datenbank soll mit um die Welt reisen und wird dann vor Ort jeweils lokal bearbeitet. Der Sinn des ganzen erschließt sich mir nicht wirklich. Stattdessden würde ich ja eher einen zentralen SQL-Server aufsetzen, der zB nur via VPN erreichbar ist. Dann bekommt jeder Beteiligte einen VPN-Client inkl. Zertifikat sowie ein kleines Frontend für die SQL-DB zur Bearbeitung. So ist vor allem auch gewährleistet, dass die verschickte und geänderte Excel-Tabelle nicht unterwegs veschütt geht - zB wenn sie im Postfach von Kollege Meyer vergammelt, während der mit nem Infekt im Bett liegt.

Man kann das ganze zB auch mit einer Collaboration-Software wie zB Confluence machen. Das ist zugegebenermaßen etwas Overkill, aber Confluence kostet in der kleinsten Variante symbolische 10$ für 10 User. Da muss man vielleicht gar nicht mehr direkt mit einer Excel-Tabelle oder gar einer DB arbeiten, sondern kann den Inhalt direkt in die jeweilige Seite einbauen - inkl. Versionierung.

Oder aber man schraubt am Prozess. Das Konstrukt, dass x Personen bzw. Firmen jeweils nacheinander an derselben Datei arbeiten, erscheint doch recht .. .. seltsam. Evtl sollte es eher einen zentralen Bearbeiter geben, der von den jeweiligen anderen Inhalte einsammelt und dann in die gemeinsame Datenbasis einpflegt. Manchmal ist es eben nicht sinnvoll, umständliche Prozesse beizubehalten und dann die Software drumherum zu bauen, sondern manchmal ist es einfacher und gleichzeitig sinnvoller, den Prozess anzupacken. Das kann man von außen aber nur schwer einschätzen.

 

[lydec]

Danke für die vielen Antworten.

Eure Ideen mit Server+VPN wäre die sauberste Variante, und das ev besser die Prozesse angepasst werden statt ‚drumherum‘ zu bauen auch, und wurde auch anfangs vorgeschlagen. Leider ist aber beides aus verschiedenen Gründen nicht möglich, das hier nicht weiter diskutiert werden soll.

SQLite muss ich mir anschauen. Das keine parallele Bearbeitung möglich ist durch mehrere Benutzer wäre kein Problem, es geht nur um die Rechte was gesehen werden darf und was nicht.

Access ist mir auch zunächst in den Sinn gekommenen, jedoch braucht Access nicht überall installiert zu sein? Das ist ja nicht im Standard-Office enthalten.

Eine VM herumschicken wäre etwas zu viel des Guten, aber ja, theoretisch auch machbar.

Schaue mir dann mal SQLite an bzw bzgl Access ausführen..

Edit: Vielleicht ist Datenbank auch zu viel, es ginge prinzipiell um eine Datei, in der Protokoll geführt wird, mit Verknüpfung auf andere Dateien, sichergestellt wird dass die Datei nach x Minuten nichtbenutzung freigeben wird und eben per Login die sichtbaren Felder gefiltert werden.

 

[Raijin]

Edit: Vielleicht ist Datenbank auch zu viel, es ginge prinzipiell um eine Datei, in der Protokoll geführt wird, mit Verknüpfung auf andere Dateien, sichergestellt wird dass die Datei nach x Minuten nichtbenutzung freigeben wird und eben per Login die sichtbaren Felder gefiltert werden.

Ich mag schwer von Begriff sein, aber ich kann dir nicht folgen.

1. Eine Excel-Tabelle wird zur Zeit von einem zum anderen weitergereicht
2. In dieser Tabelle wird irgendwas protokolliert
3. In dieser Tabelle sind zudem Links auf Dateien
4. Diese Dateien sollen nach einem Timeout freigegeben werden
5. Es gibt eine Art Login, der einzelne Bereiche freigibt

Habe ich das so richtig verstanden? Wenn ja, wie sollten Dateilinks denn gültig bleiben, wenn die Tabelle rumgereicht wird? Es ist ja eher unwahrscheinlich, dass alle Beteiligten dieselbe Ordnerstruktur haben. Und wenn diese Dateien freigegeben werden sollen (4) wer/wie/was öffnet bzw blockiert die Dateien denn? Wenn eine andere Anwendung eine Datei exklusiv öffnet, kann man von einer anderen Anwendung aus nicht so ohne weiteres "sicherstellen", dass diese Datei nach einer Zeitspanne t wieder freigegeben wird. Wenn man das forcieren würde, stehen die Chancen gut, dass die andere Anwendung crasht.

Nach wie vor vermute ich, dass der Prozess unnötig kompliziert ist. Das wirkt wie Zettel-Rumgereiche mit Excel statt mit Papier.

Irgendwie riecht das förmlich nach einem XY-Problem.

Es ist denkbar schwierig, Lösungen anzubieten, wenn man das Problem gar nicht versteht. Dass "verschiedene Gründe" gegen eine Server-Lösung sprechen, ist auch wenig hilfreich. :-/

 

[lydec]

...
1. Eine Excel-Tabelle wird zur Zeit von einem zum anderen weitergereicht

Ja, das stimmt.

2. In dieser Tabelle wird irgendwas protokolliert

Ja

3. In dieser Tabelle sind zudem Links auf Dateien

Ja es können zu Einträgen Links geben.

4. Diese Dateien sollen nach einem Timeout freigegeben werden

Nein, dass ist nicht der Fall. Das Freigeben der Datei bezog sich nur auf die Exceldatei in dem alles protokolliert wird.

5. Es gibt eine Art Login, der einzelne Bereiche freigibt

Ja.

Habe ich das so richtig verstanden? Wenn ja, wie sollten Dateilinks denn gültig bleiben, wenn die Tabelle rumgereicht wird? Es ist ja eher unwahrscheinlich, dass alle Beteiligten dieselbe Ordnerstruktur haben.

Das ist natürlich richtig, aber das ist nicht tragisch, da dies nur für die Firma A oder Firma B intern Zugriff notwendig ist.

Und wenn diese Dateien freigegeben werden sollen (4) wer/wie/was öffnet bzw blockiert die Dateien denn? Wenn eine andere Anwendung eine Datei exklusiv öffnet, kann man von einer anderen Anwendung aus nicht so ohne weiteres "sicherstellen", dass diese Datei nach einer Zeitspanne t wieder freigegeben wird. Wenn man das forcieren würde, stehen die Chancen gut, dass die andere Anwendung crasht.

Das ist nicht der Fall, da nur die Protokoll-Datei geschlossen wird. Nicht irgendwelche externe Daten.

Es ist denkbar schwierig, Lösungen anzubieten, wenn man das Problem gar nicht versteht. Dass "verschiedene Gründe" gegen eine Server-Lösung sprechen, ist auch wenig hilfreich. :-/

Sorry wenn ich mich nicht ganz korrekt für alles ausgedrückt habe. Deswegen sind die Rückfragen gut. Bzgl der IT muss ich nochmal nachfragen ob es sich mittlerweile ev geändert hat. Als es anfing hieß es, sie möchten keinen von außen erreichbaren Dienst bereitstellen.

 

[Raijin]

Bzgl der IT muss ich nochmal nachfragen ob es sich mittlerweile ev geändert hat. Als es anfing hieß es, sie möchten keinen von außen erreichbaren Dienst bereitstellen.

Letztendlich ist das der springende Punkt. Die IT ist dafür verantwortlich, entsprechende Lösungen anzubieten. Wenn Mitarbeiter um die IT herum arbeiten, entstehen teilweise noch deutlich größere Sicherheitsrisiken als wenn die IT zB ein VPN bereitstellt, das explizit für solche Zwecke geeignet ist. Was wäre zB wenn in dieser Datei bzw. der Datenbank Informationen stehen, die das Unternehmen eigentlich gar nicht verlassen dürfen? Ein banaler Login in einer Excel-Datei kann schließlich auch ausgehebelt werden und dann sieht Firma A

Für mich sieht es so aus, dass eine serverbasierte Anwendung genau das Richtige wäre. Wie gesagt, ggfs abgesichert durch eine VPN-Verbindung zwischen den Standorten/Firmen. Da muss aber natürlich die IT mitspielen. Im worst case muss die IT dann aber eine Anweisung aus der Teppich-Etage bekommen, wenn diese .. .. Protokolle für eure Arbeit essentiell sind.

Ansonsten kannst du SQLite auch in Excel bzw. VBA anbinden, vorausgesetzt der SQLite ODBC-Treiber ist installiert:

Dim con As Object

Set con = CreateObject("ADODB.Connection")

con.Open "DRIVER=SQLite3 ODBC Driver;Database=C:\Pfad\zur\Database.db;"

Dann muss jedoch stets zur xls(x)-Datei auch immer die genutzte db-Datei verschickt werden, das ist klar.


Ob eine Datenbank überhaupt der richtige Weg ist, sei mal dahingestellt. Das lässt sich ohne Kenntnis der darin gespeicherten Daten nicht einschätzen. "Protokoll" impliziert eigentlich keine sonderlich komplexe Datenstruktur und daher weiß ich nicht so recht ob man hier nicht mit Kanonen auf Spatzen zu schießen versucht.

 

[lydec]

Ob eine Datenbank überhaupt der richtige Weg ist, sei mal dahingestellt. Das lässt sich ohne Kenntnis der darin gespeicherten Daten nicht einschätzen. "Protokoll" impliziert eigentlich keine sonderlich komplexe Datenstruktur und daher weiß ich nicht so recht ob man hier nicht mit Kanonen auf Spatzen zu schießen versucht.

Da stimme ich dir zu, das die Datenbank an sich zu viel ist, jedoch sah ich dort die bessere Möglichkeit um die Benutzer zu trennen und das automatische ausloggen bei nichtbenutzung umzusetzen. Wenn als Server-Lösung wäre das zeitgleiche bearbeiten auch direkt mit gelöst.

Zu dem XY Problem: es geht etwas in die Richtung, da prinzipiell das grundsätzliche Problem darin besteht, dass durch das automatische beenden von der Excel Datei, der ganze Prozess beendet wird und damit jede ev. parallel geöffnete Excel-Datei mit beendet wird. Muss dort auch noch mal schauen wo dort ev der Hund begraben ist.

 

[Raijin]

Wenn sowieso keine parallele Bearbeitung vorgesehen ist, erschließt sich mir die Anforderung des automatischen Logouts aber irgendwie nicht. Es ist klar, dass man nach getaner Arbeit das Dokument speichert und schließt.

Sub AktiveMappeSchließen()
ActiveWorkbook.Close (True)
End Sub

Damit wird die aktive Arbeitsmappe in Excel geschlossen und alle Änderungen gespeichert (true).

Es klingt aber immer mehr danach, dass Excel hier zweckentfremdet wird. Excel ist ein Tabellenkalkulationsprogramm, das sich durch Makros zwar an vielen Stellen automatisieren lässt, aber das war's dann auch. Der VBA-Editor eignet sich nicht wirklich dazu, aus einem Excel-Dokument quasi eine eigene Software mit Quellcode zu bauen. Da wäre dann wie oben schon erwähnt wurde Access besser geeignet, weil man dort gleich eine adäquate Datenbasis mitbekommt und mit eigenen Formularen, etc. schon ziemlich viel anstellen kann. Mit der Access Runtime auf den Zielsystemen ist dann auch keine eigenständige Access-Installation notwendig.

Nichtsdestotrotz ist es umständlich, das Ding reihum zu schicken. Man könnte die Daten auch in einer Cloud ablegen und dort dann jeweils ein-/aus-checken.

 

[lydec]

Wenn sowieso keine parallele Bearbeitung vorgesehen ist, erschließt sich mir die Anforderung des automatischen Logouts aber irgendwie nicht.

Das war bisher nicht in Gespräch da nur Excel genutzt wurde, würde bei einer Web-Anwendung aber mit umgesetzt werden.

Es ist klar, dass man nach getaner Arbeit das Dokument speichert und schließt.

das ist der Punkt, so sollte es sein, jedoch gibt es immer wieder ein paar (auch mit mehrmaligem hinweisen) dass es nicht geschlossen wird und dann für andere mehrere Stunden blockiert wird. Deswegen wurde das automatische schließen eingeführt.

Und ja Excel wird hier weiter ausgebaut als dass es gedacht ist. Mit Access Runtime muss ich mit den ITs sprechen ob das mit verteilt werden könnte.