- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#41
Access Programmierung / Re: Access Datenbank speichern
Letzter Beitrag von Bitsqueezer - März 16, 2026, 12:28:41Hallo,
für jeden User einen Ordner auf einem Server ist auch eine durchaus gute Praxis, macht man vor allem so, wenn man die User per Terminal Server Access als RemoteApp starten läßt.
ACCDE: Kann nur erstellt werden, wenn es beim Kompilieren in VBA keine Fehler gab. Wie gesagt, in JEDES Modul oben "Option Explicit" einfügen (wenn nicht schon da) und dann den Code kompilieren. Erst wenn das ohne Fehler funktioniert (was nicht gleichbedeutend ist mit "der Code ist fehlerfrei"...), kannst Du eine ACCDE daraus erstellen.
Bitte berücksichtigen, daß überall Fehler abgefangen werden in VBA, denn da mit ACCDE nicht in den Code verzweigt werden kann, wenn es zu einem nicht angefangenen Fehler kommt, "hängt" die Anwendung dann.
Gruß
Christian
für jeden User einen Ordner auf einem Server ist auch eine durchaus gute Praxis, macht man vor allem so, wenn man die User per Terminal Server Access als RemoteApp starten läßt.
ACCDE: Kann nur erstellt werden, wenn es beim Kompilieren in VBA keine Fehler gab. Wie gesagt, in JEDES Modul oben "Option Explicit" einfügen (wenn nicht schon da) und dann den Code kompilieren. Erst wenn das ohne Fehler funktioniert (was nicht gleichbedeutend ist mit "der Code ist fehlerfrei"...), kannst Du eine ACCDE daraus erstellen.
Bitte berücksichtigen, daß überall Fehler abgefangen werden in VBA, denn da mit ACCDE nicht in den Code verzweigt werden kann, wenn es zu einem nicht angefangenen Fehler kommt, "hängt" die Anwendung dann.
Gruß
Christian
#42
Access Programmierung / Re: Access Datenbank speichern
Letzter Beitrag von Doming - März 16, 2026, 12:12:47Zitat von: LehmeMa am März 16, 2026, 12:01:37Meine bisherige Lösung war: für jeden Nutzer habe ich eine eigene Kopie des FE auf dem Server.
So musst Du bei einer SW-Änderung also mehrere FEs kopieren, bei meiner Lösung gibt es nur ein FE, welches jeder Nutzer beim Start auf seinen Rechner kopiert. Die Quelldatei wird also nur readonly gelesen und kann jederzeit überschrieben werden, auch wenn der Nutzer aktiv ist.
#43
Access Programmierung / Re: Access Datenbank speichern
Letzter Beitrag von LehmeMa - März 16, 2026, 12:01:37Hallo zusammen,
Danke für die vielen Antworten.
@Werner: #4 funktioniert wunderbar
@klaus: ich möchte ja auch nur das FE kopieren. Die DB bleibt dadurch ja hoffentlich unberührt.
Meine bisherige Lösung war: für jeden Nutzer habe ich eine eigene Kopie des FE auf dem Server.
So kann ich jederzeit die Dateien aktualisieren, solange der Nutzer nicht aktiv ist.
Jeder hat nur einen Link zu "seinem" Frontend auf dem Rechner. Weiterer Vorteil: Ist der Nutzer offline (Aussendienst) öffnet sich schon kein FE mit fehlendem BE ;-)
Der Lösungsvorschlag von Doming mit der Batch-Datei klingt auch gut (Risiko: s.o.)
Die Lösung von Christian kling am "proffessionellsten".
Leider bekomme ich die Meldung: "Microsoft Access konnte keine ACCDE-, MDE- oder ADE-Datei erstellen.
Gruß Markus
Danke für die vielen Antworten.
@Werner: #4 funktioniert wunderbar
@klaus: ich möchte ja auch nur das FE kopieren. Die DB bleibt dadurch ja hoffentlich unberührt.
Meine bisherige Lösung war: für jeden Nutzer habe ich eine eigene Kopie des FE auf dem Server.
So kann ich jederzeit die Dateien aktualisieren, solange der Nutzer nicht aktiv ist.
Jeder hat nur einen Link zu "seinem" Frontend auf dem Rechner. Weiterer Vorteil: Ist der Nutzer offline (Aussendienst) öffnet sich schon kein FE mit fehlendem BE ;-)
Der Lösungsvorschlag von Doming mit der Batch-Datei klingt auch gut (Risiko: s.o.)
Die Lösung von Christian kling am "proffessionellsten".
Leider bekomme ich die Meldung: "Microsoft Access konnte keine ACCDE-, MDE- oder ADE-Datei erstellen.
Gruß Markus
#44
Formular / Re: Endlosformular Popup
Letzter Beitrag von Stele4 - März 16, 2026, 08:48:34Guten Morgen!
Das Formular laesst sich zur Laufzeit mit der Mouse nicht vergroessern.
Bei den Parametern habe ich nichts entdeckt, was dies verhindert.
Der Tipp mit "DoCmd.MoveSize" war hilfreich.
Access ist hier wieder einmal sonderbar.
Der Code "Me.Detail.Height=..." ist wirkungslos.
Bei "DoCmd.MoveSize" koennen keine benannten Parameter angewendet werden.
Die Berechnung der Hoehe aus den Einzelmassen und der Anzahl der Satensaetze funktioniert auch nicht annaehernd korrekt.
Selbst wenn man die Hoehen von Kopf und Fuss des Windows-Fensters beruecksichtigt.
Bei meiner Anwendung sind es normalerweise 8 oder 16 Datensaetze. Die beiden Hoehen des Formulars lassen sich empirisch ermitteln. Fuer alles andere ist der Scroll-Balken ok.
Gruss und Dank!
Das Formular laesst sich zur Laufzeit mit der Mouse nicht vergroessern.
Bei den Parametern habe ich nichts entdeckt, was dies verhindert.
Der Tipp mit "DoCmd.MoveSize" war hilfreich.
Access ist hier wieder einmal sonderbar.
Der Code "Me.Detail.Height=..." ist wirkungslos.
Bei "DoCmd.MoveSize" koennen keine benannten Parameter angewendet werden.
Die Berechnung der Hoehe aus den Einzelmassen und der Anzahl der Satensaetze funktioniert auch nicht annaehernd korrekt.
Selbst wenn man die Hoehen von Kopf und Fuss des Windows-Fensters beruecksichtigt.
Bei meiner Anwendung sind es normalerweise 8 oder 16 Datensaetze. Die beiden Hoehen des Formulars lassen sich empirisch ermitteln. Fuer alles andere ist der Scroll-Balken ok.
Gruss und Dank!
Code [Auswählen]
With Me
Set .Recordset = mdlx_SqlSrv.fcSqlRst(sSql:="EXEC spIoSltCnf @SltId = " & .OpenArgs)
DoCmd.MoveSize , , , .FormHeader.Height + .FormFooter.Height + .Recordset.RecordCount * 500
'Twip (1 twip = 1/20 point, 1440 twips ~ 1 inch, 567 twips ~ 1 cm)
'#nicht korrektes Ergebnis: DoCmd.MoveSize , , , .FormHeader.Height
+ .FormFooter.Height
+ .Recordset.RecordCount * .txtId.Height
'#funktioniert nicht: DoCmd.MoveSize Heigth:=.Recordset.RecordCount * 200
'#funktioniert nicht: .Detail.Height = .Recordset.RecordCount * 1000
End With #45
Access Programmierung / Re: Access Datenbank speichern
Letzter Beitrag von Doming - März 16, 2026, 06:21:45Zitat von: LehmeMa am März 13, 2026, 09:56:00ich möchte die Datenbank als "Frontend" an die Mitarbeiter verteilen.
Moin Markus,
ich habe sehr gute Erfahrungen mit dieser Vorgehensweise gemacht:
1. FrontEnd in einem Netzlaufwerk ablegen (kryptischer Name, damit nicht irgendwelche Spezis eine Verknüpfung erstellen)
2. Batch-Datei erstellen
Minimalausführung wäre
Code [Auswählen]
if not exist c:\DBName md c:\DBName
copy netzlaufwerkbuchstabe:\kryptischerFrontEndname.accdb c:\DBName\DBName.accdb
start c:\DBName\DBName.accdbDas kann man natürlich auch noch ausschmücken3. eine Verknüpfung auf diese Batchdatei erstellen
Dort kann man auch das Symbol der Datenbank als Symbol der Verknüpfung einstellen
Name der Verknüpfung: "DatenbankName - Installer"
4. Den Usern diesen Link zur Verfügung stellen
Das hat den Effekt, dass man auch während der Betriebszeiten Änderungen am FrontEnd durchführen kann, ohne dass die Nutzer etwas davon mitbekommen. Bei jedem Neustart des FrontEnds bekommt der Nutzer die aktuellste Version.
Da bei uns viele Nutzer mit Verknüpfungen auf dem Desktop arbeiten, habe ich die Batch so geschrieben, dass sie eine Kopie von sich selbst auf dem Desktop des Nutzers anlegen, dann ohne den "-Installer" am Ende.
Gruß
Doming
#46
Microsoft Excel / Re: Update einspielen
Letzter Beitrag von Blaupunkt79 - März 15, 2026, 20:21:27OK, dann lag ich doch nicht so verkehrt.
Mit "Prozess" steuere ich, ob das Tool die Workbook_open Methode durchläuft, bei 87 wird diese unterbrochen. Klar, dazu fehlen Dir wertvolle Informationen.
Version A und Version B unterscheiden sich darin, dass bei Version B teilweise der Code optimiert wurde oder Userformen hinzugekommen sind, also eher weniger Formeln, ist halt eine Weiterentwicklung von Version A. Ich habe es jetzt so gelöst, dass der Benutzer nach erfolgtem Update das Tool schließen und neu starten muss. Beim Neustart wiederum wird die Workbook_open Methode durchlaufen ("Prozess" sozusagen 0) und da wird geprüft, ob eine .bak Datei vorhanden ist und entsprechend gelöscht.
Den Tip mit "FSO" werde ich im Tool durch meine DIR() Methode sukzessive ersetzen.
Danke Dir!
Mit "Prozess" steuere ich, ob das Tool die Workbook_open Methode durchläuft, bei 87 wird diese unterbrochen. Klar, dazu fehlen Dir wertvolle Informationen.
Version A und Version B unterscheiden sich darin, dass bei Version B teilweise der Code optimiert wurde oder Userformen hinzugekommen sind, also eher weniger Formeln, ist halt eine Weiterentwicklung von Version A. Ich habe es jetzt so gelöst, dass der Benutzer nach erfolgtem Update das Tool schließen und neu starten muss. Beim Neustart wiederum wird die Workbook_open Methode durchlaufen ("Prozess" sozusagen 0) und da wird geprüft, ob eine .bak Datei vorhanden ist und entsprechend gelöscht.
Den Tip mit "FSO" werde ich im Tool durch meine DIR() Methode sukzessive ersetzen.
Danke Dir!
#47
Formular / Re: Kombifelder leeren
Letzter Beitrag von Bitsqueezer - März 15, 2026, 18:21:24Hallo,
zu den Namenskonventionen:
Das unterscheidet "allgemeine Programmierer" von DB-Designern. Ja, in der Programmierung haben die Prefixe bei Variablen und bisweilen auch bei Objekten ihre Berechtigung und helfen, den Überblick nicht zu verlieren bzw. dauernd in der Deklaration nachschlagen zu müssen, um was für einen Datentyp es sich gerade handelt.
Im Datenbankdesign ist ein Typenprefix leider völlig unangebracht. Es klingt erst mal wie eine gute Idee, mit dem gleichen Hintergrund, aber im DB-Design muß man nicht gerade selten einen Datentypen für ein Feld auch mal anpassen, was selbst in der allgemeinen Programmierung dann Aufwand bedeutet, hier aber meist mit Find/Replace halbwegs schnell erledigt ist (oder wenn man so tolle Tools wie VSCode mit F2 hat, der die Umebenennung dann selbst vornimmt).
Im Datenbankdesign muß man dann jedoch eine ganze Kaskade von Dingen an unterschiedlichster Stelle ändern. Den Feldnamen, Indexnamen, Views bzw. Abfragen, wenn das Backend ein DB-Server ist, das ganze dann auch noch in Abfragen auf Backend-Tabellen, dann muß man die Controls in Formularen anpassen, Sortiereinstellungen, Abfragen im Code, Recordsets mit Bezug auf Feldnamen, usw.
Das ist erheblicher Arbeitsaufwand, den man sich dann meistens erspart und im Ergebnis hat man dann "lngArtikelnummer", aber der Datentyp wurde längst in Text geändert, was dann völliges Benennungschaos ist. Daher lieber früher als später Datentyp-Prefixe entfernen.
Umgekehrt ist es durchaus sinnvoll, den Objekten selbst einen Prefix voranzustellen wie "tbl" für Tabellen, "qry" für Abfragen, "frm" für Formulare usw. Eine Tabelle wird immer eine Tabelle sein und eine Abfrage immer eine Abfrage. Damit kann man in Objektübersichten schnell den Überblick behalten, um welches Objekt es gerade geht. Denn so manche ODBC- oder OLE-Verbindungstools listen Dir alle Objekte alphabetisch, nicht nach Objekttyp und dann sieht man nicht, ob man eine Tabelle oder View verbindet - usw.
Was Beziehungen angeht: Ja, sie sind nicht "zwingend", eine Datenbank funktioniert auch ohne Beziehungen. Aber man verschenkt einen Großteil wichtiger Funktionalität, nämlich vor allem der referentiellen Integrität, bei der die Datenbank ohne eigene Programmierung selbst überprüft und sicherstellt, daß es zu einem Foreign Key auch einen Primary Key gibt bei einer 1:N-Verbindung. Umgekehrt kann man Cascading Deletes verwenden, um sich Löscharbeit zu sparen, wenn man z.B. wie in Deinem Fall "VokabelInLektion" (m:n) die Daten aus der Zwischentabelle automatisch löschen lassen will. Man löscht eine Vokabel, dann ist diese Vokabel in keiner Lektion mehr. Man löscht eine Lektion, dann kommt die Lektion für keine Vokabel mehr vor.
Ohne Beziehung muß man die "Datenleichen" selbst entsorgen.
Also warum auf Komfort und Sicherheit verzichten?
Nebenbei hat es den Vorteil, daß Du Beziehungen in Abfragen automatisch eingestellt bekommst, wenn Access die Referenzen bereits selbst kennt. Das muß nicht immer passen, aber i.d.R. paßt es.
Übrigens kann man mit dem Beziehungseditor in Access (leider) auch Abfrage-Beziehungen erstellen, was maximal verwirrend ist und in einem Beziehungsfenster eigentlich nichts verloren hat. Am besten nicht machen. Abfragebeziehungen gehören in SQL bzw. dem Abfragedesigner.
Filter kannst Du im Code mit "Me.Filter" einstellen und mit "Me.FilterOn" ein- und ausschalten. Geht auch mit "Me.OrderBy" und "Me.OrderByOn".
Gruß
Christian
zu den Namenskonventionen:
Das unterscheidet "allgemeine Programmierer" von DB-Designern. Ja, in der Programmierung haben die Prefixe bei Variablen und bisweilen auch bei Objekten ihre Berechtigung und helfen, den Überblick nicht zu verlieren bzw. dauernd in der Deklaration nachschlagen zu müssen, um was für einen Datentyp es sich gerade handelt.
Im Datenbankdesign ist ein Typenprefix leider völlig unangebracht. Es klingt erst mal wie eine gute Idee, mit dem gleichen Hintergrund, aber im DB-Design muß man nicht gerade selten einen Datentypen für ein Feld auch mal anpassen, was selbst in der allgemeinen Programmierung dann Aufwand bedeutet, hier aber meist mit Find/Replace halbwegs schnell erledigt ist (oder wenn man so tolle Tools wie VSCode mit F2 hat, der die Umebenennung dann selbst vornimmt).
Im Datenbankdesign muß man dann jedoch eine ganze Kaskade von Dingen an unterschiedlichster Stelle ändern. Den Feldnamen, Indexnamen, Views bzw. Abfragen, wenn das Backend ein DB-Server ist, das ganze dann auch noch in Abfragen auf Backend-Tabellen, dann muß man die Controls in Formularen anpassen, Sortiereinstellungen, Abfragen im Code, Recordsets mit Bezug auf Feldnamen, usw.
Das ist erheblicher Arbeitsaufwand, den man sich dann meistens erspart und im Ergebnis hat man dann "lngArtikelnummer", aber der Datentyp wurde längst in Text geändert, was dann völliges Benennungschaos ist. Daher lieber früher als später Datentyp-Prefixe entfernen.
Umgekehrt ist es durchaus sinnvoll, den Objekten selbst einen Prefix voranzustellen wie "tbl" für Tabellen, "qry" für Abfragen, "frm" für Formulare usw. Eine Tabelle wird immer eine Tabelle sein und eine Abfrage immer eine Abfrage. Damit kann man in Objektübersichten schnell den Überblick behalten, um welches Objekt es gerade geht. Denn so manche ODBC- oder OLE-Verbindungstools listen Dir alle Objekte alphabetisch, nicht nach Objekttyp und dann sieht man nicht, ob man eine Tabelle oder View verbindet - usw.
Was Beziehungen angeht: Ja, sie sind nicht "zwingend", eine Datenbank funktioniert auch ohne Beziehungen. Aber man verschenkt einen Großteil wichtiger Funktionalität, nämlich vor allem der referentiellen Integrität, bei der die Datenbank ohne eigene Programmierung selbst überprüft und sicherstellt, daß es zu einem Foreign Key auch einen Primary Key gibt bei einer 1:N-Verbindung. Umgekehrt kann man Cascading Deletes verwenden, um sich Löscharbeit zu sparen, wenn man z.B. wie in Deinem Fall "VokabelInLektion" (m:n) die Daten aus der Zwischentabelle automatisch löschen lassen will. Man löscht eine Vokabel, dann ist diese Vokabel in keiner Lektion mehr. Man löscht eine Lektion, dann kommt die Lektion für keine Vokabel mehr vor.
Ohne Beziehung muß man die "Datenleichen" selbst entsorgen.
Also warum auf Komfort und Sicherheit verzichten?
Nebenbei hat es den Vorteil, daß Du Beziehungen in Abfragen automatisch eingestellt bekommst, wenn Access die Referenzen bereits selbst kennt. Das muß nicht immer passen, aber i.d.R. paßt es.
Übrigens kann man mit dem Beziehungseditor in Access (leider) auch Abfrage-Beziehungen erstellen, was maximal verwirrend ist und in einem Beziehungsfenster eigentlich nichts verloren hat. Am besten nicht machen. Abfragebeziehungen gehören in SQL bzw. dem Abfragedesigner.
Filter kannst Du im Code mit "Me.Filter" einstellen und mit "Me.FilterOn" ein- und ausschalten. Geht auch mit "Me.OrderBy" und "Me.OrderByOn".
Gruß
Christian
#48
Tabelle/Abfrage / Re: Aktualisierungsabfrage
Letzter Beitrag von Pädda - März 15, 2026, 18:02:45Uff: Problem gelöst mit folgenden Regeln:
+Man spricht Englisch bei SQL
+Keine Hochkommata beim Stringbau (in diesem Fall gings plötzlich ohne alle)
+Der Standardwert des ID-Feldes ,,IDDoppelfacts" darf nicht 1 sein, wenn nur 1 Datensatz existiert, sondern 0!
+Man sollte Tippfehler vermeiden
+Der funktionierende Befehl lautet:
strSQL = "UPDATE tblDoppelFacts SET " & stFeld & " = " & stYesno & " WHERE (((tblDoppelFacts.[IDDoppelFacts])= 1));"
Danke an alle die mitgeholfen haben!!"
+Man spricht Englisch bei SQL
+Keine Hochkommata beim Stringbau (in diesem Fall gings plötzlich ohne alle)
+Der Standardwert des ID-Feldes ,,IDDoppelfacts" darf nicht 1 sein, wenn nur 1 Datensatz existiert, sondern 0!
+Man sollte Tippfehler vermeiden
+Der funktionierende Befehl lautet:
strSQL = "UPDATE tblDoppelFacts SET " & stFeld & " = " & stYesno & " WHERE (((tblDoppelFacts.[IDDoppelFacts])= 1));"
Danke an alle die mitgeholfen haben!!"
#49
Formular / Re: Kombifelder leeren
Letzter Beitrag von Cherry Brandy - März 15, 2026, 17:19:35Entschuldigung an alle, die hier noch mitlesen: Die ursprüngliche Frage ist bereits abschließend beantwortet. Der folgende Text bzw. die vorige Frage sind eher allgemeiner Art und offtopic.
@ Knobbi38 :
Auf genau solche Tipps hatte ich gehofft, die helfen mir, mich weiter zu entwickeln. Vielen Dank an Dich und Bitsqueezer.
Zu Namenskonventionen gibt es – obwohl es ja eigentlich Konventionen sein sollten – offensichtlich doch eine ganze Menge unterschiedliche Ansätze und Meinungen. Ein Kollege aus dem IT-Team meiner Abteilung (ein ,,allgemeiner" Programmierer) hat mich vor einiger Zeit darauf ,,gedrillt", genau diese Konvention zu benutzen.
Unterstriche habe ich früher auch nicht verwendet, ich muss jedoch zugeben, dass sie es beim schnellen Drübergucken für das Auge einfacher machen, den Inhalt zu erfassen.
Da habe ich mich in meinen Datenbanken über die Jahre durch unterschiedliche Ansätze gearbeitet: teilweise habe ich DB, in denen bereits auf Tabellenebene die Verknüpfungen stimmen, in der letzten Zeit eher nicht. Die Beziehungen lege ich in den Abfragen bzw. in der Datensatzherkunft an. Der Ansatz ist nach dem Motto ,,was nicht zwingend erforderlich ist, bleibt erst mal weg". Und ja, ich hatte schon den Verdacht, dass mir das irgendwann mal um die Ohren fliegt.
Vermutlich hatte ich mich da zu unklar ausgedrückt: ich wollte lediglich ein Kombifeld in VBA, in dem nach der Suche kein ,,alter" Wert mehr angezeigt wird. Den Unterschied Docmd und Recordset werde ich mir mal genauer ansehen.
Auch die Benutzung von Funktionen/Prozeduren werde ich mir intensiver ansehen. Hinweise auf "best practice" sind absolut wichtig und hilfreich (Habt Ihr schon meine neue Signatur gesehen?
).
Falls es Dich bzw. einen Mitleser interessiert: Tatsächlich IST das eine DB, die ich vor über 10 Jahren zum Chinesischlernen geschrieben habe und die ich nun um Japanisch erweitere. 😉
Beide Sprachen teilen einige ihrer Schriftzeichen, allerdings mit völlig unterschiedlicher Aussprache und z.T. Bedeutung. Das Problem mehrerer möglicher Übersetzungen kann man praktisch vernachlässigen. Sowohl chinesisch als, soweit ich das nach einem knappen halben Lernjahr beurteilen kann, in fast noch größerem Maße auch japanisch haben eine extrem große Menge an Homonymen (gleichklingende Worte). Allerdings hat jeder inhaltliche Begriff ein anderes Schriftzeichen, so dass man sie im Gegensatz zu westlichen Sprachen im geschriebenen Text hervorragend auseinanderhalten kann.
@ Knobbi38 :
Auf genau solche Tipps hatte ich gehofft, die helfen mir, mich weiter zu entwickeln. Vielen Dank an Dich und Bitsqueezer.
Zitat von: Knobbi38 am März 15, 2026, 09:32:16Zu deiner Namenskonvention würde ich vorschlagen, keine Präfixe für Datentypen zu verwenden, dass ist hinderlich und unüblich. Lediglich Fremdschlüssen sollten zur besseren Lesbarkeit gekennzeichnet werden; meistens wird dafür ein "F" verwendet. Unterstriche spare ich mir einfach, aber das ist Geschmackssache.
Zu Namenskonventionen gibt es – obwohl es ja eigentlich Konventionen sein sollten – offensichtlich doch eine ganze Menge unterschiedliche Ansätze und Meinungen. Ein Kollege aus dem IT-Team meiner Abteilung (ein ,,allgemeiner" Programmierer) hat mich vor einiger Zeit darauf ,,gedrillt", genau diese Konvention zu benutzen.
Unterstriche habe ich früher auch nicht verwendet, ich muss jedoch zugeben, dass sie es beim schnellen Drübergucken für das Auge einfacher machen, den Inhalt zu erfassen.
Zitat von: Knobbi38 am März 15, 2026, 09:32:16Was jedoch noch fehlt, sind die Tabellenbeziehungen, damit die referentielle Integrität auch gewährleistet wird.
Da habe ich mich in meinen Datenbanken über die Jahre durch unterschiedliche Ansätze gearbeitet: teilweise habe ich DB, in denen bereits auf Tabellenebene die Verknüpfungen stimmen, in der letzten Zeit eher nicht. Die Beziehungen lege ich in den Abfragen bzw. in der Datensatzherkunft an. Der Ansatz ist nach dem Motto ,,was nicht zwingend erforderlich ist, bleibt erst mal weg". Und ja, ich hatte schon den Verdacht, dass mir das irgendwann mal um die Ohren fliegt.
Zitat von: Knobbi38 am März 15, 2026, 09:32:16Deine Ereignisprozeduren verstehe ich nicht, weil du doch als Vorgabe hattest, andere Suchen zu löschen. Auch solltest du nicht mit Docmd suchen, sondern in VBA mit Recordset.FindFirst (Beispiele in der Hilfe).
Vermutlich hatte ich mich da zu unklar ausgedrückt: ich wollte lediglich ein Kombifeld in VBA, in dem nach der Suche kein ,,alter" Wert mehr angezeigt wird. Den Unterschied Docmd und Recordset werde ich mir mal genauer ansehen.
Zitat von: Knobbi38 am März 15, 2026, 09:32:16Bei annähernd gleichen Code solltest du den gleichen Code in eine Funktion oder Prozedur auslagern, das gehört zur "best practice".
Auch die Benutzung von Funktionen/Prozeduren werde ich mir intensiver ansehen. Hinweise auf "best practice" sind absolut wichtig und hilfreich (Habt Ihr schon meine neue Signatur gesehen?
).Zitat von: Knobbi38 am März 15, 2026, 09:32:16als Beispiel, warum eine Normalisierung von tblVokabeln durchgeführt werden sollte, wäre eine Erweiterung um eine weitere Sprache. Hierfür müsste die Tabelle geändert werden. Auch gibt es mit der Tabelle Probleme, falls es mehrere mögliche Übersetzungen geben könnte. Das wäre so auch nicht darstellbar
Falls es Dich bzw. einen Mitleser interessiert: Tatsächlich IST das eine DB, die ich vor über 10 Jahren zum Chinesischlernen geschrieben habe und die ich nun um Japanisch erweitere. 😉
Beide Sprachen teilen einige ihrer Schriftzeichen, allerdings mit völlig unterschiedlicher Aussprache und z.T. Bedeutung. Das Problem mehrerer möglicher Übersetzungen kann man praktisch vernachlässigen. Sowohl chinesisch als, soweit ich das nach einem knappen halben Lernjahr beurteilen kann, in fast noch größerem Maße auch japanisch haben eine extrem große Menge an Homonymen (gleichklingende Worte). Allerdings hat jeder inhaltliche Begriff ein anderes Schriftzeichen, so dass man sie im Gegensatz zu westlichen Sprachen im geschriebenen Text hervorragend auseinanderhalten kann.
#50
Microsoft Excel / Re: Update einspielen
Letzter Beitrag von Knobbi38 - März 15, 2026, 16:54:46Hallo,
es wird allmählich, aber da liegt noch ein Missverständnis vor.
Die Prozedur ProzessUpdate() in VersionB ist nicht für solche Aktionen gedacht, sondern die gehören noch in VersionA! ProzessUpdate() wird verwendet, um Datenstrukturen, Formeln usw. von der alten VersionA an die neue VersionB bei der Übernahme anzupassen.
Beispiel:
In VersionA wird auf einen bestimmten Etikettendrucker gedruckt, welcher nur an diesem Computer verwendet wird. Andere Computer verwenden andere Etikettendrucker. Die Information sei in einem Konfigurationtabelle oder bei den CustomProperties hinterlegt. VersionB weiß davon natürlich nichts, weil das Update ja für alle Computer gelten soll. Dafür kann dann Prozessupdate() verwendet werden. Die individuelle Konfiguration jedes Computers könnte in ProzessUpdate dann z.B. von VersionA nach VersionB übernommen werden und VersionB kann damit VersionA ersetzen.
Es gibt gute Gründe, die alte Backup-Datei zu behalten. Wenn das Update doch nicht wie geplant funktioniert, kann wenigstens wieder auf die vorherige Version zurückgegriffen werden. Ich würde die BAK-Datei erst löschen, wenn das nächste Update sie erkennt – erst dann wird sie offensichtlich nicht mehr benötigt.
Damit wäre dann auch das Problem gelöst, dass man sich nicht selber "den Boden unter den Füßen wegziehen" kann, was du ja eigentlich vor hast und was natürlich nicht funktionieren kann. So etwas geht in diesem Rahmen nicht, sondern nur über eine externe Anwendung, z.B. ein Powershell-Script.
Zum Code:
Knobbi38
es wird allmählich, aber da liegt noch ein Missverständnis vor.
Die Prozedur ProzessUpdate() in VersionB ist nicht für solche Aktionen gedacht, sondern die gehören noch in VersionA! ProzessUpdate() wird verwendet, um Datenstrukturen, Formeln usw. von der alten VersionA an die neue VersionB bei der Übernahme anzupassen.
Beispiel:
In VersionA wird auf einen bestimmten Etikettendrucker gedruckt, welcher nur an diesem Computer verwendet wird. Andere Computer verwenden andere Etikettendrucker. Die Information sei in einem Konfigurationtabelle oder bei den CustomProperties hinterlegt. VersionB weiß davon natürlich nichts, weil das Update ja für alle Computer gelten soll. Dafür kann dann Prozessupdate() verwendet werden. Die individuelle Konfiguration jedes Computers könnte in ProzessUpdate dann z.B. von VersionA nach VersionB übernommen werden und VersionB kann damit VersionA ersetzen.
Es gibt gute Gründe, die alte Backup-Datei zu behalten. Wenn das Update doch nicht wie geplant funktioniert, kann wenigstens wieder auf die vorherige Version zurückgegriffen werden. Ich würde die BAK-Datei erst löschen, wenn das nächste Update sie erkennt – erst dann wird sie offensichtlich nicht mehr benötigt.
Damit wäre dann auch das Problem gelöst, dass man sich nicht selber "den Boden unter den Füßen wegziehen" kann, was du ja eigentlich vor hast und was natürlich nicht funktionieren kann. So etwas geht in diesem Rahmen nicht, sondern nur über eine externe Anwendung, z.B. ein Powershell-Script.
Zum Code:
- "prozess = 87" verstehe ich nicht
- wenn du schon mit FSO arbeitest, solltest du auch das FSO verwenden, um auf FileExists zu prüfen. VBA.Dir() unterstützt nicht mehr alle Konstellationen!
Knobbi38