- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#51
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
#52
Microsoft Excel / Re: Update einspielen
Letzter Beitrag von Blaupunkt79 - März 15, 2026, 13:00:43Guten Morgen, ich habe mir Deine Beispieldatei nochmals angeschaut und in mein Tool eingebaut.
Der Benutzer befindet sich in Version A und startet von da aus das Update.
Das Tool läd sich die .upd Datei (Version B)
Anschließend wird Version A in .bak umbenannt, eine Textdatei geschrieben und Version B gestartet.
Nun übernimmt Version B den Code. Version B überspringt den Workbook.Open Ablauf (durch meine Textdatei) und springt direkt in "ProcessUpdate". Version B löscht nun die .upd Datei und die Textdatei.
Jetzt springt der Code wieder zurück auf Version A.
Im Ordner habe ich folglich noch Version A (.bak Datei) und Version B. Jetzt möchte ich gerne noch die .bak Datei löschen und stehe da vor dem Problem, dass wenn ich die Version A schließe, automatisch der Code still steht.
Verstehst Du, was ich machen möchte? Ich habe keine Idee, wie ich das umsetzen kann.
Die Zeilen nach "wkb.Close SaveChanges:=False" werden ignoriert.
Grüße
Der Benutzer befindet sich in Version A und startet von da aus das Update.
Das Tool läd sich die .upd Datei (Version B)
Code [Auswählen]
myFSO.copyfile "T:\Transfer TG\BL-Tool\Experiment\BLSCC_Master_DB_deutsch.xlsm" & ".upd", ActiveWorkbook.Path & "\BLSCC_Master_DB_deutsch.xlsm" & ".upd", True
Anschließend wird Version A in .bak umbenannt, eine Textdatei geschrieben und Version B gestartet.
Code [Auswählen]
'altes Tool umbenennen
Application.DisplayAlerts = False
prozess = 87
Set wkb = ActiveWorkbook
curFilename = ActiveWorkbook.FullName
wkb.SaveAs curFilename & ".bak"
'neues Tool öffnen
Set wbkTarget = Workbooks.Open(curFilename & ".upd")
wbkTarget.SaveAs curFilename
strMacroname = wbkTarget.name & "!ProcessUpdate"
Application.Run strMacroname
Nun übernimmt Version B den Code. Version B überspringt den Workbook.Open Ablauf (durch meine Textdatei) und springt direkt in "ProcessUpdate". Version B löscht nun die .upd Datei und die Textdatei.
Code [Auswählen]
Sub ProcessUpdate()
Call Text_lesen
If Dir(ActiveWorkbook.Path & "\BLSCC_Master_DB_deutsch.xlsm" & ".upd") <> "" Then Kill ActiveWorkbook.Path & "\BLSCC_Master_DB_deutsch.xlsm" & ".upd"
If Dir(ActiveWorkbook.Path & "\U_000001.txt") <> "" Then Kill ActiveWorkbook.Path & "\U_000001.txt"
MsgBox ("Update auf Version " & HH(1) & " erfolgreich abgeschlossen!")
prozess = 0
End Sub
Jetzt springt der Code wieder zurück auf Version A.
Im Ordner habe ich folglich noch Version A (.bak Datei) und Version B. Jetzt möchte ich gerne noch die .bak Datei löschen und stehe da vor dem Problem, dass wenn ich die Version A schließe, automatisch der Code still steht.
Verstehst Du, was ich machen möchte? Ich habe keine Idee, wie ich das umsetzen kann.
Code [Auswählen]
wkb.Close SaveChanges:=False
If Dir(ActiveWorkbook.Path & "\BLSCC_Master_DB_deutsch.xlsm" & ".bak") <> "" Then Kill ActiveWorkbook.Path & "\BLSCC_Master_DB_deutsch.xlsm" & ".bak"
Die Zeilen nach "wkb.Close SaveChanges:=False" werden ignoriert.
Grüße
#53
Tabelle/Abfrage / Re: Aktualisierungsabfrage
Letzter Beitrag von Beaker s.a. - März 15, 2026, 11:56:17Hallo,
Wie Ulrich schon sagte versteht SQL nur True/False. Die Ausdrücke
Yes/No bzw. Ja/Nein gibt es nur an der Oberfläche. Das kann man
irgendwo einstellen, - weiss aber nicht wo, da ich Boolean-Felder
nicht in Textfeldern anzeige.
gruss ekkehard
Wie Ulrich schon sagte versteht SQL nur True/False. Die Ausdrücke
Yes/No bzw. Ja/Nein gibt es nur an der Oberfläche. Das kann man
irgendwo einstellen, - weiss aber nicht wo, da ich Boolean-Felder
nicht in Textfeldern anzeige.
gruss ekkehard
#54
Formular / Re: Datenquelle für Navigation...
Letzter Beitrag von Beaker s.a. - März 15, 2026, 11:49:14Hallo Lars,
dem Navi-Form zu tun, aber die Bezüge sind die Gleichen.
gruss ekkehard
ZitatÜber die Eigenschaft Form des SubForm-Steuerelements kommst du dann an das geladene Formular heran und damit auch an dessen Recordsource.Dazu kannst du dir auch mal dieses anschauen. Hat zwar nicht direkt mit
dem Navi-Form zu tun, aber die Bezüge sind die Gleichen.
gruss ekkehard
#55
Formular / Re: Kombifelder leeren
Letzter Beitrag von Knobbi38 - März 15, 2026, 09:32:16Hallo,
als 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. Hier könnte man überlegen, ob es da nicht bessere Varianten gibt. Hier findest du ein paar Überlegungen zu dem Thema:
https://access-im-unternehmen.de/Mehrsprachige_Vokabeldatenbank/#:~:text=Tabelle%20der%20Wortarten.%20Die%20Tabelle%20tblWortarten%20enth%C3%A4lt,Prim%C3%A4rindexfeld%20Wort%2D%20artNr%20und%20dem%20Feld%20Wortart.
Zu 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.
Was jedoch noch fehlt, sind die Tabellenbeziehungen, damit die referentielle Integrität auch gewährleistet wird.
Kleine Anmerkung am Rande:
Anlagefelder werden eigentlich vermieden, weil die nicht kompatible sind, wenn man auf andere Backends umstellen möchte und die Datenbank nur aufblähen. I.d.R. werden Images nicht in der Datenbank gespeichert, sondern nur der Pfad mit dem Dateinamen zur Imagedatei.
Wenn du keine DS beim ersten Öffnen des Formulars anzeigen lassen möchtest, kannst du einen Filter aktivieren, dessen Bedingung nie erfüllt wird und dieses bei der ersten Auswahl per Kombobox deaktivieren.
Deine 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).
Bei annähernd gleichem Code solltest du den gleichen Code in eine Funktion oder Prozedur auslagern, das gehört zur "best practice".
Knobbi38
als 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. Hier könnte man überlegen, ob es da nicht bessere Varianten gibt. Hier findest du ein paar Überlegungen zu dem Thema:
https://access-im-unternehmen.de/Mehrsprachige_Vokabeldatenbank/#:~:text=Tabelle%20der%20Wortarten.%20Die%20Tabelle%20tblWortarten%20enth%C3%A4lt,Prim%C3%A4rindexfeld%20Wort%2D%20artNr%20und%20dem%20Feld%20Wortart.
Zu 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.
Was jedoch noch fehlt, sind die Tabellenbeziehungen, damit die referentielle Integrität auch gewährleistet wird.
Kleine Anmerkung am Rande:
Anlagefelder werden eigentlich vermieden, weil die nicht kompatible sind, wenn man auf andere Backends umstellen möchte und die Datenbank nur aufblähen. I.d.R. werden Images nicht in der Datenbank gespeichert, sondern nur der Pfad mit dem Dateinamen zur Imagedatei.
Wenn du keine DS beim ersten Öffnen des Formulars anzeigen lassen möchtest, kannst du einen Filter aktivieren, dessen Bedingung nie erfüllt wird und dieses bei der ersten Auswahl per Kombobox deaktivieren.
Deine 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).
Bei annähernd gleichem Code solltest du den gleichen Code in eine Funktion oder Prozedur auslagern, das gehört zur "best practice".
Knobbi38
#56
Formular / Re: Kombifelder leeren
Letzter Beitrag von Cherry Brandy - März 15, 2026, 03:47:34Funktioniert! 
Jetzt fehlt mir nur noch beim Öffnen des Formulares die Anzeige eines leeren Formulars statt des üblichen ersten Datensatzes.
Da finde ich im Moment leider nur Ansätze mit Filtern bei Formload. Bei meinen Versuchen bekomme ich den Filter dann anschließend aber nicht mehr "weg".
Falls Ihr dazu noch einen Tipp habt, in welcher Richtung ich suchen sollte...
gerne.
Code [Auswählen]
Private Sub cbo_PinyinWaehlen_AfterUpdate()
If Not IsNull(Me.cbo_PinyinWaehlen) Then
DoCmd.SearchForRecord , "", acFirst, "[ID_Vokabeln] = " & Str(Nz(Me.cbo_PinyinWaehlen, 0))
Me!cbo_PinyinWaehlen = Null
End If
End Sub
Private Sub cbo_DeutschWaehlen_AfterUpdate()
If Not IsNull(Me.cbo_DeutschWaehlen) Then
DoCmd.SearchForRecord , "", acFirst, "[ID_Vokabeln] = " & Str(Nz(Me.cbo_DeutschWaehlen, 0))
Me!cbo_DeutschWaehlen = Null
End If
End Sub
Private Sub cbo_ChinesischWaehlen_AfterUpdate()
If Not IsNull(Me.cbo_ChinesischWaehlen) Then
DoCmd.SearchForRecord , "", acFirst, "[ID_Vokabeln] = " & Str(Nz(Me.cbo_ChinesischWaehlen, 0))
Me!cbo_ChinesischWaehlen = Null
End If
End SubJetzt fehlt mir nur noch beim Öffnen des Formulares die Anzeige eines leeren Formulars statt des üblichen ersten Datensatzes.
Da finde ich im Moment leider nur Ansätze mit Filtern bei Formload. Bei meinen Versuchen bekomme ich den Filter dann anschließend aber nicht mehr "weg".
Falls Ihr dazu noch einen Tipp habt, in welcher Richtung ich suchen sollte...
gerne. #57
Formular / Re: Kombifelder leeren
Letzter Beitrag von Cherry Brandy - März 15, 2026, 03:33:35Vielen Dank schon mal für die ersten Tipps.
Ich bin in der Zwischenzeit fleißig dabei, zu lernen, zu verstehen und zu verbessern.
Alles auf VBA umzubauen und auf jeden Fall auf Mischmasch, langfristig aber vollständig auf Makros zu verzichten, ist mein Ziel, bzw. war es schon bei Fragestellung.
Die Kombifelder habe ich inzwischen umbenannt in cbo_PinyinWaehlen, cbo_DeutschWaehlen und cbo_ChinesischWaehlen.
@Knobbi38
@Bitsqueezer
Zum ersten Datensatz möchte ich natürlich nicht zurück.
Die Reihenfolge der Events beschäftigt mich gerade noch. Wenn ich es bisher richtig verstanden habe, sollte es mit "AfterUpdate" über VBA möglich sein, nach Auswahl im Kombifeld mit dem Ereignis "AfterUpdate" sowohl a) den gewählten Datensatz anzuzeigen als auch b) die ggf. noch gefüllten anderen Felder von den drei Kombifeldern zu leeren (das kann ja dann nur noch eines sein).
"OnExit" hat mich auch gestört, ich hatte es lediglich verwendet, weil "After Update" schon durch das Makro besetzt war.
Ich bin in der Zwischenzeit fleißig dabei, zu lernen, zu verstehen und zu verbessern.
Alles auf VBA umzubauen und auf jeden Fall auf Mischmasch, langfristig aber vollständig auf Makros zu verzichten, ist mein Ziel, bzw. war es schon bei Fragestellung.
Die Kombifelder habe ich inzwischen umbenannt in cbo_PinyinWaehlen, cbo_DeutschWaehlen und cbo_ChinesischWaehlen.
@Knobbi38
Zitat von: Knobbi38 am März 11, 2026, 09:30:06zunächst würde ich mal sagen, dass deine Tabellen nicht normalisiert sind.Damit hast Du mich ein bisschen kalt erwischt, ich war eigentlich der Meinung, dass ich das getan hätte. An welcher Stelle sollte ich noch mal genauer drüberschauen? Screenshot DBBeziehungen ist beigefügt.
@Bitsqueezer
Zitat von: Bitsqueezer am März 11, 2026, 09:33:37Der gezeigte VBA Code löscht die jeweils anderen beiden Komboboxendas soll er tun
Zitat von: Bitsqueezer am März 11, 2026, 09:33:37... und führt dann einen Requery aus. Das lädt alle Datensätze neu und springt zum ersten Datensatz im Recordset.Ah, das erklärt, warum ich immer "beim ersten Datensatz bleibe".
Zum ersten Datensatz möchte ich natürlich nicht zurück.Die Reihenfolge der Events beschäftigt mich gerade noch. Wenn ich es bisher richtig verstanden habe, sollte es mit "AfterUpdate" über VBA möglich sein, nach Auswahl im Kombifeld mit dem Ereignis "AfterUpdate" sowohl a) den gewählten Datensatz anzuzeigen als auch b) die ggf. noch gefüllten anderen Felder von den drei Kombifeldern zu leeren (das kann ja dann nur noch eines sein).
"OnExit" hat mich auch gestört, ich hatte es lediglich verwendet, weil "After Update" schon durch das Makro besetzt war.
#58
Tabelle/Abfrage / Re: Aktualisierungsabfrage
Letzter Beitrag von Knobbi38 - März 14, 2026, 21:22:14Was meinst du mit "No"? Boolean-Werte sind üblicherweise TRUE oder FALSE.
#59
Tabelle/Abfrage / Aktualisierungsabfrage
Letzter Beitrag von Pädda - März 14, 2026, 20:54:06Problem:
strSQL = "UPDATE tblDoppelFacts SET boDplWFct = No WHERE IDDopplFacts = 1 ;"
Dies ist sozusagen das Ziel- Wird aber nicht akzeptiert mit Fehlermeldung " 1 Parameter erwartet aber zu wenige". Auch die folgende Version stirbt mit gleicher Fehlermeldung:
strSQL = "UPDATE tblDoppelFacts SET '" & stFeld & "' = No WHERE (((tblDoppelFacts.[IDDopplFacts])=1));"
Auch ganz ohne Hochkommata ändert sich nx. Die Tabelle ist ok, hat nur einen datensatz Nr 1 mit 6 Bool Feldern Ja/Nein.
Ich Fahre Win 10, Office 2010, 64 Bit. Hat jemand eine Idee?
strSQL = "UPDATE tblDoppelFacts SET boDplWFct = No WHERE IDDopplFacts = 1 ;"
Dies ist sozusagen das Ziel- Wird aber nicht akzeptiert mit Fehlermeldung " 1 Parameter erwartet aber zu wenige". Auch die folgende Version stirbt mit gleicher Fehlermeldung:
strSQL = "UPDATE tblDoppelFacts SET '" & stFeld & "' = No WHERE (((tblDoppelFacts.[IDDopplFacts])=1));"
Auch ganz ohne Hochkommata ändert sich nx. Die Tabelle ist ok, hat nur einen datensatz Nr 1 mit 6 Bool Feldern Ja/Nein.
Ich Fahre Win 10, Office 2010, 64 Bit. Hat jemand eine Idee?
#60
Formular / Re: Datenquelle für Navigation...
Letzter Beitrag von Knobbi38 - März 13, 2026, 22:15:11Hallo Lars,
im Prinzip wird das Formular im SubForm Steuerelement angesprochen. Wenn du den Namen nicht geändert hast, sollte es den Bezeichner "Navigationsunterformular" besitzen. Du kannst das auch über die Eigenschaft SubForm des Navigationscontrols im Formular abfragen. Über die Eigenschaft Form des SubForm-Steuerelements kommst du dann an das geladene Formular heran und damit auch an dessen Recordsource.
Knobbi38
im Prinzip wird das Formular im SubForm Steuerelement angesprochen. Wenn du den Namen nicht geändert hast, sollte es den Bezeichner "Navigationsunterformular" besitzen. Du kannst das auch über die Eigenschaft SubForm des Navigationscontrols im Formular abfragen. Über die Eigenschaft Form des SubForm-Steuerelements kommst du dann an das geladene Formular heran und damit auch an dessen Recordsource.
Knobbi38