- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#41
Access Programmierung / Re: Wie viele BackEnds sind si...
Letzter Beitrag von Knobbi38 - Juli 27, 2026, 11:07:42Hallo Doming,
Knobbi38
Zitat von: Doming am Juli 22, 2026, 10:10:20im Schatten dieser Anfrage steht für mich die Frage: wie viele BackEnds sind sinnvoll?bitte beachte, dass es sich bei Access um eine relationale Datenbank handelt und nicht um Excel-Tabellen. Relationen können jedoch nur innerhalb einer Datenbank verwaltet werden und nicht über deren Grenzen hinaus. Somit sind mehrere Backends bezüglich der referentiellen Integrität kontraproduktiv.
Knobbi38
#42
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Debus - Juli 25, 2026, 20:23:58Hey, wie Christian schon schreibt, setze Dir mal lokal eine SQL Server auf und über damit, bevor Du die Access Datenbank beerdigst.
Du findest sowas ganz einfach hier kostenlos
https://www.microsoft.com/de-de/sql-server/sql-server-downloads
Gruß
Holger
Du findest sowas ganz einfach hier kostenlos
https://www.microsoft.com/de-de/sql-server/sql-server-downloads
Gruß
Holger
#43
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Bitsqueezer - Juli 23, 2026, 21:10:36Hallo,
naja, wie arbeitest Du mit Access ohne SQL-Kenntnisse?
Aber wie gesagt: Das, was Du mit grafischen Designern in Access machen kannst, kannst Du auch mit SSMS machen, der Rest kommt von ganz allein. T-SQL ist weitaus umfangreicher als das karge Access SQL, die Möglichkeiten dafür auch.
Und: Wenn Du einen lokalen SQL Server installierst, kannst Du ja erst in Ruhe alles ausprobieren, ohne Firmendaten zugefährden.
Gruß
Christian
naja, wie arbeitest Du mit Access ohne SQL-Kenntnisse?
Aber wie gesagt: Das, was Du mit grafischen Designern in Access machen kannst, kannst Du auch mit SSMS machen, der Rest kommt von ganz allein. T-SQL ist weitaus umfangreicher als das karge Access SQL, die Möglichkeiten dafür auch.
Und: Wenn Du einen lokalen SQL Server installierst, kannst Du ja erst in Ruhe alles ausprobieren, ohne Firmendaten zugefährden.
Gruß
Christian
#44
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Doming - Juli 23, 2026, 12:22:02Zitat von: Bitsqueezer am Juli 23, 2026, 09:01:33Ich würde empfehlen, einfach die nächstbeste KI zu verwenden, die Dir geduldig jede Frage dazu beantworten kann. Die kannst Du auch fragen, ob sie Dir Tutorials nach Deinen Vorstellungen heraussuchen kann (vorzugsweise hier Gemini mit Google Suchmaschine im Hintergrund), außerdem kannst Du sie fragen, ob sie die Rolle als Lehrer einnehmen kann, also keine fertigen Lösungen präsentiert, sondern Dir das Thema näherbringt.
Ich habe nun schon einige Probleme in VBA mittels KI lösen können, hatte aber da aber den Vorteil, dass ich so ungefähr wusste, was mir da vorgeschlagen wird. Da SQL wie erwähnt Neuland ist, habe ich Angst, dass mir der Kollege irgendwelchen Kram erzählt, der im Nachhinein gar nicht funktionieren kann.
#45
Access Programmierung / Re: Wie viele BackEnds sind si...
Letzter Beitrag von Bitsqueezer - Juli 23, 2026, 12:09:49Hallo,
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
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
#46
Access Programmierung / Re: Wie viele BackEnds sind si...
Letzter Beitrag von Doming - Juli 23, 2026, 09:40:20Hallo 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
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
#47
Access Programmierung / Re: Wie viele BackEnds sind si...
Letzter Beitrag von Bitsqueezer - Juli 23, 2026, 09:13:57Hallo,
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
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
#48
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Bitsqueezer - Juli 23, 2026, 09:01:33Hallo,
naja, Tutorials gibt es sicherlich, aber welches davon zu Dir paßt, mußt Du schon selbst herausfinden.
Ich würde empfehlen, einfach die nächstbeste KI zu verwenden, die Dir geduldig jede Frage dazu beantworten kann. Die kannst Du auch fragen, ob sie Dir Tutorials nach Deinen Vorstellungen heraussuchen kann (vorzugsweise hier Gemini mit Google Suchmaschine im Hintergrund), außerdem kannst Du sie fragen, ob sie die Rolle als Lehrer einnehmen kann, also keine fertigen Lösungen präsentiert, sondern Dir das Thema näherbringt.
Aber so generell: Du arbeitest im Backend mit SSMS (SQL Server Management Studio, kannst Du Dir bei MS kostenlos downloaden, verwaltet jedwede SQL Server Instanz). Damit verbindest Du Dich auf den SQL Server und er listet Dir u.a. alle vorhandenen Datenbanken. Die kann man aufklappen und findet dann Tabellen, Views ("Sichten"), und einiges mehr.
Hier kannst Du z.B. neue Tabellen mit einem grafischen Designer erstellen, recht ähnlich zu dem von Access. Du kannst Views (Abfragen/Queries) erstellen, ebenfalls mit einem grafischen Designer, der um einiges einfacher und logischer ist als der von Access. Das sind schon die beiden wichtigsten Dinge. Es gibt auch einen Beziehungseditor ("Diagramme"), im Gegensatz zu dem von Access kannst Du hier auch so viele Diagramme anlegen, wie Du willst, so daß nicht ein Spinnennetz von wirren Beziehungen aus ALLEN Tabellen entsteht, wie man es in Access hat, sondern je Thema getrennt, außerdem kann man Notizen an beliebiger Stelle in's Diagramm schreiben.
Bis hierhin mußt Du also nicht einmal eine Zeile SQL können, um alles verwalten zu können.
Und, wie gesagt, SSMA (SQL Server Migration Assistant, ebenfalls kostenlos bei MS downloadbar) kannst Du dazu verwenden, Deine aktuelle Datenbank zu migrieren (immer mit einer Kopie natürlich, weil SSMA die Access-Datei verändert). Er sammelt die verlinkten Ressourcen eines Access Backends ein, holt auch lokale Tabellen des Frontends und schiebt alles als neue Tabellen auf den Server, verlinkt sie dann passend ins Frontend und behält dabei die Namen bei, so daß Dein Frontend, wenn es nicht zu kompliziert gebaut ist, nach Fertigstellung sofort mit SQL Server lauffähig ist (im Idealfall).
Natürlich braucht es etwas Nacharbeit, zum Beispiel sinnvolle Indizes zu setzen, die nicht immer richtig oder gar nicht übernommen werden, usw.
Lokale Queries übersetzt er, glaube ich, nicht. Hier kann man dann entsprechend analoge Views auf dem SQL Server erstellen und ins Frontend verlinken, um die Performance zu verbessern. Was bei Views natürlich nicht geht: Zugriffe auf lokale VBA-Funktionen oder auf Formular/Report-Elemente.
Views sind, korrekt erstellt, wie Tabellen editierbar. Für das Access-Frontend gibt es da keinen Unterschied, für Access sind alles Tabellen.
Es ist empfehlenswert, für Access keine Tabellen direkt zu verlinken, sondern immer nur Views. Aber das ist mit Access (ohne SQL Server) ja ebenso zu empfehlen.
Für einen ersten Test würde ich empfehlen, einen lokalen SQL Server zu installieren (Developer-Version ist gratis, aber entspricht der größten SQL Server Ausbaustufe, alternativ SQL Server Express). Für Produktiv-Umgebung SQL Server Express (Developer darf nicht produktiv eingesetzt werden) oder, wenn der Weg dahin klar ist und Budgets vorhanden sind, dann mind. die SQL Server Standard Version, die i.d.R. alle Wünsche abdeckt. Die kostet halt Lizenzen je User oder alternativ je CPU-Kern, dann unbegrenzte User.
Mit einem lokalen kannst Du erst mal experimentieren, SSMA ausprobieren usw.
Gruß
Christian
naja, Tutorials gibt es sicherlich, aber welches davon zu Dir paßt, mußt Du schon selbst herausfinden.
Ich würde empfehlen, einfach die nächstbeste KI zu verwenden, die Dir geduldig jede Frage dazu beantworten kann. Die kannst Du auch fragen, ob sie Dir Tutorials nach Deinen Vorstellungen heraussuchen kann (vorzugsweise hier Gemini mit Google Suchmaschine im Hintergrund), außerdem kannst Du sie fragen, ob sie die Rolle als Lehrer einnehmen kann, also keine fertigen Lösungen präsentiert, sondern Dir das Thema näherbringt.
Aber so generell: Du arbeitest im Backend mit SSMS (SQL Server Management Studio, kannst Du Dir bei MS kostenlos downloaden, verwaltet jedwede SQL Server Instanz). Damit verbindest Du Dich auf den SQL Server und er listet Dir u.a. alle vorhandenen Datenbanken. Die kann man aufklappen und findet dann Tabellen, Views ("Sichten"), und einiges mehr.
Hier kannst Du z.B. neue Tabellen mit einem grafischen Designer erstellen, recht ähnlich zu dem von Access. Du kannst Views (Abfragen/Queries) erstellen, ebenfalls mit einem grafischen Designer, der um einiges einfacher und logischer ist als der von Access. Das sind schon die beiden wichtigsten Dinge. Es gibt auch einen Beziehungseditor ("Diagramme"), im Gegensatz zu dem von Access kannst Du hier auch so viele Diagramme anlegen, wie Du willst, so daß nicht ein Spinnennetz von wirren Beziehungen aus ALLEN Tabellen entsteht, wie man es in Access hat, sondern je Thema getrennt, außerdem kann man Notizen an beliebiger Stelle in's Diagramm schreiben.
Bis hierhin mußt Du also nicht einmal eine Zeile SQL können, um alles verwalten zu können.
Und, wie gesagt, SSMA (SQL Server Migration Assistant, ebenfalls kostenlos bei MS downloadbar) kannst Du dazu verwenden, Deine aktuelle Datenbank zu migrieren (immer mit einer Kopie natürlich, weil SSMA die Access-Datei verändert). Er sammelt die verlinkten Ressourcen eines Access Backends ein, holt auch lokale Tabellen des Frontends und schiebt alles als neue Tabellen auf den Server, verlinkt sie dann passend ins Frontend und behält dabei die Namen bei, so daß Dein Frontend, wenn es nicht zu kompliziert gebaut ist, nach Fertigstellung sofort mit SQL Server lauffähig ist (im Idealfall).
Natürlich braucht es etwas Nacharbeit, zum Beispiel sinnvolle Indizes zu setzen, die nicht immer richtig oder gar nicht übernommen werden, usw.
Lokale Queries übersetzt er, glaube ich, nicht. Hier kann man dann entsprechend analoge Views auf dem SQL Server erstellen und ins Frontend verlinken, um die Performance zu verbessern. Was bei Views natürlich nicht geht: Zugriffe auf lokale VBA-Funktionen oder auf Formular/Report-Elemente.
Views sind, korrekt erstellt, wie Tabellen editierbar. Für das Access-Frontend gibt es da keinen Unterschied, für Access sind alles Tabellen.
Es ist empfehlenswert, für Access keine Tabellen direkt zu verlinken, sondern immer nur Views. Aber das ist mit Access (ohne SQL Server) ja ebenso zu empfehlen.
Für einen ersten Test würde ich empfehlen, einen lokalen SQL Server zu installieren (Developer-Version ist gratis, aber entspricht der größten SQL Server Ausbaustufe, alternativ SQL Server Express). Für Produktiv-Umgebung SQL Server Express (Developer darf nicht produktiv eingesetzt werden) oder, wenn der Weg dahin klar ist und Budgets vorhanden sind, dann mind. die SQL Server Standard Version, die i.d.R. alle Wünsche abdeckt. Die kostet halt Lizenzen je User oder alternativ je CPU-Kern, dann unbegrenzte User.
Mit einem lokalen kannst Du erst mal experimentieren, SSMA ausprobieren usw.
Gruß
Christian
#49
Access Programmierung / Re: Wie viele BackEnds sind si...
Letzter Beitrag von Doming - Juli 23, 2026, 07:07:12Hallo,
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
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
#50
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Doming - Juli 23, 2026, 06:15:50Hallo,
da ich bisher ausschließlich mit Access-BackEnds gearbeitet und mir mein bisheriges Wissen autodidaktisch beigebracht habe, gibt es ein möglichst nicht zu verkopftes Tutorial, welches man sich dazu mal einverleiben könnte?
Gruß
Doming
da ich bisher ausschließlich mit Access-BackEnds gearbeitet und mir mein bisheriges Wissen autodidaktisch beigebracht habe, gibt es ein möglichst nicht zu verkopftes Tutorial, welches man sich dazu mal einverleiben könnte?
Gruß
Doming