- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#1
Access Programmierung / Re: Kann man mit VBA auslesen,...
Letzter Beitrag von Knobbi38 - März 04, 2026, 20:28:07Hier mal die WMI Variante:
und ein Beispiel für den Aufruf:
Nach dem Muster lassen sich auch noch andere Eigenschaften abfragen.
Siehe:
https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-printer
Knobbi38
Code [Auswählen]
Public Function GetDuplexPrinter() As String()
Dim oPrinters As Object
Dim oPrinter As Object
Dim avntCapabilities As Variant
Dim astrPrinter() As String
Dim i
Const cDUPLEX_PRINTING = 3&
astrPrinter = Split("")
Set oPrinters = GetObject("winmgmts:").InstancesOf("Win32_Printer")
If oPrinters.Count > 0 Then
For Each oPrinter In oPrinters
avntCapabilities = oPrinter.Capabilities
For i = 0 To UBound(avntCapabilities)
If avntCapabilities(i) = cDUPLEX_PRINTING Then
ReDim Preserve astrPrinter(UBound(astrPrinter) + 1)
astrPrinter(UBound(astrPrinter)) = oPrinter.Name
Exit For
End If
Next
Next
End If
GetDuplexPrinter = astrPrinter
Set oPrinter = Nothing
Set oPrinters = Nothing
End Function
und ein Beispiel für den Aufruf:
Code [Auswählen]
Sub ListDuplexPrinter()
Dim astrPrinter() As String
Dim i As Long, n As Long
astrPrinter = GetDuplexPrinter()
n = UBound(astrPrinter)
Debug.Print UBound(astrPrinter) + 1; " Duplex printer found."
For i = 0 To UBound(astrPrinter)
Debug.Print i, astrPrinter(i)
Next
End Sub
Nach dem Muster lassen sich auch noch andere Eigenschaften abfragen.
Siehe:
https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-printer
Knobbi38
#2
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Bitsqueezer - März 03, 2026, 17:07:12Hallo Klaus,
warum formulierst Du es dann immer so absolutistisch, als wenn das, was Du oben geschrieben hast, die einzige Möglichkeit wäre, was faktisch schlicht falsch ist?
Access ist hier genauso vielseitig wie andere DB-Systeme. Auch das also kein Argument.
Man kann das auch einfach so schreiben, daß Du Deine bevorzugte Methode beschreibst, ohne gleich auszuschließen, daß es auch andere Herangehensweisen an ein Problem gibt.
Und ja, in #11 habe ich die (eine!) mögliche Methode unter Anwendung von Relationen beschrieben. Aber auch das ist nicht die einzige oder einzig wahre Methode, es ist eine von sehr vielen Lösungsmöglichkeiten.
Gruß
Christian
warum formulierst Du es dann immer so absolutistisch, als wenn das, was Du oben geschrieben hast, die einzige Möglichkeit wäre, was faktisch schlicht falsch ist?
Access ist hier genauso vielseitig wie andere DB-Systeme. Auch das also kein Argument.
Man kann das auch einfach so schreiben, daß Du Deine bevorzugte Methode beschreibst, ohne gleich auszuschließen, daß es auch andere Herangehensweisen an ein Problem gibt.
Und ja, in #11 habe ich die (eine!) mögliche Methode unter Anwendung von Relationen beschrieben. Aber auch das ist nicht die einzige oder einzig wahre Methode, es ist eine von sehr vielen Lösungsmöglichkeiten.
Gruß
Christian
#3
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von MzKlMu - März 03, 2026, 14:54:02@christian,
Im Grunde hast Du mit Deiner Antwort in #11 genau meine Sichtweise bestätigt.
Ich habe fertig.
ZitatAuch Datenbankprofis bauen Datenbanksysteme, die keinerlei Beziehungen zueinander haben.Das ist mir durchaus geläufig und mir sind die unterschiedlichen Strukturformen von Datenbanken auch bekannt. Aber, wir sind hier nun mal bei Access zur Entwicklung relationaler Datenbanken. Und meine Meinung bassiert ausschließlich auf dieser Annahme.
Im Grunde hast Du mit Deiner Antwort in #11 genau meine Sichtweise bestätigt.
Ich habe fertig.
#4
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Bitsqueezer - März 03, 2026, 14:09:25Hallo Andre,
ich würde hier eher auf Key/Value-Tabellen setzen.
Eine Tabelle, die die Maschinen listet.
Eine Tabelle, die alle Module (aller Maschinen) listet.
Eine m:n-Tabelle, die Module zu Maschinen zuordnet (wodurch jedes Modul in jeder Maschine vorkommen kann, außerdem kann die m:n-Tabelle z.B. eine Modulseriennummer erhalten etc.).
Eine Tabelle, die alle Parameter (aller Module) listet, deren Parameternamen und Metadaten wie Datentyp, Wertebereichsfelder usw.
Eine Tabelle für Parameterlisten, bestehend aus ID und Parameterlistenname.
Eine Tabelle für Parameterlisten-Parameter, die die ID der Parameterliste und die ID eines Parameters enthält. Damit erhält man den Inhalt einer Parameterliste.
Dann kommt die Tabelle für die Zuordnung der Parameter-IDs zu einer Modul-ID. Damit kannst Du dann jedem Modul jeden Parameter zuordnen. Die Tabelle enthält außerdem ein Textfeld für den Parameterwert, oder alternativ ein paar Felder unterschiedlicher Datentypen (Text, Integer, Decimal z.B.), um einen Value im passenden Datentyp gemäß Parameterdefinition zu speichern.
Im Verwaltungsfrontend kannst Du damit nun Module erstellen, ihnen Namen vergeben und mit Hilfe der Parameterlisten-Tabelle eine passende Liste von Parametern in die Key/Value-Tabelle schreiben, die dann passend zum Modul mit Werten versehen werden kann.
Du kannst Maschinen anlegen und ihnen dann die Module zuweisen, die dann die passenden Parameter beinhalten.
In dieser Form ist es komplett datenbankkonform, Du bist maximal flexibel und Du kannst das auch hervorragend in einem Bericht verwenden, um im Hauptbericht z.B. die Maschinen zu listen, im Unterbericht die zugehörigen Module und in einem Unterunterbericht alle Parameter. (Alternativ kann man das auch über Gruppen machen, das braucht dann keine Unterberichte, etwas, was es in Formularen nicht gibt.)
Vorteil: Du brauchst nichts mehr neu zu programmieren, wenn Module oder Maschinen oder Parameter sich ändern, Du paßt einfach nur den Inhalt der Tabellen über ein Verwaltungsfrontend an.
Das kann man dann für den User ebenfalls verwenden, um über weitere Tabellen Parameterhistories zu verwalten usw.
Gruß
Christian
ich würde hier eher auf Key/Value-Tabellen setzen.
Eine Tabelle, die die Maschinen listet.
Eine Tabelle, die alle Module (aller Maschinen) listet.
Eine m:n-Tabelle, die Module zu Maschinen zuordnet (wodurch jedes Modul in jeder Maschine vorkommen kann, außerdem kann die m:n-Tabelle z.B. eine Modulseriennummer erhalten etc.).
Eine Tabelle, die alle Parameter (aller Module) listet, deren Parameternamen und Metadaten wie Datentyp, Wertebereichsfelder usw.
Eine Tabelle für Parameterlisten, bestehend aus ID und Parameterlistenname.
Eine Tabelle für Parameterlisten-Parameter, die die ID der Parameterliste und die ID eines Parameters enthält. Damit erhält man den Inhalt einer Parameterliste.
Dann kommt die Tabelle für die Zuordnung der Parameter-IDs zu einer Modul-ID. Damit kannst Du dann jedem Modul jeden Parameter zuordnen. Die Tabelle enthält außerdem ein Textfeld für den Parameterwert, oder alternativ ein paar Felder unterschiedlicher Datentypen (Text, Integer, Decimal z.B.), um einen Value im passenden Datentyp gemäß Parameterdefinition zu speichern.
Im Verwaltungsfrontend kannst Du damit nun Module erstellen, ihnen Namen vergeben und mit Hilfe der Parameterlisten-Tabelle eine passende Liste von Parametern in die Key/Value-Tabelle schreiben, die dann passend zum Modul mit Werten versehen werden kann.
Du kannst Maschinen anlegen und ihnen dann die Module zuweisen, die dann die passenden Parameter beinhalten.
In dieser Form ist es komplett datenbankkonform, Du bist maximal flexibel und Du kannst das auch hervorragend in einem Bericht verwenden, um im Hauptbericht z.B. die Maschinen zu listen, im Unterbericht die zugehörigen Module und in einem Unterunterbericht alle Parameter. (Alternativ kann man das auch über Gruppen machen, das braucht dann keine Unterberichte, etwas, was es in Formularen nicht gibt.)
Vorteil: Du brauchst nichts mehr neu zu programmieren, wenn Module oder Maschinen oder Parameter sich ändern, Du paßt einfach nur den Inhalt der Tabellen über ein Verwaltungsfrontend an.
Das kann man dann für den User ebenfalls verwenden, um über weitere Tabellen Parameterhistories zu verwalten usw.
Gruß
Christian
#5
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Bitsqueezer - März 03, 2026, 13:49:29Hallo Klaus,
naja, auch wenn Du sicher ob der Erfahrung des Fragestellers richtig liegen dürftest, kann man das so aber auch nicht formulieren.
Wenn Du eine Tabelle Kunden hast und eine mit Lieferanten und eine mit Artikeln, dann haben diese nicht zwingend eine Beziehung zueinander.
Wenn ich wissen möchte, welche 10 Kunden sind zuletzt hinzugekommen, welche 10 Lieferanten und welche 10 Artikel, stelle ich einfach (hier) drei Unterberichte untereinander, die wiederum keine Beziehung zum Hauptbericht haben, da sie nichts miteinander zu tun haben.
Wenn die Tabellen als Heap geführt werden, also ohne PK, etwa nur über das Einrichtungsdatum selektiert werden sollen, braucht man dazu auch keinen PK und keinen FK.
Ein Index wäre gut für die Performance, aber auch der ist nicht zwingend notwendig. Auswahl der Datensätze erfolgt über Datumsbereich (im Beispiel).
Das ist nicht schön und keine perfekte Datenbankwelt, aber durchaus machbar.
Übrigens: Auch Datenbankprofis bauen Datenbanksysteme, die keinerlei Beziehungen zueinander haben. Ich arbeite berufsbedingt gerade mit Sage 100 und wie soll man sagen, ein paar hundert Tabellen und KEINE Beziehungen zueinander. Das ist extrem nervig, weil man es auch schlecht herausfinden kann, was wozu gebraucht wird, aber machbar ist es. Und offenbar hält sich das System schon viele Jahre auf dem Markt.
(OK, inwieweit man die Ersteller wirklich als "Profis" bezeichnen darf, steht auf einem anderen Blatt... ich würde nie eine so komplexe Datenbank ohne Beziehungen und RI bauen...)
Gruß
Christian
naja, auch wenn Du sicher ob der Erfahrung des Fragestellers richtig liegen dürftest, kann man das so aber auch nicht formulieren.
Wenn Du eine Tabelle Kunden hast und eine mit Lieferanten und eine mit Artikeln, dann haben diese nicht zwingend eine Beziehung zueinander.
Wenn ich wissen möchte, welche 10 Kunden sind zuletzt hinzugekommen, welche 10 Lieferanten und welche 10 Artikel, stelle ich einfach (hier) drei Unterberichte untereinander, die wiederum keine Beziehung zum Hauptbericht haben, da sie nichts miteinander zu tun haben.
Wenn die Tabellen als Heap geführt werden, also ohne PK, etwa nur über das Einrichtungsdatum selektiert werden sollen, braucht man dazu auch keinen PK und keinen FK.
Ein Index wäre gut für die Performance, aber auch der ist nicht zwingend notwendig. Auswahl der Datensätze erfolgt über Datumsbereich (im Beispiel).
Das ist nicht schön und keine perfekte Datenbankwelt, aber durchaus machbar.
Übrigens: Auch Datenbankprofis bauen Datenbanksysteme, die keinerlei Beziehungen zueinander haben. Ich arbeite berufsbedingt gerade mit Sage 100 und wie soll man sagen, ein paar hundert Tabellen und KEINE Beziehungen zueinander. Das ist extrem nervig, weil man es auch schlecht herausfinden kann, was wozu gebraucht wird, aber machbar ist es. Und offenbar hält sich das System schon viele Jahre auf dem Markt.
(OK, inwieweit man die Ersteller wirklich als "Profis" bezeichnen darf, steht auf einem anderen Blatt... ich würde nie eine so komplexe Datenbank ohne Beziehungen und RI bauen...)
Gruß
Christian
#6
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Instandhalter - März 03, 2026, 13:46:54Hi,
ich habe es hin bekommen.
In den Abfragen fehlte folgender Eintrag in der SQL Ansicht:
SELECT
FROM [jeweiligeTabelle]
WHERE
ID = (
SELECT
MAX(ID)
FROM
[jeweiligeTabelle]
);
Ansonsten habe ich jetzt für jedes Formular einen Bericht erstellt und in einem Gesamt Bericht zusammengefasst.
Jetzt wird der letzte aktuelle Eintrag angezeigt und gedruckt.
Zum Hintergrund, es wird keine klassische Datenbank mit verknüpften Tabellen für Verwaltung, Adressen oder ä.
Sondern es wird eine digitale Parameterliste für unsere Maschinen und Anlagen in Form einer Datenbank.
Warum, derzeit werden alle Parameteränderungen an den Anlagen in Papierform geführt. Das macht die Nachverfolgbarkeit schwierig und im Ramen vom IATF müssen wir jetzt Digitalisieren.
Jede Anlage hat eigenständige Module mit einem separaten Parametersatz, deshalb habe ich für jedes eine Tabelle angelegt.
Was macht die Datenbank:
In der Grundansicht ist alles gesperrt
Bei angeforderter Bearbeitung, wird im jeweiligen Modul ein neuer Datensatz angelegt und mit einem Zeitstempel versehen. Zusätzlich muss die Auftragsnummer eingegeben werden. (wurde bisher durch die Mitarbeiter ständig vergessen.)
Weiterhin wird bei Datenänderung der jeweilige Eintrag automatisch Rot markiert. Die Rote Markierung bleibt über 3 Aufträge bestehen. Falls es hier keine Änderungen mehr gibt, gilt der Parameter als qualifiziert und die Markierung verschwindet automatisch. Zusätzlich gibt es noch eine History. In der Ansicht kann man sich die Einträge auswählen anzeigen und Filtern lassen.
War viel Arbeit und man kann vieles effizienter gestalten, aber es funktioniert.
Wenn gewünscht, lade ich sie hoch.
Grüße
Andre
ich habe es hin bekommen.
In den Abfragen fehlte folgender Eintrag in der SQL Ansicht:
SELECT
FROM [jeweiligeTabelle]
WHERE
ID = (
SELECT
MAX(ID)
FROM
[jeweiligeTabelle]
);
Ansonsten habe ich jetzt für jedes Formular einen Bericht erstellt und in einem Gesamt Bericht zusammengefasst.
Jetzt wird der letzte aktuelle Eintrag angezeigt und gedruckt.
Zum Hintergrund, es wird keine klassische Datenbank mit verknüpften Tabellen für Verwaltung, Adressen oder ä.
Sondern es wird eine digitale Parameterliste für unsere Maschinen und Anlagen in Form einer Datenbank.
Warum, derzeit werden alle Parameteränderungen an den Anlagen in Papierform geführt. Das macht die Nachverfolgbarkeit schwierig und im Ramen vom IATF müssen wir jetzt Digitalisieren.
Jede Anlage hat eigenständige Module mit einem separaten Parametersatz, deshalb habe ich für jedes eine Tabelle angelegt.
Was macht die Datenbank:
In der Grundansicht ist alles gesperrt
Bei angeforderter Bearbeitung, wird im jeweiligen Modul ein neuer Datensatz angelegt und mit einem Zeitstempel versehen. Zusätzlich muss die Auftragsnummer eingegeben werden. (wurde bisher durch die Mitarbeiter ständig vergessen.)
Weiterhin wird bei Datenänderung der jeweilige Eintrag automatisch Rot markiert. Die Rote Markierung bleibt über 3 Aufträge bestehen. Falls es hier keine Änderungen mehr gibt, gilt der Parameter als qualifiziert und die Markierung verschwindet automatisch. Zusätzlich gibt es noch eine History. In der Ansicht kann man sich die Einträge auswählen anzeigen und Filtern lassen.
War viel Arbeit und man kann vieles effizienter gestalten, aber es funktioniert.
Wenn gewünscht, lade ich sie hoch.
Grüße
Andre
#7
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Debus - März 03, 2026, 12:29:04Hey, wie wäre es, wenn Du das was Du mal hast hier zur Verfügung stellst, dann kann man Dir wahrscheinlich leichter helfen.
Gruß
Holger
Gruß
Holger
#8
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von MzKlMu - März 03, 2026, 12:12:21Hallo,
Auch um eine Datenauswahl zum Drucken auszuwählen, sind Schlüsselfelder notwendig. Über den Primärschlüssel erfolgt dann die eindeutige Identifikation.
Zum Ausdruck ist ein Bericht erforderlich. Ein Bericht hat mit Formularen nichts zu tun.
- Was sind das für 4 Tabellen
- Gibt es Beziehungen
Ich fürchte, Du hast noch ein erhebliches Defizit was Access betrifft.
ZitatJa, in der Datenbank sind 4 Tabellen, die unabhängig voneinander sind.Das kann so nicht sein. Wenn das 4 Tabellen sind, so sind Beziehungen zwischen den Tabellen erforderlich. Dazu braucht es Schlüsselfelder.
Auch um eine Datenauswahl zum Drucken auszuwählen, sind Schlüsselfelder notwendig. Über den Primärschlüssel erfolgt dann die eindeutige Identifikation.
Zum Ausdruck ist ein Bericht erforderlich. Ein Bericht hat mit Formularen nichts zu tun.
- Was sind das für 4 Tabellen
- Gibt es Beziehungen
Ich fürchte, Du hast noch ein erhebliches Defizit was Access betrifft.
#9
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Bitsqueezer - März 03, 2026, 12:06:59Hallo,
wenn es 4 unabhängige Tabellen sind, die inhaltlich einen anderen Aufbau haben, dann erstelle für jede der 4 Tabellen je einen Bericht.
Diese Berichte kannst Du dann als Unterberichte in einen Hauptbericht einfügen, wobei deren senkrechte Größe klein eingestellt sein kann, dabei stellst Du jeden Unterbericht so ein, daß er automatisch vergrößert wird.
Für jeden der Unterberichte verwendest Du eine passende Abfrage, in der es nur an Dir liegt, was "letzte aktuelle" Datensätze sind. Das kann ein Datensatzdatum sein, oder die Auto-ID als Primary Key (sofern vorhanden) oder welches Kriterium auch immer. Wenn Du davon die letzten 10 Datensätze z.B. sehen willst, kannst Du die Abfrage absteigend nach Datum oder PK sortieren und dann ein "TOP 10" nach "SELECT" schreiben.
Berichte kann man wie Formulare automatisiert erstellen lassen. Einfach die gewünschte Abfrage direkt öffnen und dann auf einen der Berichtsarten klicken, Access erstellt dann einen fertigen Bericht (den man i.d.R. noch im Design anpassen muß).
Gruß
Christian
wenn es 4 unabhängige Tabellen sind, die inhaltlich einen anderen Aufbau haben, dann erstelle für jede der 4 Tabellen je einen Bericht.
Diese Berichte kannst Du dann als Unterberichte in einen Hauptbericht einfügen, wobei deren senkrechte Größe klein eingestellt sein kann, dabei stellst Du jeden Unterbericht so ein, daß er automatisch vergrößert wird.
Für jeden der Unterberichte verwendest Du eine passende Abfrage, in der es nur an Dir liegt, was "letzte aktuelle" Datensätze sind. Das kann ein Datensatzdatum sein, oder die Auto-ID als Primary Key (sofern vorhanden) oder welches Kriterium auch immer. Wenn Du davon die letzten 10 Datensätze z.B. sehen willst, kannst Du die Abfrage absteigend nach Datum oder PK sortieren und dann ein "TOP 10" nach "SELECT" schreiben.
Berichte kann man wie Formulare automatisiert erstellen lassen. Einfach die gewünschte Abfrage direkt öffnen und dann auf einen der Berichtsarten klicken, Access erstellt dann einen fertigen Bericht (den man i.d.R. noch im Design anpassen muß).
Gruß
Christian
#10
Bericht / Re: Bericht mit mehreren Formu...
Letzter Beitrag von Instandhalter - März 03, 2026, 11:55:52Jetzt hab ich es geschnallt.
Ich muss den Bericht als eigenständiges Objekt mit eigener Abfrage erstellen.
Ja, in der Datenbank sind 4 Tabellen, die unabhängig voneinander sind.
Die Anzahl der Datensätze in den Tabellen ist unterschiedlich.
Was ich erreichen möchte, ist ein Gesamtbericht mit dem letzten aktuellen Datensätzen der 4 Tabellen.
Ich muss den Bericht als eigenständiges Objekt mit eigener Abfrage erstellen.
Ja, in der Datenbank sind 4 Tabellen, die unabhängig voneinander sind.
Die Anzahl der Datensätze in den Tabellen ist unterschiedlich.
Was ich erreichen möchte, ist ein Gesamtbericht mit dem letzten aktuellen Datensätzen der 4 Tabellen.