Tool gesucht - Ersatz für Access DB Frontend
Hallo zusammen
Historisch gewachsen haben wir bei uns verschiedene Datenbanken unter MySQL/MariaDB und auch Access.
Zum Erfassen und Auswerten von Daten wird dort Access als Benutzer-Frontend verwendet. Die Anbindung der jeweiligen Datenbank läuft in der Regel via ODBC. In den Frontends gibt es dann eben diverse Erfassungsformulare, Abfragen und Berichte und - mal mehr, mal weniger - Makros.
Jetzt würde ich da gerne mal kurz- bis mittelfristig von Access als Frontend weg und irgendwas anderes einsetzen. Daher die Frage, ob da jemand was geeignetes kennt?
Erst mal bin ich da für alles offen so lange es dem bisherigen Funktionsumfang nahe kommt.
Nice to have wäre, wenn Anwender- und Entwicklungswerkzeug getrennt wären. Vielleicht gibt es auch irgendeine Webanwendung bei der ich hinten ein Access-Frontend rein kippe und vorne kommt ein Webfrontend für den User raus.
Ich bin schon seit einiger Zeit am googeln, aber irgendwie habe ich noch nichts passendes gefunden. Vielleicht habe ich mich auch zu blöd dran gestellt
Soll ich vielleicht einfach zu LibreOffice Base gehen? Oder sagt ihr "Bleib bei Access und Access-Runtime."
Schreibt einfach mal alles was euch dazu einfällt...
Manuel
Historisch gewachsen haben wir bei uns verschiedene Datenbanken unter MySQL/MariaDB und auch Access.
Zum Erfassen und Auswerten von Daten wird dort Access als Benutzer-Frontend verwendet. Die Anbindung der jeweiligen Datenbank läuft in der Regel via ODBC. In den Frontends gibt es dann eben diverse Erfassungsformulare, Abfragen und Berichte und - mal mehr, mal weniger - Makros.
Jetzt würde ich da gerne mal kurz- bis mittelfristig von Access als Frontend weg und irgendwas anderes einsetzen. Daher die Frage, ob da jemand was geeignetes kennt?
Erst mal bin ich da für alles offen so lange es dem bisherigen Funktionsumfang nahe kommt.
- Es muss mit den Datenbanken sprechen können. Die Access-DBn müssten dann halt endlich mal nach MariaDB migriert werden.
- Ich brauche frei definierbare Abfragen und Berichte.
- Makros wären auch gut, weil man ja immer mal Daten irgendwie miteinander verrechnen muss, in ein Format bringen oder oder oder. Hier und da werden auch Programmaufrufe aus dem Frontend heraus gemacht oder Mails verschickt und dabei Daten aus einem Formular übergeben.
Nice to have wäre, wenn Anwender- und Entwicklungswerkzeug getrennt wären. Vielleicht gibt es auch irgendeine Webanwendung bei der ich hinten ein Access-Frontend rein kippe und vorne kommt ein Webfrontend für den User raus.
Ich bin schon seit einiger Zeit am googeln, aber irgendwie habe ich noch nichts passendes gefunden. Vielleicht habe ich mich auch zu blöd dran gestellt
Soll ich vielleicht einfach zu LibreOffice Base gehen? Oder sagt ihr "Bleib bei Access und Access-Runtime."
Schreibt einfach mal alles was euch dazu einfällt...
Manuel
Please also mark the comments that contributed to the solution of the article
Content-ID: 668334
Url: https://administrator.de/contentid/668334
Printed on: December 10, 2024 at 14:12 o'clock
8 Comments
Latest comment
Moin,
lasst euch (sofern kein fähiger Entwickler vorhanden ist) das von einer Firma oder einem Freelancer entwickeln.
Wenn ihr es "mobil" braucht, als Web Anwendung, wenn ihr es nur intern braucht, als normale Desktop Anwendung.
Mit Access würde ich ehrlich gesagt nicht mehr weiter arbeiten wollen.
Abfragen und Berichte würden sich über Combit List&Label lösen lassen (müsste gekauft und implementiert werden). Alternative wäre, dass die neue Anwendung direkt PDFs erstellt. Was vor allem bei ausführlichen Berichten deutlich teurer (= Arbeitszeit des Entwicklers) wird.
Wäre halt auch nice zu wissen, wie groß der Umfang deiner Access Datenbank ist, wieviele Tabellen, relationen, was genau da drin steht ...
lasst euch (sofern kein fähiger Entwickler vorhanden ist) das von einer Firma oder einem Freelancer entwickeln.
Wenn ihr es "mobil" braucht, als Web Anwendung, wenn ihr es nur intern braucht, als normale Desktop Anwendung.
Mit Access würde ich ehrlich gesagt nicht mehr weiter arbeiten wollen.
Abfragen und Berichte würden sich über Combit List&Label lösen lassen (müsste gekauft und implementiert werden). Alternative wäre, dass die neue Anwendung direkt PDFs erstellt. Was vor allem bei ausführlichen Berichten deutlich teurer (= Arbeitszeit des Entwicklers) wird.
Wäre halt auch nice zu wissen, wie groß der Umfang deiner Access Datenbank ist, wieviele Tabellen, relationen, was genau da drin steht ...
Ist halt jetzt schon so ein bissi ERP.
Wenn ihr da selber immer dran werkeln wollt, würde ich persönlich den Umstieg zu Base empfehlen.
Glom hatte ich früher mal gesehen. Da gabs dann auch Unterschiede zu User und Developer. Aber irgendwie geht die Homepage nicht mehr. Keine Ahnung, obs das noch gibt.
Die Frage ist aber: wieso weg von Access?
Wenn ihr da selber immer dran werkeln wollt, würde ich persönlich den Umstieg zu Base empfehlen.
Glom hatte ich früher mal gesehen. Da gabs dann auch Unterschiede zu User und Developer. Aber irgendwie geht die Homepage nicht mehr. Keine Ahnung, obs das noch gibt.
Die Frage ist aber: wieso weg von Access?
Hallo,
als Access-Programmierer kann ich nur sagen, Du wirst auf dem Markt nicht viele Alternativen finden, die Dir eine auch nur annähernde Funktionalität liefern.
Access als Backend - keine gute Idee, sollte man schnell von wegkommen, sofern es um Unternehmensdaten geht (wie hier).
Access als Frontend - bietet Dir so ziemlich alles, was man für die Arbeit mit Datenbanken braucht, Formulare, Reporte, Programmierbarkeit mit VBA (Makros sind in Access etwas Anderes und sollte man besser nicht einsetzen).
Damit lassen sich sehr gute und sehr komfortable Anwendungen erstellen, die als Backend auf z.B. SQL Server aufsetzen (was meine erste Wahl wäre), Access kann aber auch (selbst übergreifend) auf nahezu alle DB-Server zugreifen und noch etliche andere Datenquellen - selbst simultan, da es eben eine eigene Abfragesprache (SQL) hat, die zwar karg ist, aber für übergreifende Datenabfragen ausreichend. Und im Fall eines DB-Servers als Backend hast Du den vollen maximalen Komfort einer professionellen Datenbank. Das schließt selbstverständlich auch MariaDB oder MySQL und viele andere ein. SQL Server hat halt demgegenüber den Vorteil, daß Du auch bei Bedarf leicht in die Cloud (Azure) migrieren kannst, wo nur soviele Kosten entstehen, wie Du an Leistung haben möchtest. Auf dem anderen Ende der Skala kannst Du auch einen SQL Server Express verwenden, den es gratis gibt.
Andere Alternativen wären halt Webanwendungen auf klassische Weise wie etwa mit PHP/Javascript/CSS/HTML geschrieben (ja, das gehört alles zusammen und man muß alles dazu können).
Dann gibt es .NET-Programmiersprachen wie C# oder VB.NET, mit denen man ebenfalls noch viel mehr machen kann, als in Access jemals möglich sein wird, aber auch hier braucht es natürlich die entsprechenden Programmierungsspezialisten. Coding und Design läßt sich hier mit z.B. WPF trennen, dennoch - es braucht erfahrene Programmierer, man kann eine Anwendung nicht "zusammenklicken".
MS bietet dann in Azure Lösungen wie PowerApps, PowerAutomate und PowerBI an, die versprechen, "No-Code"-Lösungen zu sein - sie sind es aber nicht, sie sind auch nicht annähernd so performant und das Coding in etwa PowerApps benötigt schon sehr viel Verständnis für DAX (wieder eine neue Abfragesprache - und SQL benötigt man trotzdem weiterhin). Also: Auch hier brauchst Du fähige Leute, bevor Du ein brauchbares Ergebnis bekommst.
Verabschiede Dich dabei von dem Gedanken, daß Du irgendeine der Access-Anwendungen "mal eben" in eine der o.g. oder anderen nicht genannten Technologien umwandeln kannst. Das gilt ebenso umgekehrt oder zwischen den genannten Technologien - jede hat ihre Eigenarten und jede muß eben auf ihre Weise gestaltet werden und kann nicht "umgewandelt" werden.
Es ist also weit einfacher, wenn Du schon bestehende Access-Anwendungen hast, diese weiterzuentwickeln oder zu verbessern, Potential ist bei derartigen "gewachsenen" Anwendungen meist sehr viel. Und das ist dann meist einfacher, als alles neu zu schreiben. Es kommt natürlich immer auf den Umfang an, da Du aber von "wenigen Tabellen" sprichst, würde ich den Aufwand hier eher geringer sehen.
Nichtsdestotrotz sollte man sich auch überlegen, ob man bei nur kleinen, verstreuten und schwer zentral verwaltbaren Anwendungen überlegen, ob man nicht alle in einer Datenbank (also selbstverständlich einem DB-Server) konsolidiert und dann eine Anwendung mit verschiedenen Modulen daraus baut, so daß jeder User seinen Part wiederfindet, gesteuert über Rechte. Mit kleinen Anwendungen ist das oft noch machbar, wenn sie mal ein paar hundert Tabellen umfassen, wird ein Riesenprojekt daraus.
Wenn Du Dir über Lizenzkosten von Office Gedanken machst: Die Runtime gibt es noch immer, auch in einer 365-Variante und immer noch kostenlos:
https://support.microsoft.com/de-de/office/herunterladen-und-installiere ...
Es ist allerdings durchaus überlegenswert, den Pfad der festen Lizenzen zu verlassen und auf O365 zu wechseln, so daß man immer über die entsprechend neuesten Versionen verfügt. In Access hat sich in den letzten Jahren wiederum nicht so viel getan, daß durch einen Update ältere Programme nicht mehr laufen würden. Die Grenze liegt allerdings schon so bei A2010, also was ab A2013 lauffähig ist, sollte i.d.R. auch unter allen neueren laufen. MDBs natürlich nicht mehr auch keine ADPs.
Es gab mal eine Web-Version von Access, hatte allerdings den Nachteil, daß man ausschließlich mit Makros (also Null VBA) programmieren mußte und daß man zum Hochladen einen Sharepoint-Server haben mußte. Die konnte man tatsächlich "hinten reinkippen" und vorne kam eine Webanwendung raus, die wie Access aussah. MS hat das aber mittlerweile wieder eingestellt.
Ich würde, wenn Web unbedingt notwendig ist, eher einen Terminalserver aufsetzen, auf den die Frontends installiert werden. Das hat den Vorteil, daß man per RemoteDesktop bzw. RemoteApp auf dem Server arbeitet (wo dann alle garantiert mit der gleichen Access-Version, auch Runtime, wenn nötig, arbeiten). Das bedeutet, die Daten verlassen den Server nicht und landen nur auf dem Client, wenn sie vom Remote Desktop auf den Client absichtlich kopiert werden. Man hat die volle Performance, weil nichts über das Netz gezogen wird und man kann es von überall her verwenden, sogar auf Tablets und Phones, sofern die Remote-Desktop-App von MS installiert wird (gibt auch andere Hersteller natürlich).
Hat man SQL Server als Backend, kann man sogar gratis dessen Report-Server verwenden, der auch nochmal einiges mehr drauf hat als Access-Reports und nebenbei einen Webserver beinhaltet, mit dem Reports bequem abgerufen werden können - ganz ohne Access. Dennoch kann man dann weiterhin Access-Frontends verwenden.
Fazit: Wenn Du umsteigen willst, kostet es und benötigt Spezialisten, wenn Du bei Access bleiben willst und bessere Ergebnisse als Hobbyprogrammierer-Niveau benötigt werden, kommst Du auch hier um entsprechende Spezialisten nicht herum. Die gute Nachricht: Sich in Access und VBA-Programmierung selbst einzuarbeiten, um bessere Ergebnisse zu bekommen, ist bei weitem einfacher als in allen anderen Technologien, die aktuell "hip" sind oder als solche angepriesen werden. Das ist die einzige "Sparfuchs"-Lösung, für alles Andere braucht man eben Spezialisten. Wenn es genug Arbeit gibt, könntest Du auch einfach darüber nachdenken, jemanden einzustellen. Das ist sicherlich preiswerter, als externe Programmierer hinzuzuziehen.
Gruß
Christian
als Access-Programmierer kann ich nur sagen, Du wirst auf dem Markt nicht viele Alternativen finden, die Dir eine auch nur annähernde Funktionalität liefern.
Access als Backend - keine gute Idee, sollte man schnell von wegkommen, sofern es um Unternehmensdaten geht (wie hier).
Access als Frontend - bietet Dir so ziemlich alles, was man für die Arbeit mit Datenbanken braucht, Formulare, Reporte, Programmierbarkeit mit VBA (Makros sind in Access etwas Anderes und sollte man besser nicht einsetzen).
Damit lassen sich sehr gute und sehr komfortable Anwendungen erstellen, die als Backend auf z.B. SQL Server aufsetzen (was meine erste Wahl wäre), Access kann aber auch (selbst übergreifend) auf nahezu alle DB-Server zugreifen und noch etliche andere Datenquellen - selbst simultan, da es eben eine eigene Abfragesprache (SQL) hat, die zwar karg ist, aber für übergreifende Datenabfragen ausreichend. Und im Fall eines DB-Servers als Backend hast Du den vollen maximalen Komfort einer professionellen Datenbank. Das schließt selbstverständlich auch MariaDB oder MySQL und viele andere ein. SQL Server hat halt demgegenüber den Vorteil, daß Du auch bei Bedarf leicht in die Cloud (Azure) migrieren kannst, wo nur soviele Kosten entstehen, wie Du an Leistung haben möchtest. Auf dem anderen Ende der Skala kannst Du auch einen SQL Server Express verwenden, den es gratis gibt.
Andere Alternativen wären halt Webanwendungen auf klassische Weise wie etwa mit PHP/Javascript/CSS/HTML geschrieben (ja, das gehört alles zusammen und man muß alles dazu können).
Dann gibt es .NET-Programmiersprachen wie C# oder VB.NET, mit denen man ebenfalls noch viel mehr machen kann, als in Access jemals möglich sein wird, aber auch hier braucht es natürlich die entsprechenden Programmierungsspezialisten. Coding und Design läßt sich hier mit z.B. WPF trennen, dennoch - es braucht erfahrene Programmierer, man kann eine Anwendung nicht "zusammenklicken".
MS bietet dann in Azure Lösungen wie PowerApps, PowerAutomate und PowerBI an, die versprechen, "No-Code"-Lösungen zu sein - sie sind es aber nicht, sie sind auch nicht annähernd so performant und das Coding in etwa PowerApps benötigt schon sehr viel Verständnis für DAX (wieder eine neue Abfragesprache - und SQL benötigt man trotzdem weiterhin). Also: Auch hier brauchst Du fähige Leute, bevor Du ein brauchbares Ergebnis bekommst.
Verabschiede Dich dabei von dem Gedanken, daß Du irgendeine der Access-Anwendungen "mal eben" in eine der o.g. oder anderen nicht genannten Technologien umwandeln kannst. Das gilt ebenso umgekehrt oder zwischen den genannten Technologien - jede hat ihre Eigenarten und jede muß eben auf ihre Weise gestaltet werden und kann nicht "umgewandelt" werden.
Es ist also weit einfacher, wenn Du schon bestehende Access-Anwendungen hast, diese weiterzuentwickeln oder zu verbessern, Potential ist bei derartigen "gewachsenen" Anwendungen meist sehr viel. Und das ist dann meist einfacher, als alles neu zu schreiben. Es kommt natürlich immer auf den Umfang an, da Du aber von "wenigen Tabellen" sprichst, würde ich den Aufwand hier eher geringer sehen.
Nichtsdestotrotz sollte man sich auch überlegen, ob man bei nur kleinen, verstreuten und schwer zentral verwaltbaren Anwendungen überlegen, ob man nicht alle in einer Datenbank (also selbstverständlich einem DB-Server) konsolidiert und dann eine Anwendung mit verschiedenen Modulen daraus baut, so daß jeder User seinen Part wiederfindet, gesteuert über Rechte. Mit kleinen Anwendungen ist das oft noch machbar, wenn sie mal ein paar hundert Tabellen umfassen, wird ein Riesenprojekt daraus.
Wenn Du Dir über Lizenzkosten von Office Gedanken machst: Die Runtime gibt es noch immer, auch in einer 365-Variante und immer noch kostenlos:
https://support.microsoft.com/de-de/office/herunterladen-und-installiere ...
Es ist allerdings durchaus überlegenswert, den Pfad der festen Lizenzen zu verlassen und auf O365 zu wechseln, so daß man immer über die entsprechend neuesten Versionen verfügt. In Access hat sich in den letzten Jahren wiederum nicht so viel getan, daß durch einen Update ältere Programme nicht mehr laufen würden. Die Grenze liegt allerdings schon so bei A2010, also was ab A2013 lauffähig ist, sollte i.d.R. auch unter allen neueren laufen. MDBs natürlich nicht mehr auch keine ADPs.
Es gab mal eine Web-Version von Access, hatte allerdings den Nachteil, daß man ausschließlich mit Makros (also Null VBA) programmieren mußte und daß man zum Hochladen einen Sharepoint-Server haben mußte. Die konnte man tatsächlich "hinten reinkippen" und vorne kam eine Webanwendung raus, die wie Access aussah. MS hat das aber mittlerweile wieder eingestellt.
Ich würde, wenn Web unbedingt notwendig ist, eher einen Terminalserver aufsetzen, auf den die Frontends installiert werden. Das hat den Vorteil, daß man per RemoteDesktop bzw. RemoteApp auf dem Server arbeitet (wo dann alle garantiert mit der gleichen Access-Version, auch Runtime, wenn nötig, arbeiten). Das bedeutet, die Daten verlassen den Server nicht und landen nur auf dem Client, wenn sie vom Remote Desktop auf den Client absichtlich kopiert werden. Man hat die volle Performance, weil nichts über das Netz gezogen wird und man kann es von überall her verwenden, sogar auf Tablets und Phones, sofern die Remote-Desktop-App von MS installiert wird (gibt auch andere Hersteller natürlich).
Hat man SQL Server als Backend, kann man sogar gratis dessen Report-Server verwenden, der auch nochmal einiges mehr drauf hat als Access-Reports und nebenbei einen Webserver beinhaltet, mit dem Reports bequem abgerufen werden können - ganz ohne Access. Dennoch kann man dann weiterhin Access-Frontends verwenden.
Fazit: Wenn Du umsteigen willst, kostet es und benötigt Spezialisten, wenn Du bei Access bleiben willst und bessere Ergebnisse als Hobbyprogrammierer-Niveau benötigt werden, kommst Du auch hier um entsprechende Spezialisten nicht herum. Die gute Nachricht: Sich in Access und VBA-Programmierung selbst einzuarbeiten, um bessere Ergebnisse zu bekommen, ist bei weitem einfacher als in allen anderen Technologien, die aktuell "hip" sind oder als solche angepriesen werden. Das ist die einzige "Sparfuchs"-Lösung, für alles Andere braucht man eben Spezialisten. Wenn es genug Arbeit gibt, könntest Du auch einfach darüber nachdenken, jemanden einzustellen. Das ist sicherlich preiswerter, als externe Programmierer hinzuzuziehen.
Gruß
Christian
Moin,
+1 für "stay at home". Nicht nur, dass ich keinen adäquaten Ersatz kenne, Du hast auch Teammitglieder, die vieles neu lernen müssten, was sie jetzt beherrschen.
Vorteil von Access in so einer Konstellation m.M.n.: fitte Poweruser können da selbst ran und sich den Alltag so erleichtern, wie sie es brauchen.
Jede andere Individualprogrammierung benötigt für jede Anpassung, wie Du richtig sagst, Experten; das kostet Zeit und Geld.
Access hat einer große Userbase, viel Dokumentation im Netz, viele Beispiele, ist optisch bedienbar und kann bei Bedarf auch durchaus tiefergehend erweitert werden.
Nicht nutzen würde ich es als alleiniges Datenbanktool (Backend ...), da wäre es mir nicht robust genug.
Gruß
DivideByZero
+1 für "stay at home". Nicht nur, dass ich keinen adäquaten Ersatz kenne, Du hast auch Teammitglieder, die vieles neu lernen müssten, was sie jetzt beherrschen.
Vorteil von Access in so einer Konstellation m.M.n.: fitte Poweruser können da selbst ran und sich den Alltag so erleichtern, wie sie es brauchen.
Jede andere Individualprogrammierung benötigt für jede Anpassung, wie Du richtig sagst, Experten; das kostet Zeit und Geld.
Access hat einer große Userbase, viel Dokumentation im Netz, viele Beispiele, ist optisch bedienbar und kann bei Bedarf auch durchaus tiefergehend erweitert werden.
Nicht nutzen würde ich es als alleiniges Datenbanktool (Backend ...), da wäre es mir nicht robust genug.
Gruß
DivideByZero
Ich finde da ja Power BI ganz spannend.
Aber! das kostet auch und du musst dich wieder komplett reinfuchsen. Wenn Access bereits vorhanden ist, würde ich da auch bleiben wollen. Es sind da ja schon Leute da, die damit umgehen können.
Kostentechnisch die Runtime und gut.
Datenbanktechnisch bin ich selber weg. Das müssen andere beantworten, ob MariaDB oder vielleicht doch SQL (Express)
Aber! das kostet auch und du musst dich wieder komplett reinfuchsen. Wenn Access bereits vorhanden ist, würde ich da auch bleiben wollen. Es sind da ja schon Leute da, die damit umgehen können.
Kostentechnisch die Runtime und gut.
Datenbanktechnisch bin ich selber weg. Das müssen andere beantworten, ob MariaDB oder vielleicht doch SQL (Express)