Wie viele BackEnds sind sinnvoll?

[Doming]

Hallo,

im Schatten dieser Anfrage steht für mich die Frage: wie viele BackEnds sind sinnvoll?

Ich hatte in der Vergangenheit Vorfälle, in denen ein Datensatz defekt war und ich als Entwickler Probleme hatte, die Datenbank zu reparieren, weil andere FrontEnds das BackEnd blockierten, auch wenn sie die betroffene Tabelle gar nicht genutzt haben.

Insofern wäre es ja sinnvoll, für jede Tabelle ein eigenes BackEnd zu erstellen, oder?

Gruß
 Doming

[Bitsqueezer]

Hallo,

Dein Problem wird ja nicht besser, indem Du die Tabellen auf Backends verteilst. Access hält die Links zum Backend (zu allen Backends) in je einer Verbindung offen. Auch dann übrigens je eine Verbindung, wenn Du alles in einem Backend hast.
Also blockierst Du statt einem 20 Backends...
Der einzige kleine Vorteil wäre, daß jedes Backend dann 2GB Größe haben kann. Aber wenn man dabei bereits Probleme hat, sollte man eh über einen DB-Server als Backend nachdenken.
Oder anders formuliert: Man sollte besser grundsätzlich keine Access Backends verwenden, besonders bei vielen beteiligten Usern. Es gibt heutzutage keine wirkliche Begründung mehr, ein Access Backend einzusetzen, weil alle Arten von DB-Servern zu bekommen sind, auch ohne Kosten, die alle besser sind als Access als Backend.
Empfehlung: SQL Server Express, multi-user-tauglich, ReportingServices optional installierbar, ebenso Analysis Services, Integration Services...
und arbeitet perfekt mit Access zusammen, mit SSMA auch leicht (und gratis) zu migrieren.
Es ginge auch MySQL oder PostgreSQL usw.

Gruß

Christian

[Doming]

Hallo,

aktuell arbeite ich mit 18 Datenbanken mit knapp 300 Tabellen (lokal oder verteilt auf 10 BackEnds). Eine Umstellung auf SQL-Server stelle ich mir umfangreich vor.

Gruß
 Doming

[Bitsqueezer]

Hallo,

ja, natürlich ist es erst mal einiges an Arbeit. SSMA wird Dich unterstützen, ein Frontend mit passenden Access-Backends auf den SQL Server zu migrieren.
Wenn sich die Ressourcen überschneiden (gemeinsam genutzte Tabellen in verschiedenen Frontends), muß man sicherlich auch Handarbeit leisten. Aber in diesem Fall genügt es, eins davon zu migrieren, die Tabelle ist ja dann schon auf dem Server, und bei allen weiteren die Tabelle aus der Migration auszuklammern. Verlinken mußt Du sie dann selbst, aber das ist ja kein Akt.

U.U. wirst Du feststellen, daß viele der Tabellen nicht mehr nötig sind, wenn viele ähnliche Tabellen einsetzen, die zu einer konsolidiert werden können. Dafür mußt Du sie dann auch nur noch an einer Stelle anpassen, auch inhaltlich. Beispielsweise, wenn Du eine eigene Usertabelle hast oder Ähnliches. Die kannst Du u.U. auch ganz ablösen, wenn Du Dich mit dem Rechtesystem vertraut gemacht hast.
(Bei der Installation von SQL Server möglichst den gemischten Modus installieren, damit kannst Du sowohl Windows Authentication mit Domänenusern verwenden als auch SQL Server User, die von SQL Server direkt verwaltet werden und je Datenbank individuell verwaltet werden können.)

Du KANNST alle 300 natürlich in eine Datenbank einstellen, wenn sie einen gemeinsamen Zweck erfüllen. Wenn es aber z.B. solche gibt, die mit Tabellen/Funktionen so gar nichts mit anderen zu tun haben, ist es auch kein Problem, weitere Datenbanken zu erstellen.

Rechtetechnisch kann man die gleichen User auch zu mehreren Datenbanken zuweisen, dann können diese auch beide Datenbanken benutzen, auch z.B. in nur einer Abfrage Tabellen beider Datenbanken verwenden.

Langfristig wirst Du Dich fragen, wieso Du die Migration nicht schon vor x Jahren gemacht hast...

Fang einfach mal mit der einfachsten Version an: Lokaler Developer SQL Server, SSMA laden und eines Deiner Frontends (erst mal ein möglichst einfaches) auf diesen migrieren.

SSMA: https://learn.microsoft.com/de-de/sql/ssma/sql-server-migration-assistant?view=sql-server-ver17
SSMS: https://learn.microsoft.com/de-de/ssms/install/install
SQL Server Express und Developer: https://www.microsoft.com/de-de/sql-server/sql-server-downloads

Gruß

Christian

[Doming]

Hallo Christian und vielen Dank für Deine Ausführungen.

Leider sehe ich da aktuell keine großen Chancen, das auch durchzubekommen.
In der Hierarchie sitze ich hier nicht gerade an oberster Stelle, bei den Entscheidern Änderungen durchzubekommen ist eher schwierig. Wie gesagt, von oben wird vorgegeben, möglichst alle Access-Datenbanken abzuschalten. Die Abteilungen, die seit Jahren an die Anwendungen gewöhnt sind, wollen am besten keine Veränderungen ("Wieso, läuft doch alles") und auf Konzernebene wird dann entschieden, dass diese und jene Software gar nicht mehr verwendet werden soll...

Von den 300 Tabellen werden viele nachts aus SAP importiert. Einige davon werden gar nicht mehr verwendet. Der Konvertierer soll auch eingestampft werden, mal sehen, wie ich die Funktionen abfange.

Leicht resignierte Grüße
 Doming

[Bitsqueezer]

Hallo,

naja, wenn es abgeschafft werden soll, ist das ja genau der Königsweg: Access-Backends werden durch SQL Server abgelöst - also: keine Access-Datenbanken mehr.

Access-Frontends bleiben, aber sind dann ja keine Access-Datenbanken mehr, sondern Apps mit SQL Server Backend. Somit sind auch die User glücklich, für sie ändert sich nichts.

SAP-Download: Kann mit SQL Server automatisiert werden, da man hier auch ohne Userinteraktion Jobs ausführen kann, die den Task erledigen.

Kosten: Sind hier sicherlich erst mal höher, aber das rechnet sich später, weil man hier deutlich an Sicherheit gewinnt (Backups/Usersicherheit/Sicherheit gegen externe Angriffe uvm.) und später auch Auswertungen erstellen kann, z.B. PowerBI o.Ä. (oder Reporting Services, was schon in SQL Server enthalten ist).

Was nicht mehr gebraucht wird, kann man ja in dem Zuge gleich entsorgen.

Sollen auch Access-Frontends nicht mehr verwendet werden, kann man sie nach und nach gegen .NET- oder andere Frontendtechnologien austauschen, zur Not auch PowerApps.
Natürlich muß man hier alles neu programmieren, kann sich aber zumindest nach den bestehenden Anwendungen ausrichten. Das Backend bleibt dabei gleich.

Gruß

Christian