Datum: 18.05.2022
Thema: Präsentation einer Anwendung durch Teilnehmer, Hilfe bei Problemen, Allgemeine Diskussion. Und wieder alles virtuell.
Zum Mai-Stammtisch gesellte sich ein neues Gesicht in die Zoom-Runde. Begrüßen durften wir Elisabeth.
Nach ein wenig Urlaubsimpressionen – hervorgerufen durch diverse Hintergrundbilder in der Zoom-Session – folgte eine kurze Vorstellungsrunde. Den Auftakt machte Uwe, dessen IT-Anfänge in die C64-/C128-Zeit fielen. Bei der BEB kam er mit Access 2.0 in Berührung. Heute ist er bei der Nord/LB tätig. Hier wird jedoch im IT-Bereich viel Outsourcing betrieben. Daher wird auch weniger mit Access programmiert.
Auch Daniel berichtet von Access-Ablösungsbestrebungen in einem Landesministerium – obgleich man gut und kostengünstig mit Access programmieren kann.
Uwe berichtet von zwei Anwendungen bei der Nord/LB auf Visual Studio / C++-Basis; sie laufen heute noch nicht 🥴
Klaus sieht für eine Abkehr von Access keinen prinzipiellen Grund. Einzelgründe mag es geben, aber kein Grund das Pferd zu wechseln. Beispielsweise kann die Version hochgezogen werden.
Elisabeth steht auch vor dem Hochziehen der Access-Version von 2016 auf Access 365.
Klaus ergänzt, dass Access 2016/2019/365 die selbe Codebasis haben.
Bei Access 365 können Updates querschießen, z.B. für das Windows 10-Caching und Access Backends.
Uwe empfiehlt, den Einsatz des SQL Server Migration Assistant for Access für Elisabeths Anwendung.
Das Problem ist, dass Abfragen in Access auf Server-/Backend-Konstellationen langsam sind. Schneller sind hier sog. Pass Through-Abfragen.
Der Migrationsassistent von Microsoft gibt hier Warnungen vor Migrationsproblemen aus.
Bedenken sollte man auch, Datentypen migrierbar zu machen. Datentypen in Access funktionieren nämlich etwas anders als auf dem SQL Server.
Uwe erwähnt, das z.B. Date-/Time-Felder problematisch werden können. Klaus ergänzt, das bei Bit-Felder Access keine Null-Werte kennt – das schafft nur der SQL Server. Und Constraints müssen im SQL Server erstellt werden. Problematisch sind auch BLOB-Felder.
Ganz allgemein lassen sich 98% der Datentypen zuordnen, 2% erfordern Nacharbeit oder können nicht geändert werden.
Uwe erwähnt, das sich im SQL Management Studio eine Liste aller Datentypen ausgeben lässt.
Elisabeth will denn auch evtl. eine Analyse der DB vornehmen.
Uwe schlägt vor, sämtlich Module in eine Textdatei zu exportieren.
Problematisch kann es bei Eigenschaften werden, weiß Klaus.
Wenn Access mobil genutzt werden soll, bietet sich ein Remote Desktop-Zugriff an. Access hat Schwierigkeiten mit Laufzeiten auf File Servern zwischen Frontend und Backend. Dies kann im Ernsfall zu Konflikten bei langsamem Zugriff führen.
Sönke berichtet von einer Zeiterfassungs-Datenbank im LAN. Diese „schmiert“ öfter ab. Es gibt immer Probleme. Maximal können zehn Zugriffe erfolgen, offen sind i.d.R. sechs Zugriffe.
Es reicht, nur die Datenbank zu öffnen, dann wird eine laccdb-Datei (Sperrdatei) angelegt.
Die Erkenntnis des Abends daraus ist: Access braucht ein Rock solid-Netzwerk!
Als Alternative bietet sich der Zugriff per ODBC auf einen SQL Server an.
Sönke dachte an eine ADO DB.
Daniel schlägt eine Database 1…n-Architektur vor.
Uwe vermutet, das evtl. Datenbanken, die Access nach einem Absturz anlegt, ursächlich sein können.
Elisabeth fragt nach einem Bugtracking-Tool.
Klaus schlägt einfach Excel vor. Elisabeth setzt derzeit auf Word.
Daniel verweist auf eine Access-Vorlage: https://support.microsoft.com/de-de/office/empfohlene-access-vorlagen-e14f25e4-78b6-41de-8278-1afcfc91a9cb
Zum Schluss des Stammtisches gab es noch einen Webtipp zur Access DevCon-Nachlese, die Mike Wolfe verfasst hat:
https://nolongerset.com/devcon-vienna-2022-recap-1-1/
https://nolongerset.com/devcon-vienna-2022-recap-1-2/
Access-Stammtisch Hannover 