Online / Offline Datenbanken

Wenn ihr es einfach und im Windowsumfeld haben möchtet, dann solltet ihr euch mit den Access-Geschichten doch einmal intensiver auseinandersetzen.
Für einfache Anwendungen und kleinere Datenhaltungen in einem Windowsbetriebsumfeld deckt das so ziemlich jeden notwendigen Bedarf ab ohne zu komplex zu werden. Es gehen sogar recht komplexe Dinge.

Alles andere wird dann schnell "professionell". Die Einarbeitungszeit in ACCESS halte ich für einen versierten IT-Menschen für gering.

Deinen Sicherheitsaspekt in Bezug auf Cloud-Anwendungen kann ich verstehen. Wenn alle Anwender in einem Intranet sind und nicht von extern zugreifen sollen/müssen würde ich an derartige Lösungen gar nicht erst denken.

Die Frage bei der Access-Awendung ist natürlich noch die Verteilung bzw. Zentralisierung der Datenhaltung. Ich schätze aber mal die Excel-Dateien die jetzt verwendet werden, liegen aktuell auf irgendeinem zentralen Server bei euch?

Gruß

 

das problem hatten wir auch mit exel, die exel liste war am schluss gute 33mb groß und hat paar minuten zum laden gebraucht.

wurde jetzt umgestellt auf Access, und jetzt ists viel schneller, einfacher und können nicht so große fehler passieren.

wobei natürlich access etwas aufwendiger zum "programmieren" ist, wenn man das so sagen kann.

 

Wir nutzen auch Acces bei uns um z.B. Sachen ausm Lager auszubuchen, Eisenbahnwaggons zu organisieren um Proben fürs Labor anzumelden etc.

Der großteil geht zwar übers SAP aber für so Betriebsinterne Sachen find ich das klasse. Hab halt leider selbst keine Ahnung wie das alles programmiert wird, aber wir haben so ne "Acces-Sau" auf ner andren Schicht der macht das alles

 

ich denke wenn man sich gut mit exel auskennt, sollte es nicht allzuschwer sein sich in access einzuarbeiten.
gibts doch bestimmt irgendwelche bücher oder foren die das einem näherbringen.

wenn ihr jedoch noch keine lizenz für access habt dann könnt halt bisschen teuer werden in der anschaffung, office professional kostet nen paar euro.

 

Die Kosten müssen immer relativ zum Zeit- und Informationsgewinn gesehen werden, der sich mit Einführung derartiger Lösungen ergibt. Ich möchte nicht wissen wie viel Zeit und Information dabei verloren, wenn man diese Excel-Stückwerke immer wieder neu aufsetzen muss, weil sie jemand unwissentlich zerschossen hat. Für eine strukturierte Ablage sind Datenbanksysteme einfach die elegantere und effektiviere Art zu arbeiten.

 

Access mag zwar knapp als "Datenbank" durchgehen - wurde jedoch nicht für den Multiuser-Einsatz konzipiert. Wenn mehrere Leute gleichzeitig darauf zugreiffen, kann/wird es die genau gleichen Probleme geben sofern eine Access-DB dahinter hängt. Lediglich die Sache mit dem zerschossenen Format etc. gibt es hier nicht.

Man könnte die Daten allerdings auch z.B. in eine SQL-Server Datenbank ablegen, und relativ einfach über Access anbinden. Sozusagen wäre Access dann "nur" noch ein VBA-Frontend, dann könnten auch mehrere Leute gleichzeitig daran arbeiten. Das Problem ist hier halt, dass man sowas (SQL-DB) bei der IT-Abteilung beantragen und begründen muss - daher wird halt gerne mit den Produkten der Office-Palette was selbst zusammengebastelt. Eine wirklich gute Lösung für deinen Fall wird es so auf keinen Fall geben.

Ein Kollege hat sich sowas in der Art mit EditGrid gebaut, gemäss ihm scheint das hervorragend zu funktionieren.

 

Wenn man die Anwendung von den Tabellen trennt, macht Access auch im Multi-User-Betrieb sehr selten Probleme Es reicht übrigens eine Access-Lizenz aus (sofern nur ein User Änderungen daran vornimmt). Zum Ausführen einer Access-Datenbank reicht normales Office bzw. die Access-Runtime aus, soweit ich weiß.

 

Ändert aber nicht an der Tatsache, dass Access grundsätzlich nicht dafür ausgelegt ist. Das ist lediglich ein Workarround um das Problem einzudämmen.

Wenn jemand die Skills hat - sowas professionell in Access zu realisieren, dann wird er das auch mit vernünftigen Technologien tun können

 

Im Normalfall macht es jedoch in einem Windows dominierten Umfeld mehr Sinn bei einfachen Lösungen zu bleiben. Die Einführungen neuerer komplexer Technologien zieht immer einen am Anfang des Projektes unterschätzen Rattenschwanz an Folgekosten (Serverkosten, Lizenzskosten, Wartungskosten, Implementationskosten etc.) mit sich. Dann heißt es immer nur kurz und knapp ... "zu teuer machen sie Excel weiter".

 

Da geb ich dir natürlich teilweise recht - jedoch ist das Risiko und die Kosten bei solchen "Einzellösungen" auch nicht zu unterschätzen. Ich kenne Firmen die teilweise relativ geschäftskritische Anwendungen so am laufen haben. Angefangen hat alles mal mit einem simplen Worksheet und ein paar Formeln - mittlerweilen sind es tausende Zeilen VBA welche weder dokumentiert noch kommentiert sind - gewartet von einer einzelnen Person. Wenn derjenige unerwartet ausfällt - dann gehts rund - und wird richtig teuer

Das Problem ist ja nicht Excel/VBA an sich - sondern die Art und Weise wie leider oft damit gearbeitet wird. Da fühlt sich jemand plötzlich als Applikationsentwickler obwohl er eigentlich keine Ahnung von sowas hat. Und genau das finde ich extrem kritisch..

 

So etwas haben wir bei uns in einer Konzernabteilung auch ... die Access-Anwendung wird als automatisches Monitoringtool missbraucht und muss von meinem SAP Systembereich aus täglich Dateien mit bis zu 500MB Klartext verarbeiten (manchmal locker 1.000.000+ Datensätze pro Tag ). Ich glaube der gute Mann schläft keine Nacht ruhig und er hat selber schon eine (vernünftige) Folgeanwendung beantragt.
Aber es ist wie du schon sagst in dem Bereich eine sehr heikle One-Man-Show.

Als Gegenbeispiel haben wir auch eine sehr komplexes Multi-User Access-Anwendung für das Controlling mit automatisierten Schnittstellen zu weiteren verteilten Anwendungen bei uns am Laufen, die hervorragend und äußerst stabil funktioniert. Das Tool zeigt auf jedenfall das es mit Access möglich ist, auch sehr komplexe Sachen sicher und stabil über Jahre am Laufen zu halten.

Im Zweifelsfalle gibt es am Markt sehr viele und auch "günstige" VBA-erfahrene Entwickler.