- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#51
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Bitsqueezer - Juli 22, 2026, 14:26:45Hallo,
neinnein, Du hast mich falsch verstanden: Nicht die Access-Anwendungen (die Frontends), sondern nur das Backend.
Das ist einigermaßen einfach auszutauschen mit SSMA und die Frontends funktionieren danach i.d.R. 1:1 wie vorher.
Die IT wird es freuen, nur eine Datenbank auf SQL Server mit Backup (automatisiert durch SQL Server selbst) zu bestimmten Zeiten durchzuführen, statt x Access Backends, die ggf. gerade auch noch defekt sind.
Gruß
Christian
neinnein, Du hast mich falsch verstanden: Nicht die Access-Anwendungen (die Frontends), sondern nur das Backend.
Das ist einigermaßen einfach auszutauschen mit SSMA und die Frontends funktionieren danach i.d.R. 1:1 wie vorher.
Die IT wird es freuen, nur eine Datenbank auf SQL Server mit Backup (automatisiert durch SQL Server selbst) zu bestimmten Zeiten durchzuführen, statt x Access Backends, die ggf. gerade auch noch defekt sind.
Gruß
Christian
#52
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Doming - Juli 22, 2026, 10:44:53Hmtja, tatsächlich ist es so, dass unsere IT am Liebsten sowieso alle Access-Anwendungen einstampfen will (die Argumentation kann ich verstehen, ich möchte als Außenstehender meinen Quellcode auch nicht reparieren müssen, wenn der Verursacher im Urlaub ist 
) Allerdings sind die Dinger teilweise schon essentieller Bestandteil der Arbeitsweisen in der Abteilung, an eine Ablösung ist von der Seite kaum zu denken.
) Allerdings sind die Dinger teilweise schon essentieller Bestandteil der Arbeitsweisen in der Abteilung, an eine Ablösung ist von der Seite kaum zu denken. #53
Access Programmierung / Re: Datenbanken anonymisieren
Letzter Beitrag von Bitsqueezer - Juli 22, 2026, 10:25:44Hallo,
parallel zu Deiner anderen Frage, spätestens jetzt wäre es dringend nötig, ein DB-Backend und nicht mehr Access-Backends zu verwenden.
Zum einen hast Du ein zentrales Repository für ALLE Tabellen, die dann auch perfekt zusammenarbeiten können, zum anderen kannst Du hier alle Arten von Rechten vergeben, Zugriffsarten auf welche Ressourcen, Benutzer, Benutzergruppen, Rollen, granular bis runter zu einzelnen Feldern oder Datensätzen. Ebenso kann man Daten anonymisieren, so daß der nicht berechtigte Benutzer nur verschlüsselte Daten sieht bzw. Dummy-Daten, so daß man Daten auch vor Entwicklern verborgen halten kann, wenn gewünscht.
Mit Access ist Datensicherheit quasi nicht sinnvoll realisierbar.
Ein DB-Server braucht dabei auch keinen Fileserver, läuft als Dienst.
Gruß
Christian
parallel zu Deiner anderen Frage, spätestens jetzt wäre es dringend nötig, ein DB-Backend und nicht mehr Access-Backends zu verwenden.
Zum einen hast Du ein zentrales Repository für ALLE Tabellen, die dann auch perfekt zusammenarbeiten können, zum anderen kannst Du hier alle Arten von Rechten vergeben, Zugriffsarten auf welche Ressourcen, Benutzer, Benutzergruppen, Rollen, granular bis runter zu einzelnen Feldern oder Datensätzen. Ebenso kann man Daten anonymisieren, so daß der nicht berechtigte Benutzer nur verschlüsselte Daten sieht bzw. Dummy-Daten, so daß man Daten auch vor Entwicklern verborgen halten kann, wenn gewünscht.
Mit Access ist Datensicherheit quasi nicht sinnvoll realisierbar.
Ein DB-Server braucht dabei auch keinen Fileserver, läuft als Dienst.
Gruß
Christian
#54
Access Programmierung / Re: Wie viele BackEnds sind si...
Letzter Beitrag von Bitsqueezer - Juli 22, 2026, 10:20:55Hallo,
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
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
#55
Access Programmierung / Wie viele BackEnds sind sinnvo...
Letzter Beitrag von Doming - Juli 22, 2026, 10:10:20Hallo,
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
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
#56
Access Programmierung / Datenbanken anonymisieren
Letzter Beitrag von Doming - Juli 22, 2026, 10:05:09Hallo,
wir haben bei uns im Unternehmen eine gewachsene DB-Struktur, d.h. User A baut ein FrontEnd DB_Rechnungen und steckt die Tabellen in Rechnungen_be, User B baut DB_Auftrag und schreibt die die Tabs in Auftrag_BE usw.
Nun sollen die Fileserver abgeschaltet werden und die DB sollen auf ein neues Netzlaufwerk, damit es "mit dem Wildwuchs" ein Ende hat. Also: Die Anwender bekommen die FrontEnds irgendwo in der Verzeichnisstruktur, so dass auch nur sie Zugriff haben. Auf die BE haben ja alle Anwender Vollzugriff, damit sie die Daten lesen und schreiben können. Es gibt natürlich Tabellen, die von mehreren FrontEnds genutzt werden, z.B. tbl_Kundendaten.
Meine Idee wäre jetzt, die BackEnds zu anonymisieren, also statt Auftrag_BE dann nur noch BE1, BE2 usw.. Und auch die Tabellen könnten Dann Tab1, Tab2 usw. heißen. Das Ganze, um Manipulationen der Daten zu erschweren.
Der Entwickler hat dann natürlich eine Liste mit Art und Funktion der verschiedenen Tabellen.
Im Frontend kann Tab1 dann wieder als tbl_Kunde verknüpft werden.
Klar, für den Entwickler mehr Arbeit, aber für den Feldwaldwiesen-Schlingel eine große Hürde, um gezielt Rohdaten zu manipulieren.
Gruß
Doming
wir haben bei uns im Unternehmen eine gewachsene DB-Struktur, d.h. User A baut ein FrontEnd DB_Rechnungen und steckt die Tabellen in Rechnungen_be, User B baut DB_Auftrag und schreibt die die Tabs in Auftrag_BE usw.
Nun sollen die Fileserver abgeschaltet werden und die DB sollen auf ein neues Netzlaufwerk, damit es "mit dem Wildwuchs" ein Ende hat. Also: Die Anwender bekommen die FrontEnds irgendwo in der Verzeichnisstruktur, so dass auch nur sie Zugriff haben. Auf die BE haben ja alle Anwender Vollzugriff, damit sie die Daten lesen und schreiben können. Es gibt natürlich Tabellen, die von mehreren FrontEnds genutzt werden, z.B. tbl_Kundendaten.
Meine Idee wäre jetzt, die BackEnds zu anonymisieren, also statt Auftrag_BE dann nur noch BE1, BE2 usw.. Und auch die Tabellen könnten Dann Tab1, Tab2 usw. heißen. Das Ganze, um Manipulationen der Daten zu erschweren.
Der Entwickler hat dann natürlich eine Liste mit Art und Funktion der verschiedenen Tabellen.
Im Frontend kann Tab1 dann wieder als tbl_Kunde verknüpft werden.
Klar, für den Entwickler mehr Arbeit, aber für den Feldwaldwiesen-Schlingel eine große Hürde, um gezielt Rohdaten zu manipulieren.
Gruß
Doming
#57
Formular / Re: Filterung beim Öffnen eine...
Letzter Beitrag von Christian72 - Juli 20, 2026, 09:42:47Guten Morgen Christian,
besten Dank!
Christian
besten Dank!
Christian
#58
Formular / Re: Filterung beim Öffnen eine...
Letzter Beitrag von Bitsqueezer - Juli 17, 2026, 15:19:05Hallo,
ja klar, an einer Stelle genügt es.
Das Makro wäre wohl die passende Stelle (obwohl ich empfehlen würde, alle Makros durch VBA abzulösen).
Ob das Makro generell den Filter in die Filtereigenschaften schreibt, weiß ich nicht, vermute aber ja.
Der Filter bleibt aber auch bei Verwendung von VBA gerne schon mal in der Eigenschaft stehen. Passiert, wenn man z.B. mit STRG-S das Formular selbst speichert, was vor allem während der Entwicklung gerne schon mal passiert.
Passiert auch, wenn man DoCmd.Close verwendet und den Save-Parameter angibt (der nicht den aktuellen Datensatz speichert, sondern das Formular...).
Kannst Du da löschen und wieder speichern.
Ist aber kein Garant, daß es nicht wieder passiert. Kannst Du aber ignorieren, da Dein Makro den Wert in jedem Fall neu setzt.
Es wird so oder so nur einmal gefiltert, selbst wenn Du den Filter 2x setzt. Ist dann ja identisch und da gibt es nichts Neues zu filtern.
Gruß
Christian
ja klar, an einer Stelle genügt es.
Das Makro wäre wohl die passende Stelle (obwohl ich empfehlen würde, alle Makros durch VBA abzulösen).
Ob das Makro generell den Filter in die Filtereigenschaften schreibt, weiß ich nicht, vermute aber ja.
Der Filter bleibt aber auch bei Verwendung von VBA gerne schon mal in der Eigenschaft stehen. Passiert, wenn man z.B. mit STRG-S das Formular selbst speichert, was vor allem während der Entwicklung gerne schon mal passiert.
Passiert auch, wenn man DoCmd.Close verwendet und den Save-Parameter angibt (der nicht den aktuellen Datensatz speichert, sondern das Formular...).
Kannst Du da löschen und wieder speichern.
Ist aber kein Garant, daß es nicht wieder passiert. Kannst Du aber ignorieren, da Dein Makro den Wert in jedem Fall neu setzt.
Es wird so oder so nur einmal gefiltert, selbst wenn Du den Filter 2x setzt. Ist dann ja identisch und da gibt es nichts Neues zu filtern.
Gruß
Christian
#59
Formular / Filterung beim Öffnen eines Fo...
Letzter Beitrag von Christian72 - Juli 17, 2026, 12:50:13Guten Tag,
es gibt mal wieder ein Problem:
- Formular "07- Abfrage Ort-Firma-Bestellung-Rechnung" => Dort sind alle Kunden aufgelistet.
(Es ist anders als der Name vermuten lässt, keine Abfrage sondern ein Formular, und der Name an sich ist auch schrecklich. Vom Vorbesitzer "geerbt". Die Namen (nicht nur dieses Formulars) ist eines der vielen Dinge, die noch zu tun ist.)
- Es gibt dort einen Button, nach dessen Betätigung sich das Formular "2021-Eingabe-Firma4" öffnet (siehe: Anhang "Makro").
Dort kann (unter anderem) eine neue Angebotsnummer für den jeweiligen Kunden erzeugt werden.
In dem zweiten Formular "2021-Eingabe-Firma4" soll es nur um den vorher angewählten Kunden gehen.
Dazu gibt es im Makro (siehe: Anhang 1) ja die Bedingung.
Im Formular "2021-Eingabe-Firma4" gibt es einen Filter (siehe: Anhang 2), der meiner Meinung nach die gleiche Filterung bewirkt wie die Bedingung im Makro.
Frage:
- Ist das nicht doppelt gefiltert?
- Reicht nicht die Filterung an einer Stelle aus bzw. ist ev. sogar besser?
Vielen Dank vorab
Christian
es gibt mal wieder ein Problem:
- Formular "07- Abfrage Ort-Firma-Bestellung-Rechnung" => Dort sind alle Kunden aufgelistet.
(Es ist anders als der Name vermuten lässt, keine Abfrage sondern ein Formular, und der Name an sich ist auch schrecklich. Vom Vorbesitzer "geerbt". Die Namen (nicht nur dieses Formulars) ist eines der vielen Dinge, die noch zu tun ist.)
- Es gibt dort einen Button, nach dessen Betätigung sich das Formular "2021-Eingabe-Firma4" öffnet (siehe: Anhang "Makro").
Dort kann (unter anderem) eine neue Angebotsnummer für den jeweiligen Kunden erzeugt werden.
In dem zweiten Formular "2021-Eingabe-Firma4" soll es nur um den vorher angewählten Kunden gehen.
Dazu gibt es im Makro (siehe: Anhang 1) ja die Bedingung.
Im Formular "2021-Eingabe-Firma4" gibt es einen Filter (siehe: Anhang 2), der meiner Meinung nach die gleiche Filterung bewirkt wie die Bedingung im Makro.
Frage:
- Ist das nicht doppelt gefiltert?
- Reicht nicht die Filterung an einer Stelle aus bzw. ist ev. sogar besser?
Vielen Dank vorab
Christian
#60
Access-Hilfe / Re: Datenbank für Container
Letzter Beitrag von Doming - Juli 17, 2026, 07:07:04Hallo,
wieviel hast Du schon mit relationalen Datenbanken gearbeitet? Access ist ist eine andere Denke als Excel. Man füttert die Tabellen mit den Daten und der Istzustand wird dann durch Abfragen abgebildet.
Eine empfehlenswerte Seite ist in diesem Zusammenhang https://www.access-tutorial.de/
Wenn Du in Excel die Adresse Deines Kunden änderst, sind die vorherigen Daten weg (je nach getriebenem Aufwand). In Access kommt ein neuer Datensatz hinzu und man kann auch später noch die Adresse vom Zeitpunkt X abfragen.
Wie gesagt, in dem Fall der Bewegungstabelle könnte man das Gewicht auch dem Datensatz mit der Leerung zuordnen, gerade wenn es sicher ist, dass pro Container nur ein Material angeliefert wird.
Im Gegensatz zu Excel sollte der Anwender in Access normalerweise keine Tabelle zu Gesicht bekommen, denn gerade die m:n-Tabellen haben in ihren Feldern (Spalten) normalerweise keine sichtbaren Infos, sondern nur Zahlen. Dort werden nur die Datensatzschlüssel der Grundtabellen miteinander verknüpft.
Gruß
Doming
wieviel hast Du schon mit relationalen Datenbanken gearbeitet? Access ist ist eine andere Denke als Excel. Man füttert die Tabellen mit den Daten und der Istzustand wird dann durch Abfragen abgebildet.
Eine empfehlenswerte Seite ist in diesem Zusammenhang https://www.access-tutorial.de/
Wenn Du in Excel die Adresse Deines Kunden änderst, sind die vorherigen Daten weg (je nach getriebenem Aufwand). In Access kommt ein neuer Datensatz hinzu und man kann auch später noch die Adresse vom Zeitpunkt X abfragen.
Wie gesagt, in dem Fall der Bewegungstabelle könnte man das Gewicht auch dem Datensatz mit der Leerung zuordnen, gerade wenn es sicher ist, dass pro Container nur ein Material angeliefert wird.
Im Gegensatz zu Excel sollte der Anwender in Access normalerweise keine Tabelle zu Gesicht bekommen, denn gerade die m:n-Tabellen haben in ihren Feldern (Spalten) normalerweise keine sichtbaren Infos, sondern nur Zahlen. Dort werden nur die Datensatzschlüssel der Grundtabellen miteinander verknüpft.
Gruß
Doming