Office: Anti-Access-Kurs in der Dienststelle

Hallo in die Runde,

in unserer Dienststelle zeichnet sich eine Tendenz gegen Access ab. Hintergrund ist ein Rollout neuer Computer durch unseren Haus- und Hof-Dienstleister in Q1/2020. Nach derzeitigem Kenntnisstand werden die Maschinen mit Windows 10 64bit mit Office 2016 oder 2019 32bit ausgerollt. Soweit, so gut.

Die IT-Leitung stellt jetzt alle Access-Anwendungen auf den Prüfstand. mde’s/accde’s bzw. mdb’s/accdb’s, die bisher unter Office 2013 problemlos liefen, sollen mit dem neuen System angeblich nur signiert laufen. Der Grundton darüber lautet: „Access ist tot“ oder „Die Datenbanken fallen uns auf die Füße“ *entsetzt

Alles sollte schnell nach Oracle und ein Webfrontend umgestellt werden.

Ich habe in den Downloads zur 14. AEK den Vortrag von Karl Donaubauer gefunden, der mir schon einige Argumente pro Access liefert (http://donkarl.com/Downloads/AEK/AEK14_Status.zip).

Ganz überzeugen konnte ich die Vorgesetzten damit jedoch noch nicht. Gut geht es mir mit dem Gedanken, mich von Access verabschieden zu müssen, nicht. *depressed

Habt ihr evtl. noch Argumentations-Hilfen parat?

:)

 

Leider habe ich keine "Pro-ACCESS-Argumente" sondern eher schlechte Nachrichten.
Ein guter Freund meinerseits war vom 04.5 bis 13.05 bei der Microsoft Build 2019 in Seattle. Er hat mir berichtet, das die Tage von ACCESS als Desktop-Datenbank wohl gezählt sind.
Vielleicht kommt auch daher die Aussage

MS sprach von 2022-2023, man will alles in die Cloud verlagern und die Ersatzprodukte sind der SQL-Server und die Software Azure. ACCESS soll aus dem Office-Paketen herausgelöst werden, als Backend-Datenbank gibt es seit dem Frühjahr 2018 bei vielfachem Zugriff bereits erhebliche Probleme, mit denen man sich nicht auf Dauer herumschlagen will. Die unterschiedlichen Updates für die verschiedenen Versionen 2010;2013;2016 usw. würden auch zu viele Resourcen bei MS binden.
Als Frontend soll es übergangsweise ein abgespecktes Tool a la Access geben, die Zukunft sei jedoch Visual Studio oder .NET-Lösungen.
Einen mittleren Betrieb mit ca. 50 Datenbank-Usern habe ich zusammen mit besagtem Freund (SQL-Server Experte) auf den SQL-Server Express 2017 als Backend-Datenbank umgestellt. ACCESS 2016 auf allen Arbeitsplätzen als Frontend. Läuft absolut stabil und zuverlässig, derzeit werden die Abfragen auf den SQL-Server nach und nach übertragen (gespeicherte Prozeduren und auch Views) um die Geschwindigkeit zu optimieren.

 

Das die IT-Leitung etwas auf den Prüfstand stellt, ist doch normal und gut. So etwas muß von Zeit zu Zeit gemacht werden.

Nur, was ist das Ergebnis?

Das wird wohl so schnell nicht gehen. Wer soll denn die Umstellung vornehmen? Sind das KnowHow und die ManPower dafür im Unternehmen vorhanden und sind die Anwendungen überhaupt dafür geeignet?

Wie hoch sind die zu erwartenden Folgekosten (Lizenz-, Service-, Personal- und Ausbildungskosten)?

Langfristig könnte man sich vieles vorstellen ...

@elmar
Da gab es doch schon mal den Versuch von MS, etwas mit Visual Studio zu machen, als Alternative zu Access in der Net Welt. Gab es aber nicht lange und war wohl ein Ladenhüter. Wie hieß das doch gleich? Schon wieder vergessen *wink.gif*

Ulrich

 

Ich denke, man muss erst einmal unterscheiden, ob man bei Access an das Backend (das wäre die eigentliche Desktop-DB) oder an die Frontend-Funktionalität denkt. Eine solche pauschale Aussage wie oben zeugt von Unverstand.

Es gibt eine Reihe von Personen, die sagen schon seit Jahrzehnten, dass man in einem professionellen Umfeld (IT ??) als Backend ein aktives DBMS einsetzen sollte bzw. muss. Nutzeranzahl, Dateigröße, Sicherheitsaspekte, Datensicherung im laufenden Betrieb, Zentralisation und damit übersichtlichere Pflege von Verarbeitung - solche Punkte können schon einzeln für ein aktives DBMS und gegen ein File-Backend sprechen. Da geht es an fast jeder Front um richtig Geld, anders als bei einem Home-Anwender.
Gegenfrage: Die vielen Access-Anwendungen wurden erstellt, obwohl die IT ein richtiges aktives DBMS zur Verfügung gestellt hatte? Warum?

Daneben: Die Jet-Engine/ACE als Träger des Accessbackends ist im Betriebssystem seit Win 2000 enthalten bzw. kommt spätestens mit einer Officeinstallation dazu. MDB/ACCDB erstellen, Tabellen + Felder anlegen, Indizes, Beziehungen erstellen, Daten einfügen, ändern, löschen - alles kann man ohne Access, einfach per Code (DAO, ADOX/ADODB, SQL). Als lokaler Datenspeicher für diverse kleine Anwendungen hat eine solche DB allemal eine höhere Wertigkeit als eine Excelmappe, ein Haufen von Textdateien oder was man sonst noch nimmt.
Wer einmal auf seinen Rechner schaut: Da gibt es eine Reihe von MDB's, die mit Access nie etwas zu tun hatten. Wenn das gestrichen würde, würde man sich stärker wundern als gedacht. Der Ersatz durch XML, wo man Daten auch strukturiert ablegen kann und was ja durchaus öfter anzufinden ist, ist jetzt auch nicht simpel und erfordert eine Menge an Kompetenz und Programmieraufwand.

Die Rolle von Access als Frontend ist dann auch ziemlich klar. Man muss schon suchen, um eine grafische Bedienoberfläche mit etwas Funktionalität mal so schnell und einfach (Zusammenklicken, Assistenten) erstellen zu können.

Woran ich auch denken würde: Käme man auf die Idee, den Verkaufsschlager Excel zu eliminieren? Auch hier im Forum erlebt man recht oft, dass Excel zu klein wird und man Daten anderswo ablegen und gar verarbeiten muss. Wird man da statt an den nächstgrößen Bruder Access gleich an Oracle & Co denken wollen und vor allem umsetzen können (Fachwissen, Berechtigungen auf Zugang, zeitnahe uns ausreichende Unterstützung durch die IT)?

 

Hallo zusammen,

herzlichen Dank für Eure Ausführungen. Immerhin: In der kommenden Woche gibt es einen kleinen „IT-Gipfel“ mit allen Verantwortlichen, auf dem ich hoffentlich alle Fragezeichen aus der Welt schaffen kann.

Meinst Du evtl. LightSwitch?

Gruß, RookieOne

 

Hallo RookieOne,

genau: LightSwitch hieß das und wie es aussieht, gibt es immer noch ein paar Alternativprodukte dazu, beispielsweise: openxava um nur eines zu nennen. Die anderen kann man leicht mit einer Suchmaschine finden.

Eine andere Möglichkeit könnte eventuell auch Xojo sein.

Keine Gewähr und vor allem ungetestet! Es muß sich jeder selber einen Eindruck verschaffen.

Gruß Ulrich

 

Hallo, knobbi38,
hallo zusammen,

im heutigen Gespräch wurde die Situation etwas „erhellt“.

Access-Datenbanken werden nicht per se geblockt o.ä.

Die Makrosicherheit wird von der IT auf „Mittel“ gestellt. Künftig soll der Code signiert werden und mdbs/accdbs usw. paketiert werden. Dann wird auch die Makrosicherheit auf „Hoch“ gesetzt. Jedoch wird das wohl noch nicht mit dem kommenden Rollout in Kraft treten.

 

Ich kenne das Problem, habe ich bei einer grossen Behörde vor 15 J durchgemacht. Hab mir im Innenministerium eine blutigen Nase geholt ;-)
Es sollte damals eine Anwendung unter dem aktuellen System geproggt werden, ist bis heute nicht geschehen.
Meine DB (eine ganze Abteilung arbeitet damit äusserst effizient) läuft nun seit 23 J auf einem separaten (jetzt)WinServer und die Frontends werden über Citrix bedient. Der Betrieb wird stillschweigend geduldet, weil niemand in der Lage ist/war, unter SAP diese Anwendung nachzubilden (zu horrenden Preisen). Übrigens äusserst stabil, erst auf Acc2.0 bis jetzt auf Acc2016

 

Tja, da hat jemand eine theoretisch gute Idee gehabt, die in der Praxis leider gegen die Wand fahren wird.

VBA-Code in Access kann gegenwärtig nicht signiert werden!
Lektüre (englisch): Signing VBA Code in Access .accdb databases

 

Hallo, sonic8,

das ist ja ein interessanter Artikel. OK, mit dem Thema „Code-Signierung“ hatte ich mich bislang noch nicht auseinandergesetzt.