manuel-r
Goto Top

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.
  • 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 face-wink

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

Content-ID: 668334

Url: https://administrator.de/contentid/668334

Printed on: December 10, 2024 at 14:12 o'clock

ForgottenRealm
ForgottenRealm Sep 24, 2024 at 09:49:36 (UTC)
Goto Top
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 ...
manuel-r
manuel-r Sep 24, 2024 at 10:14:03 (UTC)
Goto Top
Zitat von @ForgottenRealm:
Wäre halt auch nice zu wissen, wie groß der Umfang deiner Access Datenbank ist, wieviele Tabellen, relationen, was genau da drin steht ...

Das sind alles kleine Datenbanken mit einigen wenigen Tabellen und Relationen. Da werden dann in verschiedenen Abteilungen Dinge erfasst die unsere Hauptanwendungen so nicht her geben.

Ein Frontend bietet unseren Technikern Auswertungen darüber wieviel Material welcher Sorte in einem Zeitraum auf/für ein bestimmtes Projekt produziert/geliefert wurde. Die Daten dazu kommen aus der entsprechenden Produktionsanlage.
In einem anderen Fall erfasst unsere Dispo die Material- und Geräteanforderungen die von draußen eingehen um den Überblick zu behalten was er wann an welchem Ort anliefern muss.
Ein Dritter Fall hilft dabei den Überblick zu behalten welche Materialien in welcher Menge von welchem Projekt wie entsorgt oder verkauft werden müssen/können.
Ein letztes Beispiel hilft der zuständigen Kollegin den Überblick über Fahrzeuge/Maschinen und die zugehörige Versicherungen und Schäden zu bewahren.

Das Ganze für jeden aktuellen und zukünftigen Anwendungsfall entwickeln zu lassen kann mit Rücksicht auf die einmaligen und laufenden Kosten nicht das Ziel sein. Solche Sachen leben ja und wir alle wissen, dass da öfter hier und da mal was hinzugefügt oder geändert werden soll/muss. Und da habe ich wenig Lust, dass dann jedes Mal ein Entwickler gleich mal 4-stellige Rechnungen schreibt.

Und natürlich gibt es für all diese Beispiele irgendeine Spezialanwendung die das kann und noch tausend Sachen mehr die niemand wirklich braucht. Für dieses tausend Features muss man dann natürlich auch entsprechend zahlen.
kpunkt
kpunkt Sep 24, 2024 at 11:08:01 (UTC)
Goto Top
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?
manuel-r
manuel-r Sep 24, 2024 updated at 11:32:13 (UTC)
Goto Top
Die Frage ist aber: wieso weg von Access?

In grauer Vorzeit hatten einige User das Office als Pro (mit Access) um eben solche Sachen damit zu machen. Alle anderen hatten das kleine Office ohne Access und dafür mit der Runtime damit sie mit den Frontends arbeiten konnten.
Dann gab es mehr und mehr Gejammer, warum X ein Access hat und Y eben nicht. Das hat dann dazu geführt, dass wir danach alle mit Pro ausgestattet haben. Das war recht günstig mit Gebraucht-Lizenzen abbildbar.

Bei den Preisen die Microsoft gedenkt für Office 2024 aufzurufen bzw. das was die Pakete mit Access in O365 kosten muss man sich über das Thema eben wieder Gedanken machen. Bei ~180 Usern wirkt sich das schon im Geldbeutel aus.

Und deswegen ja auch die Frage in die Runde, ob vielleicht wieder "kleines" Office und Access-Runtime.
Bitsqueezer
Bitsqueezer Sep 24, 2024 at 21:20:38 (UTC)
Goto Top
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
DivideByZero
DivideByZero Sep 24, 2024 at 22:08:15 (UTC)
Goto Top
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
wiesi200
wiesi200 Sep 25, 2024 at 00:45:03 (UTC)
Goto Top
Hallo,

hab's zwar noch nie getestet aber gibt's dafür nicht Microsoft Power App bzw. Das ganze Low Code Zeugs.
kpunkt
kpunkt Sep 25, 2024 at 05:12:52 (UTC)
Goto Top
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)