Bericht mit mehreren Formularen richtig erstellen und Drucken

[Instandhalter]

Hallo liebes Forum,

mein Name ist Andre und wie mein Nick schon sagt Instandhalter.
Ich baue mir gerade eine Datenbank mit 4 Formularen und dazugehörigen Tabellen auf.
Die meisten Sachen, die ich benötige, habe ich mir hier aus dem Forum entnommen.
Aber nun stehe ich vor ein Problem wo ich nicht weiter komme.
Ich möchte die 4 Formulare am Ende mit dem aktuellen Inhalt als kompletten Bericht als PDF ausdrucken.
Hier habe ich mir zunächst ein Formular als Zusammenfassung erstellt, wo die 4 Formulare aufgelistet sind.
Beim Drucken passiert folgendes, dass die Formulare mit allen Datensätzen aus der Datenbank ausgedruckt werden.

Im nächsten Versuch habe ich ein Bericht von der Zusammenfassung erstellt.
selber Effekt, es werden immer alle Formulare mit allen Datensätzen gedruckt.

Im letzten Versuch, habe ich ein Bericht erstellt und die einzelnen Formulare eingefügt.
Auch hier der selbe Effekt.

Ich habe ebenfalls versucht die aktuelle ID der Datensetze zu verwenden, ohne Erfolg, es wird immer der komplette Datenbestand gedruckt.

Wie ist die richtige Vorgehensweise um die 4 Berichte mit dem aktuellen Inhalt zusammenzufassen und als pdf zu drucken.

Für Hilfe wäre ich äußerst Dankbar.


Grüße Andre

[trebuh]

Ich nehme mal an, Du meinst mit "aktuellen Inhalt" den Aktuellen Datensatz im Formular? (Einzelnes Formular)

Sind den alle 4 Formulare gleichzeitig offen?
Oder Hast Du ein Formular mir 3 Unterformularen?

[MzKlMu]

Hallo,
das ist der völlig falsche Ansatz. Man druckt keine Formulare als Bericht.
Ein Bericht ist ein eigenständiges Objekt und braucht auch eine eigene Abfrage als Datenbasis.
Und in dieser Abfrage wird über die Kriterien bestimmt welche(r) Datensatz/sätze gedruckt werden soll(en).

Auch beim Druck der Formulare sind in der Datenbasis Kriterien anzuwenden. Aber wie gesagt, Formulare werden nicht gedruckt.

[Instandhalter]

Guten Morgen,
ich gehe auch davon aus, dass ich an einer Stelle die Datenbank falsch aufgebaut habe.

Aufgebaut ist das ganze wie folgt:
Tabelle > Abfrage > Formular_Eingabe > Hauptformular mit Reitern für die Eingaben (funktioniert bestens)

Auswertung:
Tabelle > Abfrage > Formular_Auswertung > Formular_Zusammenfassung > Bericht
Im Bericht wird alles korrekt angezeigt incl. Datensätze im aktuellen Stand so wie ich das benötige.
Gehe ich jetzt auf drucken oder Druckvorschau, will Access auf einmal den Inhalt der kompletten Datenbank drucken
Also wenn z.B. Tabelle1 10 Einträge hat, dann werden 10 Seiten von Tabelle1 ausgedruckt.
Wie kann ich das verhindern?

[MzKlMu]

Hallo,

Wie kann ich das verhindern?

Ich habe alles dazu gesagt. Du brauchst Kriterien in der Abfrage die auf die gewünschten Daten filtert.
Ohne Kriterien, werden immer alle Datensätze gedruckt/angezeigt.

Und wie gesagt, Formulare sind zum Drucken ungeeignet (auch über einen Bericht). Du musst Dir einen Bericht erstellen mit einer entsprechenden Datenquelle (Abfrage) für die dann auch die entsprechenden Kriterien einzustellen sind.
Auf meine diesbezügliche Hinweise von mir gehst Du auch weiter gar nicht ein.

Datenbank falsch aufgebaut

Dass die Datenbank falsch aufgebaut ist, habe ich ja nicht gesagt, das wäre noch zu klären. Du sprichst auch von Tabellen (Mehrzahl) aber in der weiteren Beschreibung schreibst Du Tabelle (Einzahl).
Du solltest mal genauer beschreiben was Du hast und hier mal ein Bild des Beziehungsfensters posten. Sobald es mehr als eine Tabelle gibt, sind Bezieheungen erforderlich.

Access ist kein fertiges Programm, sondern eine Entwicklungsplattform zur Erstellung relationaler Datenbanken. Dazu ist es unerlässlich Access zu lernen. Da geht nichts intuitiv wie z.B. Exel oder Word.
Hier mal ein Tutorial:

https://www.access-tutorial.de/

[Instandhalter]

Jetzt 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.

[Bitsqueezer]

Hallo,

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

[MzKlMu]

Hallo,

Ja, 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.

[Debus]

Hey, 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

[Instandhalter]

Hi,
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

[Bitsqueezer]

Hallo 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

[Bitsqueezer]

Hallo 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

[MzKlMu]

@christian,

Auch 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. 

[Bitsqueezer]

Hallo 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