- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#1
Tabelle/Abfrage / Re: Verschachtelte Abfrage mit...
Letzter Beitrag von WernHo - April 05, 2026, 15:30:58Ach ja, stimmt. Daran habe ich nicht gedacht.
Vielen lieben Dank.
Vielen lieben Dank.
#2
Tabelle/Abfrage / Re: Verschachtelte Abfrage mit...
Letzter Beitrag von Bitsqueezer - April 04, 2026, 12:59:01Hallo,
das liegt an Deinem JOIN: bei INNER JOIN werden nur Datensätze angezeigt, die in beiden Tabellen vorkommen.
Daher nimmst Du diejenige Tabelle, von der Du immer alle Datensätze sehen willst und machst von dieser aus einen LEFT JOIN zu der Tabelle, die nicht immer alle Datensätze hat, dann wird für diese im Ergebnis für alle Felder im SELECT NULL angezeigt.
Mit dem Abfragedesigner ist das auch ganz einfach: Zeige Dir die Eigenschaften der Verbindungslinie an, die sagt Dir ganz deutlich, welche Einstellung Du brauchst und verwandelt Deinen JOIN entsprechend passend.
Gruß
Christian
das liegt an Deinem JOIN: bei INNER JOIN werden nur Datensätze angezeigt, die in beiden Tabellen vorkommen.
Daher nimmst Du diejenige Tabelle, von der Du immer alle Datensätze sehen willst und machst von dieser aus einen LEFT JOIN zu der Tabelle, die nicht immer alle Datensätze hat, dann wird für diese im Ergebnis für alle Felder im SELECT NULL angezeigt.
Mit dem Abfragedesigner ist das auch ganz einfach: Zeige Dir die Eigenschaften der Verbindungslinie an, die sagt Dir ganz deutlich, welche Einstellung Du brauchst und verwandelt Deinen JOIN entsprechend passend.
Gruß
Christian
#3
Tabelle/Abfrage / Verschachtelte Abfrage mit Anz...
Letzter Beitrag von WernHo - April 04, 2026, 12:35:29Access 2019, 2 Tabellen: MM & VerzeichnisNeu
1) MM.ID, MM.VerzNr, MM.Nr (ID=Index, VerzeichnisNr, Nummer (String, 3-stellig zum Kennzeichnen)
2) VerzeichnisNeu.ID, VerzeichnisNeu.ModelName, VerzeichnisNeu.VerzNr (ID=Index, PersonenName, VerzNr wie in Tabelle 1)
Die beiden Tabellen sind durch die VerzNr verbunden, somit kann ich 001: ErsterName, 002:ZweiterName .... 211:ZweihundertelfterName darstellen.
Nun kommt es vor, dass manche Namen öfters vorkommen, zB. an 11. Stelle und an 121. Stelle, also 011 und 121.
Somit 2x vorhanden.
Das frage ich ab, wie viele Male jemand vorkommt in aufsteigender Reihenfolge und es klappt auch wunderbar:
Aber ich habe nun ein kleines Problem: diejenigen, die noch keinen Eintrag haben, werden nicht berücksichtigt. Also diejenigen, die Anzahl Null haben.
Und das möchte ich gerne auch angezeigt haben.
KI habe ich befragt, auch gegoogelt, bin aber leider zu keinem brauchbaren Ergebnis bekommen.
Daher möchte ich bitte die Profis hier fragen, wie ich so etwas bewerkstelligen kann.
Danke im Voraus.
1) MM.ID, MM.VerzNr, MM.Nr (ID=Index, VerzeichnisNr, Nummer (String, 3-stellig zum Kennzeichnen)
2) VerzeichnisNeu.ID, VerzeichnisNeu.ModelName, VerzeichnisNeu.VerzNr (ID=Index, PersonenName, VerzNr wie in Tabelle 1)
Die beiden Tabellen sind durch die VerzNr verbunden, somit kann ich 001: ErsterName, 002:ZweiterName .... 211:ZweihundertelfterName darstellen.
Nun kommt es vor, dass manche Namen öfters vorkommen, zB. an 11. Stelle und an 121. Stelle, also 011 und 121.
Somit 2x vorhanden.
Das frage ich ab, wie viele Male jemand vorkommt in aufsteigender Reihenfolge und es klappt auch wunderbar:
Code [Auswählen]
SELECT MM.VerzNr, VerzeichnisNeu.ModelName, (Count(*)) AS Anz FROM MM INNER JOIN VerzeichnisNeu ON MM.VerzNr = VerzeichnisNeu.VerzNr
GROUP BY MM.VerzNr, VerzeichnisNeu.ModelName ORDER BY (Count(*)) DESC;Somit werden angezeigt: VerzNr, ModelName, Anz (wie oft vorhanden), höchste Anzahl zuerst.Aber ich habe nun ein kleines Problem: diejenigen, die noch keinen Eintrag haben, werden nicht berücksichtigt. Also diejenigen, die Anzahl Null haben.
Und das möchte ich gerne auch angezeigt haben.
KI habe ich befragt, auch gegoogelt, bin aber leider zu keinem brauchbaren Ergebnis bekommen.
Daher möchte ich bitte die Profis hier fragen, wie ich so etwas bewerkstelligen kann.
Danke im Voraus.
#4
Access Programmierung / Re: Datensätze filtern per But...
Letzter Beitrag von Bitsqueezer - April 03, 2026, 23:20:55Hallo,
also wenn man denn unbedingt Buttons haben will (ich fände auch eine Kombobox sinnvoller), dann sollte man die Buttons wenigstens nicht statisch halten, sondern einfach mit z.B. 1 bis 10 (mehr als 10 Jahre wird kaum jemand brauchen) durchnumerieren, und dann beispielsweise vom heutigen Jahr - 10 den ersten Button per Code in Form_Load mit 2016, den zweiten mit 2017 usw. beschriften.
So paßt sich die UI automatisch an, wenn das nächste Jahr kommt. Und das Jahr, das geklickt wurde, ist dann leicht anhand der Button-Nummer zu ermitteln.
Etwas eleganter, ohne einen Wust an Eventprozeduren für 10 Buttons, kann man es mit Eventklassen lösen.
Ein Beispiel findest Du auf meiner Downloadseite unter "ButtonArray".
Oder, was noch einfacher ist: Toggle-Buttons verwenden. Also eine Optionsgruppe, bei der ohnehin jeder Button einen Wert hat, den Du aus der Optionsgruppe auslesen kannst. Die dynamische Beschriftung der Buttons bleibt, und anhand des Values der Optionsgruppe kannst Du das geklickte Jahr berechnen. Alternativ kannst Du den Value je Button auch schon berechnen in Form_Load und damit aus Value gleich das geklickte Jahr auslesen.
Vorteil hierbei: Der angeklickte Button bleibt gedrückt, so daß man sehen kann, wie der Filter aktuell gesetzt ist.
Du kannst außerdem eine ActiveX-Scrollbar einbauen, mit der Du die Jahreszahlen hin und herscrollen kannst, wenn 10 nicht ausreichen, indem Du einfach Value und Caption "scrollst", also per VBA in Abhängigkeit des Scrollbalkens austauschst.
Man könnte natürlich auch einfach eine Listbox einsetzen, hier ginge dann sogar Mehrfachauswahl. Die geht allerdings nur als senkrechte Liste, während Du bei der OptionGroup frei gestalten kannst.
Gruß
Christian
also wenn man denn unbedingt Buttons haben will (ich fände auch eine Kombobox sinnvoller), dann sollte man die Buttons wenigstens nicht statisch halten, sondern einfach mit z.B. 1 bis 10 (mehr als 10 Jahre wird kaum jemand brauchen) durchnumerieren, und dann beispielsweise vom heutigen Jahr - 10 den ersten Button per Code in Form_Load mit 2016, den zweiten mit 2017 usw. beschriften.
So paßt sich die UI automatisch an, wenn das nächste Jahr kommt. Und das Jahr, das geklickt wurde, ist dann leicht anhand der Button-Nummer zu ermitteln.
Etwas eleganter, ohne einen Wust an Eventprozeduren für 10 Buttons, kann man es mit Eventklassen lösen.
Ein Beispiel findest Du auf meiner Downloadseite unter "ButtonArray".
Oder, was noch einfacher ist: Toggle-Buttons verwenden. Also eine Optionsgruppe, bei der ohnehin jeder Button einen Wert hat, den Du aus der Optionsgruppe auslesen kannst. Die dynamische Beschriftung der Buttons bleibt, und anhand des Values der Optionsgruppe kannst Du das geklickte Jahr berechnen. Alternativ kannst Du den Value je Button auch schon berechnen in Form_Load und damit aus Value gleich das geklickte Jahr auslesen.
Vorteil hierbei: Der angeklickte Button bleibt gedrückt, so daß man sehen kann, wie der Filter aktuell gesetzt ist.
Du kannst außerdem eine ActiveX-Scrollbar einbauen, mit der Du die Jahreszahlen hin und herscrollen kannst, wenn 10 nicht ausreichen, indem Du einfach Value und Caption "scrollst", also per VBA in Abhängigkeit des Scrollbalkens austauschst.
Man könnte natürlich auch einfach eine Listbox einsetzen, hier ginge dann sogar Mehrfachauswahl. Die geht allerdings nur als senkrechte Liste, während Du bei der OptionGroup frei gestalten kannst.
Gruß
Christian
#5
Tabelle/Abfrage / Re: Access SQL: Konvertierung ...
Letzter Beitrag von Knobbi38 - April 03, 2026, 16:57:07@jens05
Sicherlich hast du damit recht, aber mir geht es um die Lesbarkeit des Codes. Da ist nicht sofort ersichtlich, dass eine Funktion ohne diese Deklaration öffentlich ist, eine mit DIM außerhalb einer Prozedur/Funktion deklarierte Variable jedoch nichtöffentlich. Die explizite Verwendung sollte hier für Klarheit und eine bessere Lesbarkeit sorgen.
Knobbi38
Sicherlich hast du damit recht, aber mir geht es um die Lesbarkeit des Codes. Da ist nicht sofort ersichtlich, dass eine Funktion ohne diese Deklaration öffentlich ist, eine mit DIM außerhalb einer Prozedur/Funktion deklarierte Variable jedoch nichtöffentlich. Die explizite Verwendung sollte hier für Klarheit und eine bessere Lesbarkeit sorgen.
Knobbi38
#6
Access Programmierung / Re: Datensätze filtern per But...
Letzter Beitrag von jens05 - April 03, 2026, 16:50:34Zitat von: Knobbi38 am April 03, 2026, 14:42:57Damit wird dann das ganze Jahr auf jedenfall berücksichtigt.damit hast du natürlich recht, bin vor Jahrzehnten auch darauf reingefallen, und habe mich gewundert warum DS fehlen. Danke fürs erweitern.
ZitatWarum eigentlich keine Kombobox?Zwischenzeitlich ist dem User jeder Klick zuviel, da wird sogar durchgezählt wieviel klicks jemand machen muss um ans Ziel zu kommen.
Sicherlich, ein Kombifeld, oder ein einfaches Textfeld macht dem Ersteller der DB das Leben einfacher
#7
Tabelle/Abfrage / Re: Access SQL: Konvertierung ...
Letzter Beitrag von jens05 - April 03, 2026, 16:46:20Zitat von: Knobbi38 am April 03, 2026, 16:11:31Dann fehlt die Angabe der Sichtbarkeit für die Funktion "Public"Wenn nicht explizit mit Public, Private oder Friend angegeben, lautet die Standardeinstellung für alle Function-Prozeduren ,,Public".
#8
Tabelle/Abfrage / Re: Access SQL: Konvertierung ...
Letzter Beitrag von Knobbi38 - April 03, 2026, 16:11:31Hallo Hans-Jürgen,
dein Code-Minimalismus in allen Ehren, aber das führt zu nichts, denn Ziel ist es ja, erstmal eine Funktion lesbar und wiederverwendbar zu gestalten, damit man nach einiger Zeit mit Problemen konfrontiert wird. Hier ist es zunächst mal die Namenskonvention "dec" anstatt "lng...". "dec" wird sehr häufig als Präfix für Zahlen vom Datentyp Decimal verwendet, hier also mehr als irreführend. Dann fehlt die Angabe der Sichtbarkeit für die Funktion "Public". Schlimmer ist jedoch die Verwendung eines Bytewertes als Schleifenvariable, da dies in VBA nicht immer fehlerfrei funktioniert. Hier sollte man grundsätzlich einen Long Wert verwenden. Außerdem ist das Ergebnis falsch, was zumindest deutlich gekennzeichnet werden sollte!
Du bist auch schon mehrfach auf die Überprüfung von NULL hingewiesen worden – nicht ohne Grund. Die Helfer haben diesbezüglich sicherlich schon ihre Erfahrungen gemacht. Wenn die Abfrage dir "um die Ohren fliegt", erinnert sich später niemand mehr an die schlampig programmierte VBA-Funktion. Entschuldige, aber ich muss es einfach mal so deutlich sagen.
Knobbi38
dein Code-Minimalismus in allen Ehren, aber das führt zu nichts, denn Ziel ist es ja, erstmal eine Funktion lesbar und wiederverwendbar zu gestalten, damit man nach einiger Zeit mit Problemen konfrontiert wird. Hier ist es zunächst mal die Namenskonvention "dec" anstatt "lng...". "dec" wird sehr häufig als Präfix für Zahlen vom Datentyp Decimal verwendet, hier also mehr als irreführend. Dann fehlt die Angabe der Sichtbarkeit für die Funktion "Public". Schlimmer ist jedoch die Verwendung eines Bytewertes als Schleifenvariable, da dies in VBA nicht immer fehlerfrei funktioniert. Hier sollte man grundsätzlich einen Long Wert verwenden. Außerdem ist das Ergebnis falsch, was zumindest deutlich gekennzeichnet werden sollte!
Du bist auch schon mehrfach auf die Überprüfung von NULL hingewiesen worden – nicht ohne Grund. Die Helfer haben diesbezüglich sicherlich schon ihre Erfahrungen gemacht. Wenn die Abfrage dir "um die Ohren fliegt", erinnert sich später niemand mehr an die schlampig programmierte VBA-Funktion. Entschuldige, aber ich muss es einfach mal so deutlich sagen.
Knobbi38
#9
Tabelle/Abfrage / Re: Access SQL: Konvertierung ...
Letzter Beitrag von hajott - April 03, 2026, 15:38:36Hallo Christian,
auch dir vielen Dank. Das mit PIVOT werde ich mir mal ansehen.
Ich habe von euch echt noch viel gelernt!
Vielen Dank und frohe Ostern
Hans-Jürgem
auch dir vielen Dank. Das mit PIVOT werde ich mir mal ansehen.
Ich habe von euch echt noch viel gelernt!
Vielen Dank und frohe Ostern
Hans-Jürgem
#10
Tabelle/Abfrage / Re: Access SQL: Konvertierung ...
Letzter Beitrag von Bitsqueezer - April 03, 2026, 15:01:17Hallo,
wie Ulrich schon sagte, die Funktion verwendet Long als Parameter, was für SQL-Aufrufe nicht gut ist, wenn ein Feld mal NULL ist. Daher am besten für solche Zwecke immer Variant (auch für Rückgabeparameter) verwenden, da hier auch NULL verwendet werden kann.
Wenn Du die Tage als Liste vorliegen hast (also jeweils ein Datensatz) und zusätzlich eine Kalendertabelle mit je Zeile ein Datum hast (und weiteren Spalten wie Jahr, Monat, Tag und weitere hilfreiche Datumswerte), dann kannst Du über MIN das kleinste vorhandene und MAX das größte vorhandene Datum aus Deinen Daten ermitteln und dann die Kalendertabelle verwenden, um alle Tage zwischen diesen Daten abzurufen.
Du hast dann also beispielsweise:
Diese Tabelle kannst Du dann einfach für eine PIVOT-Abfrage benutzen, die aus Zeilen Spalten macht.
Wenn Du das variabel brauchst (weil Pivot-Abfragen normalerweise fest angegebene Spaltennamen brauchen), kannst Du das SQL in VBA zusammenstellen und an eine QueryDef übergeben und danach ausführen.
Mit einer weiteren Spalte, z.B. "IstFreierTag", die Du als Integer-Zahl der Größe Byte definierst, und in der Kalendertabelle angelegt wird, kannst Du diese als Wert für die Pivot-Abfrage verwenden. Da diese eine Aggregatabfrage braucht, kannst Du einfach MIN oder MAX verwenden, was keine Rolle spielt, welche, denn es gibt ohnehin immer nur einen Ergebniswert je Tag. Als Spalten kannst Du dann die Tage zwischen den Kalenderdaten verwenden, als Zeilen die Namen in "Schichtmuster" (gleichbedeutend mit "GROUP BY" quasi).
Theoretisch geht das so auch mit "X" und "-", wenn's sein muß und Du "IstFreierTag" als Text deklarierst. Allerdings hat die Zahl den Vorteil, daß Du sie auch in summierten Abfragen nutzen kannst, um etwa eine Abfrage zu machen, wieviele Arbeitstage zwischen Datum X und Y liegen.
Das Bitgefummel sieht für mich eher nach "Programmierer-Selbstbeschäftigung" aus und nicht nach einer sinnvollen Lösung.
Gruß
Christian
wie Ulrich schon sagte, die Funktion verwendet Long als Parameter, was für SQL-Aufrufe nicht gut ist, wenn ein Feld mal NULL ist. Daher am besten für solche Zwecke immer Variant (auch für Rückgabeparameter) verwenden, da hier auch NULL verwendet werden kann.
Wenn Du die Tage als Liste vorliegen hast (also jeweils ein Datensatz) und zusätzlich eine Kalendertabelle mit je Zeile ein Datum hast (und weiteren Spalten wie Jahr, Monat, Tag und weitere hilfreiche Datumswerte), dann kannst Du über MIN das kleinste vorhandene und MAX das größte vorhandene Datum aus Deinen Daten ermitteln und dann die Kalendertabelle verwenden, um alle Tage zwischen diesen Daten abzurufen.
Du hast dann also beispielsweise:
Code [Auswählen]
Schichtmuster Arbeitstage
Arbeitstag 01.04.26
Osternfrei 02.04.26
Osternfrei 03.04.26
Wochenende 04.04.26
Wochenende 05.04.26
Osternfrei 06.04.26
Osternfrei 07.04.26
Osternfrei 08.04.26
Arbeitstag 09.04.26
Arbeitstag 10.04.26
...
Wobei Dir die Kalendertabelle dazu auch gleich die Texte für "Schichtmuster" ermitteln kann.Diese Tabelle kannst Du dann einfach für eine PIVOT-Abfrage benutzen, die aus Zeilen Spalten macht.
Wenn Du das variabel brauchst (weil Pivot-Abfragen normalerweise fest angegebene Spaltennamen brauchen), kannst Du das SQL in VBA zusammenstellen und an eine QueryDef übergeben und danach ausführen.
Mit einer weiteren Spalte, z.B. "IstFreierTag", die Du als Integer-Zahl der Größe Byte definierst, und in der Kalendertabelle angelegt wird, kannst Du diese als Wert für die Pivot-Abfrage verwenden. Da diese eine Aggregatabfrage braucht, kannst Du einfach MIN oder MAX verwenden, was keine Rolle spielt, welche, denn es gibt ohnehin immer nur einen Ergebniswert je Tag. Als Spalten kannst Du dann die Tage zwischen den Kalenderdaten verwenden, als Zeilen die Namen in "Schichtmuster" (gleichbedeutend mit "GROUP BY" quasi).
Theoretisch geht das so auch mit "X" und "-", wenn's sein muß und Du "IstFreierTag" als Text deklarierst. Allerdings hat die Zahl den Vorteil, daß Du sie auch in summierten Abfragen nutzen kannst, um etwa eine Abfrage zu machen, wieviele Arbeitstage zwischen Datum X und Y liegen.
Das Bitgefummel sieht für mich eher nach "Programmierer-Selbstbeschäftigung" aus und nicht nach einer sinnvollen Lösung.
Gruß
Christian