infobase: EDV - MS-Access

Berichte

BERICHTE / UNTERBERICHTE:

Unterberichte lassen sich wie Unterfomulare einsetzen. Auch die Sache mit den relationalen Bezügen klappt zuverlässig und schnell. Allerdings muß die Datenquelle des Unterberichtes auch das Verknüpfungsfeld enthalten, über das die
Steuerung von Haupt- und Unterbericht läuft. Schwierig wird das, wenn ein Unterbericht summarische GROUP BY - Auswertungen beinhaltet, in denen die SELECT-Anweisung nicht diverse Felder beinhalten kann. Hier muß die SQL-Anweisung, die die Daten des Unterberichtes liefert, einen Ausdruck a'la

WHERE FeldName=[Berichte]![BerichtName]![FeldName]

s.a. Bericht Kommissionsliste in strobel.mdb

Ein bißchen ärgerlich ist, daß Unterberichte mit einem Seitenwechsel nicht sehr viel anfangen können. Ein typisches Beispiel ist der oben genannte Bericht. Dem Hauptbericht liegen als Datenquelle die Kommissionen/Aufträge zugrunde. Diverse Unterberichte liefern die dazugehörenden Zeitdaten sowie summarische GROUP BY - Auswertungen der Kostenstellen und Mitarbeiter. Ein klassisches Seitenwechsel-Thema wäre z.B. das Drucken einer Überschriftenzeile auf jeder Seite eines mehrseitigen Berichtes. Werden die mehreren Seiten aber durch entsprechend umfangreiche Daten eines Unterberichtes erzeugt, klappt zwar die Sache mit dem Drucker-bezogenen Seitenwechsel, aber den Unterberichten wird das
Ereignis Seitenwechsel offenbar vorenthalten, so daß die Überschriftenzeilen eines Unterberichtes nur einmal erscheinen. Schade !

* * * *

Arbeiten mit BERICHTEN / SORTIERTE DATEN IN FORMULAREN MIT BERICHTEN DRUCKEN / FORMULARDATEN MIT EIGENER SORTIERUNG DRUCKEN / REIHENFOLGE von DATEN wie im FORMULAR DRUCKEN / FORMULARE überhaupt DRUCKEN / ANZAHL von Datensätzen in
BERICHTEN / LAUFENDE SUMMEN in BERICHTEN:

Ein einfaches Problem vorneweg:

In einer anwenderfreundlichen Software kann direkt von einem datenbearbeitenden Formular aus ein entprechender Druck ausgelöst werden. Um die aktuellsten Eingaben mit zu berücksichtigen, sollte jedoch die Eigenschaft 'dirty' des
Formulares überprüft und ein Speichern des Datensatzes vorgenommen werden.

Um das bei Open Access automatisch bewältigte Problem, Daten beim Drucken sortiert auszugeben, in ACCESS zu lösen, bedarf es einiger Klimmzüge. Hat man diese umständliche Art und Weise erst einmal gefressen, ergeben sich jedoch auch
positive Aspekte, wie z.B. zur Laufzeit auf derartige Eigenschaften wie Gruppenbildung und Sortierung durch flexible SourceCode-Routinen eingreifen zu können.

Verdeutlicht werden soll das anhand des Berichtes 'Ventile_Liste' in 'HP_VHP.MDB':

Für diesen Bericht wurden zwei Ebenen in 'Gruppieren und Sortieren' vereinbart:
- Die erste beinhaltet einen Gruppenfuß, der einen durchgehenden Unterstrich als grafisches Element druckt. Dummerweise muß er an ein Feld gebunden sein, mitsamt den dazugehörenden Eigenschaften 'Gruppieren nach' und 'Intervall'.
- Die zweite beinhaltet ein Feld, nach dem die zu druckenden Datensätze innerhalb der durch die ersten Ebene gebildeten Gruppen sortiert werden.

Um einen umlaufenden Rahmen unten nach dem letzten Datensatz zu schließen, wird Ebene 1 auf ein Feld gesetzt, das über alle Datensätze eine gemeinsame Eigenschaft aufweist, z.B. der erste (Intervall=1) Buchstabe des Feldes BNr. Die
Eigenschaft 'Gruppieren nach' steht in diesem Fall auf 'Anfangszeichen'. Die für das Auge sichtbare Sortierung der Liste wird hier ausschließlich durch die zweite Ebene bestimmt.

Werden für die erste Ebene Angaben wie 'Gruppieren nach'='Anfangszeichen' und Intervall=3 gemacht, werden für das entsprechende Feld Gruppen gebildet, die jeweils mit einem Trennstrich abgeschlossen werden. Die Datensätze innerhalb
dieser Gruppen werden nach den Angaben von Ebene 2 sortiert.

Zum Thema 'Daten sortiert ausdrucken' mußte es leider zu einem mittleren Eklat kommen.

Folgender Fall:

Der Anwender erhält in Folge eines Such- und Filtervorgangs eine Datenblatt-Liste mit mehreren Datensätzen. Er verfügt über die Möglichkeit, z.B. über die schnelle Sortierung oder im schlimmsten Fall sogar über die Filtergeschichten die Reihenfolge der angezeigten Daten auf mannigfaltigste Art zu verändern ... und dann sollen diese Daten ausgedruckt werden.

Es gab mal eine Zeit, in der gab es eine Software, mit der man genau das tun konnte ...

In Access ist es nicht möglich, die manipulierte Reihenfolge der Daten abzufragen und sie mittels von SQL-Anweisungen im Bericht nachzuvollziehen.

Mögliche Strategien waren u.a. Imitieren der Symbolleisten-Sortier-Schaltflächen durch Ersetzen durch Makro's, die die gewünschten Sortierungen durchführen. Hier könnten in eigenen Code's auch entsprechende Flags oder globale SQL-Strings
gesetzt werden. Völlig deppenmäßig wäre z.B. daß Reinnudeln der angezeigten Daten in eine temporäre Tabelle, auf die dann nämlich auch die RecordSource-Eigenschaft des Berichtes gesetzt wird. Aber bei größeren Datenmengen sicher eine Strafe für Mensch und Rechner.

Wie üblich konnte im Hause DMT wieder einmal eine Lösung gefunden werden, die die Unzulänglichkeiten von MS-Access ebenso elegant wie gewitzt überwindet.

Die in keiner abfragbaren Eigenschaft hinterlegte Reihenfolge der angezeigten Daten kann für die Position jedes einzelnen Datensatzes per Durchnudeln der RecordsetClone-Datensätze nachvollzogen werden. Leider besteht keine
Möglichkeit, der Datenherkunft eines Berichtes die Daten eines RecordSet's zuzuordnen. Der Ausweg besteht darin, die bisher an Felder der bezogenen Tabelle gebundenen Steuerelemente zu 'entbinden', damit beim Ereignis 'On_Print' des
Datenbereichs den Steuerelementen überhaupt Werte zugewiesen werden können. Wichtig ist nur, daß der Bericht sich wegen der Anzahl der Daten in beiden Listen auf die inhaltlich gleiche Datenliste bezieht. Nachzulesen in HP_VHP.MDB
im Zusammenspiel zwischen dem Formular 'Ventile_allgemein' und dem Bericht 'Ventile_Liste'.

Allerdings muß auch hier eine bittere Pille geschluckt werden: Durch das Abnudeln eines RecordsetClone's wird eine manuelle Bildschirm-Sortierung 1 zu 1 ausgedruckt, aber auch nur ein einziges Mal; wird dieser Bericht als
Ganzseitenansicht geöffnet und zwischen den evtl. mehreren geblättert, funktioniert gar nichts mehr und es werden ausschließlich die Daten des letzten Datensatzes in allen Zeilen angezeigt.

Über evtl. globale Flags könnten Schaltvorgänge ausgelöst werden, oder noch besser: der Bericht druckt grundsätzlich in der Reihenfolge der Bildschirm-Anzeige, dafür bietet die Formular-Symbolleiste einen PushButton für 'Default-Sortierung'.

Und jetzt wieder mal Korken knallen, Feuerwerk und Jubelrufe ...

3 Jahre nach der virtuellen Datensatz-Synchronisierung a'la hp_vhp konnte das Hin- und Herblättern eines dynamisch synchronisierten Berichtes gelöst werden (Bildschirm wie auch Drucker !!!).

Ein paar Klimmzüge sind nötig, aber das Ergebnis ist die Sache wert:

Das neueste Modell kann gefunden werden unter '...Standardliste...' in SEL ADRESSEN.MDB.

Deklarationsteil:

Option Compare Database   'Verwenden der Datenbank-Sortierreihenfolge beim
Vergleich von Zeichenfolgen.
Option Explicit

Dim RS As Recordset
Dim iSeite As Integer
Dim iDataPerPage1 As Integer, iDataPerPageFF As Integer

iSeite=1 spart beim Anzeigen die Setze_Daten-Routine.
Die DataPerPage-Variablen sind handgesetzt, da mir Automatikroutinen hierfür zu aufwendig sind. Von einem Parameterformular können gewünschte Einstellungen übernommen werden, vom zu imitierenden Mutterformular wird das RecordsetClone an eine berichtsglobale Recordset-Variable übergeben und nebenbei ein Deppen-Abfrage (SELECT TOP n FROM ...) initiert, die den Bericht an eine Datenquelle bindet, die einfach nur mit der Anzahl der Daten, die auch im evtl.
gefilterten Formular zu sehen sind, übereinstimmt. Die Steuerelemente selbst sind ungebunden, aber der Bericht verhält sich wenigstens quantitativ korrekt.

Sub Report_Open (Cancel As Integer)

    iSeite = 1
    iDataPerPage1 = 32
    iDataPerPageFF = 34

    If IsFormOpen("Standardliste_Parameter") Then
       Me!txtTitel.Caption = Forms!Standardliste_Parameter!Titel
    End If

    If IsFormOpen("EditForm") Then
       Set RS = Forms!EditForm.RecordsetClone
       RS.MoveLast
       Me.RecordSource = "SELECT TOP " & RS.RecordCount & " Namesuch FROM AD;"
       RS.MoveFirst
    End If

End Sub

Für's Auge gibts dann die Vollbilddarstellung mit Wechsel:

Sub Report_Activate ()

    DoCmd Maximize

End Sub


Sub Report_Deactivate ()

    DoCmd Restore

End Sub

In Berichtskopf_Print wird RS grundsätzlich auf den ersten Datensatz eingestellt. Damit kann der Fickfehler verhindert werden, daß trotz korrekter Bildschirmdarstellung ALLER Seiten beim Drucken die erste Seite mit den Daten der zweiten gedruckt wird, wenn zuvor von Seite 2 zu Seite 1 geblättert wurde.

Sub Berichtskopf3_Print (Cancel As Integer, PrintCount As Integer)

    RS.MoveFirst

End Sub

In Detail_Print werden auf den ersten folgende Seitenwechsel erkannt, die interne Seitenvariable mitgezogen und der seitenspezifische erste Datensatz eingestellt. Die Übergabe der Recordsetfeldwerte an die Berichts-Steuerelemente
kennen wir ja schon.

Sub Detail1_Print (Cancel As Integer, PrintCount As Integer)

    If iSeite <> Me.Page Then       ' Seitenwechselbedingung tritt erst NACH
Seite 1 ein.      iSeite = Me.Page
       Setze_Datensatz              ' Startdatensatz für folgende Seitenwechsel
    End If

    If Not RS.EOF Then              ' Werte einzeln übernehmen

       Me!Namesuch = RS.Namesuch
       Me!Titel = RS.Titel
       Me!Funktion = RS.Funktion
       Me!Institut = RS.Institut
       Me!Ort = RS.Ort
       Me!Zirkel = RS.Zirkel

       RS.MoveNext

    End If

End Sub

Und hier kommts und scheint auch wirklich zu tun:
Beachtenswert die Unterscheidung zwischen erste, zweite und folgenden Seiten, da bei der zweiten Seite berücksichtigt werden muß, daß die erste Seite wegen eines Berichtskopfes evtl. weniger Datensätze enthält.

Private Sub Setze_Datensatz ()

    On Error GoTo err_Setze_Datensatz

    Dim i As Integer, iGoto As Integer

    Select Case iSeite
        Case 1:     iGoto = 0
        Case 2:     iGoto = iDataPerPage1
        Case Else:  iGoto = iDataPerPage1 + ((iSeite - 2) * iDataPerPageFF)
    End Select

    RS.MoveFirst

    For i = 1 To iGoto
        RS.MoveNext
    Next i

    Exit Sub


err_Setze_Datensatz:

    Fehler "Setze_Datensatz"
    Exit Sub

End Sub

Klar, daß im Hause Klumpp Funktionalitäten gewünscht werden, die auch diese Lösung unbrauchbar machen:

Ähnlich wie der oben beschriebene Formulardaten-Druck sollen in LITSTG Literatur-Formular-Daten als Liste ausgedruckt werden, aber mit einer eigenen Sortierung gemäß Standort-Position.

Hierfür wurde sozusagen als Rache dann doch die Temp-Tabellen-'Lösung' eingeführt, da zudem abartigste Sortierkriterien zu realisieren waren.

Bei Report_Open wird ein Parametertitel zugewiesen und die zentralen Felder des LITSTG-Formulares in eine zuvor geleerte Temptabelle geschrieben. Reihenfolge und Indizes sind egal. Eine eigene Abfrage verbindet in diesem Falle die
Tempdaten mit den Standort- und Literaturdaten, um Felder wie Titel etc. und die Sortierfelder anzeigen zu können und sortierbar zu machen. Allein der ORDER-String

ORDER BY Standort_Zuordnungen.Raum DESC, Standort_Zuordnungen.Regal, Standort_Zuordnungen.Fach, LITSTG.Standort, LITSTG.Titel;

ist eine mittlere Zumutung. Das wird aber von NT sehr flott abgearbeitet.

*

Abhängige Daten in BERICHTEN und UNTERBERICHTEN:

Zuweilen kommt es vor, daß die Angabe eines einzigen Schlüssel-Kriteriums das Verhältnis zischen zwei Datensatzgruppen nicht hinreichend beschreibt.

Die Access-Eigenschaften-Dialoge lassen aber nur Verbindungen zwischen jeweils einem Feld zu, sowohl bei Unterformularen wie auch Unterberichten.

Sind die Abhängigkeiten komplizierter, muß zu verschiedenen Lösungen gegriffen werden (Access 2.0):

Bei Unterformularen reicht es aus im Ereignis Form_Current des Hauptformulares Code auszuführen, der die Datensatzherkunft des Unterformulares neu bestimmt:

Im folgenden wird bei der Anzeige Debitoren-bezogener Daten ein ansonsten verstecktes Unterformular mit einer jeweils neuen Datensatzherkunft bestückt.

    If Me!debitor.Tag <> "" Then
       Me!UF_Kundendaten.Form.Recordsource = "SELECT * FROM kunden WHERE ttnr = '" & Me!matnr & "' AND " & Me!debitor.Tag & " = " & Me!debitor
    End If

Bei Unterberichten werden derartige Manipulationen in den Ereignissen "Beim Formatieren" etc. verweigert. Auch das Ereignis Form_Current im bezogenen Unterbericht bzw. Unterformular tritt nur ein einziges Mal nach dem Öffnen ein.

Lösung (anhand eines im Bericht eingebetteten Unterformulares):

    If IsReportOpen("ventile_maske") = True Then
       If Forms!ventile!debitor.Tag <> "" Then
          Me.Recordsource = "SELECT * FROM kunden WHERE " & Forms!ventile!debitor.Tag & " = " & Forms!ventile!debitor
       End If
    End If

Der Code wird nur ausgeführt, wenn das ansonsten auch in Formularen verwendete Unterformular im Bericht erscheint.
Für die beteiligten Datensatzgruppen bestehen Abhängigkeiten für matnr sowie Debitoren-bezogene Felder.
Im Eigenschaften-Dialog des Berichtes ist die matnr-Abhängigkeit hinterlegt, während beim Öffnen des Unterformulares die Gesamtmenge der zugrundeliegenden Daten auf dynamische Art auf die dem Kunden zugehörig beschränkt wird.

DRUCKANFORDERUNG ABFANGEN:

Klingt abenteuerlich und ist es auch !

In wenigen Worten:

In der strobelschen bestatt.mdb ist's vorzüglich gelöst, und der Weg war selbst nach Übernehmen einiger Module aus bewährten Anwendungen ein schier endloser.

Als erstes legen wir ein Makro an, das auf eine Funktion Drucken() zeigt. Diesem Makro (oder besser anders herum) wird dann eine Schaltfläche einer Standard-Symbolleiste zugeordnet. Wenn jetzt noch den Frontend-Formularen entsprechende Menüleisten-Makros zugewiesen werden, landen sämtliche Access-like aussehenden Druckanforderungen in einer selbst-geschriebenen Routine.

Function Drucken ()

    On Error GoTo err_Drucken

    Dim sForm As String, sReport As String

    sForm = Screen.ActiveForm.Name

    ' **** ist evtl. noch ein Datensatz in Bearbeitung ? ****

    If Forms(sForm).Dirty = True Then
       DoCmd RunMacro "Menübefehle.Datensatz_speichern"
    End If

Drucken_Check_Seitenansicht:

    ' **** und dann das Drama mit der Seitenansicht ****

    If Check_Seitenansicht(sForm) = True Then
       sForm = "direkt"
    End If

Weiter_Drucken:

    ' **** Formular-spezifische Druckoptionen ****

    Select Case sForm
        Case "Ventile":     DoCmd OpenForm "Ventile_Drucken"
                            Forms!Ventile_drucken.Tag = "SELECT * FROM Ventile WHERE BNR='" & Forms!Ventile!BNr & "';"
        Case "direkt":      ' **** Ausnahme: Kennlinien-Zoom Druck umleiten ****
                            sReport = Screen.ActiveReport.Name
                            If sReport = "Kennlinien_Zoom" Then
                               DoCmd OpenReport "Ventile_Grafik"
                            Else
                               DoCmd RunMacro "Menübefehle.DateiDrucken"
                            End If
        Case Else:          DoCmd RunMacro "Menübefehle.Seitenansicht"
    End Select

    Exit Function


err_Drucken:

    If Err = 2475 Then          ' kein Formular aktiv
       sForm = "direkt"
       Resume Weiter_Drucken
    ElseIf Err = 2476 Then      ' kein Bericht aktiv
       Resume Next
    ElseIf Err = 2465 Then      ' dirty nicht prüfbar
       Resume Drucken_Check_Seitenansicht
       'Beep
       'Exit Function
    ElseIf Err = 2501 Then      ' Druck abgebrochen
       Exit Function
    Else
       Fehler "Drucken"
       Exit Function
    End If

End Function

Hier können z.Bsp. Berichte vorsichtshalber in der Seitenansicht ausgegeben oder spezielle Druck-Auswahl-Dialoge geöffnet werden. Sollte das Formular bereits in der Seitenansicht dargestellt werden, so kann per 'direkt'-Fall der finale Druck-Dialog angezeigt werden und gut gewesen. Sogar Umleitungen von Zoom-Fake-Berichten an reelle Berichte sowie abgebrochene Druckausgaben werden abgecheckt.

siehe auch Check_Seitenansicht()

ANZAHL von Datensätzen in BERICHTEN:

Bekannt ist mittlerweile der Trick, sich per SELECT TOP xyz innerhalb einer dummy-Abfrage eine (hoffentlich) definierte Anzahl von Datensätzen liefern zu lassen und diese dazu zu benutzen, die Anzahl der Druck-Vorgänge innerhalb eines
Berichtes zu steuern.

Zuerst wurde diese Technik angewandt, um Berichte in der Sortierung und Filterung des Formulares erscheinen zu lassen (heftiges Recordset-Gewanke).

Spätestens der Wunsch, dem Anwender per einfachem Dialog zu erlauben, eine frei bestimmbare Anzahl von Druckvorgängen bestimmen zu lassen, stellt uns vor das Problem, eine Abfrage zu konstruieren, die auf gesicherte Weise auch größere
Mengen von Datensätzen zurückliefert.

siehe auch ANZAHL von Datensätzen in ABFRAGEN.

LETZTER DATENSATZ in einem BERICHT:

Wenn man direkt nach dem letzten Datensatz eines Berichtes etwas anfügen möchte, so muß / kann man sich hierfür eines Gruppenfußes bedienen, der unabhängig von einem Gruppenkopf gesetzt werden kann. Der eigentliche Zweck wäre, nach einer
Änderung des Inhaltes des bezogenen Feldes ein solches Zeichen zu setzen. Das kann aber durch entsprechende Einstellungen im Gruppen-Editor auch dazu benutzt werden, etwas nach dem letzten Datensatz zu tun.

Möchte man z.B. einen umlaufenden Rahmen, hat man schon alle Hände voll zu tun, im oberen Bereich diesen Rahmen auf's Pixel genau um den Titel und seitlich an den Daten entlang laufen zu lassen. Schwierig wird es aber erst, wenn unterhalb
des letzten Datensatzes eine quer abschließende Rahmenlinie gezogen werden soll, und für die angezeigten Feldinhalte keine durchlaufende, gleichbleibende Eigenschaft zur Pseudo-Gruppenbildung herangezogen werden kann. Abhilfe schafft
im Fenster 'Sortieren und Gruppieren' ein Eintrag, der sich auf einen Ausdruck a'la ="dummy" beziehen kann. Da dies reines Geseihere ist, das sich während des Druckvorganges nicht ändern wird, wird diese 'Gruppe' erst nachdem der
letzte Datensatz gedruckt ist, als beendet angesehen und siehe da, die ersehnte Linie wird gedruckt.

GRAFICKEN:

Wie sich mittlerweile herumgesprochen hat, ist es manchmal innerhalb graphischer Benutzeroberflächen und entsprechender Software auch möglich, mit bunten Bildern zu arbeiten.

So könnte ein fortgeschrittener Anwender in Versuchung kommen, in einer Tabelle neben Text-Daten auch Grafik-Daten zu speichern und diese später sogar auszudrucken. In Fällen, in denen unendlich vielen Datensätzen nur endlich viele
Grafik-Datensätze zugewiesen werden sollen, ist es sinnvoll, diese Grafiken in einer eigenen Tabelle zu speichern. In einem Bildschirm-Formular wird eine entsprechende Grafik über ein verknüpftes Unterformular angezeigt. Analog dazu
kann ein in einem Druck-Bericht ein Unterbericht eingefügt und mit diesem verknüpft werden, um entsprechende Daten auszudrucken.

Wie sich im Fall 'BOSCH HP/VHP' gezeigt hat, wird beim Formatieren eines Berichtes (vor Seitenansicht/Druck) alles, was unterhalb der Grafik ausgedruckt werden soll, auf seltsame Weise verzerrt. Im Entwurfsmodus muß quasi geraten
werden, wie die betroffenen Steuerelemente gesetzt werden sollen, damit diese beim Ausdruck ansehlich plaziert werden. War aber ein auszudruckender Datensatz nicht mit einer Grafik verknüpft, wurden die Steuerelemente korrekt plaziert.
Alle Versuche, in diesem Fall eine Dummy-Grafik zu übergeben, schlugen leider fehl.

Abhilfe konnte in diesem Fall dadurch geschaffen werden, daß der Bericht nicht mit einem Unterbericht, sondern mit einem weiteren Unterformular verknüpft wird, in dem die Größe der Grafik an die auszudruckende Größe angepasst werden kann.

Gruppierte Berichts-Bereiche auf eigenen Seiten:

Sehr beschissen war beim Erstellen eines AT/VHP-Ventile-Formelbereich-Berichtes die Tatsache, daß beim gruppierten Ausdruck (Ventil_Art), der auf jeweils einer eigenen Seite erfolgte (Seitenumbruch-Steuerelement in Gruppen-Fuß-Bereich) aber auch jedesmal eine leere Seite (aber dafür schön mit Seitenkopf) am Ende mit ausgespuckt wurde. Nach ewigem Hilfe-Gelese, Hin- und Her-Kopiere diverser Steuerelemente in den verschiedenen Berichts-Bereichen und Rumgechecke mit den Gruppierungseigenschaften hat es dann doch geklappt, obwohl ich dies beim besten Willen nicht auf eine der durchgeführten Aktionen zurückführen kann. Im Nachhinein scheint die Einstellung 'Zusammenhalten' im Gruppierungsfenster auf 'Mit 1. Detaildatensatz' = 'Der Gruppenkopf wird nur dann auf einer Seite ausgedruckt, wenn auch der erste Detaildatensatz gedruckt werden kann.' relevant zu sein.

Ich interpretiere das so, daß der im Gruppenfuß befindliche Seitenumbruch nach jedem Gruppenwechsel auch eine neue Seite ausspuckt, dies nach dem letzten Datensatz aber nicht tut, da ja dann kein weiterer Detaildatensatz mehr gedruckt
werden kann. Selbst der Gruppenname, der im Kopf erscheint, enthält jetzt sogar den Namen der Gruppe, die dann auch wirklich ausgedruckt wird. Anfangs wurde immer der Name der bereits erledigten Gruppe auf die neue Seite gedruckt.

DRECK, DRECK, DRECK !

SEITENFUß wird nicht gedruckt.

Bei allzu knapp gesetzten Rändern kann es vorkommen, daß der Seitenfuß verschluckt wird.

LAUFENDE SUMMEN in BERICHTEN

werden benötigt, wenn Werte addiert werden sollen, die nicht direkt aus der dem Bericht zugrunde liegenden Datenquelle stammen, da in diesen Fällen keine Aggregatfunktionen wie Summe(Feld1) benutzt werden können.

Wie es aussieht hat mind. Access 2.0 einen Bug, der darin besteht, daß Steuerelemente, die z.B. im Fußbereich einer Tabelle den Wert einer im Detailbereich laufenden Summe darstellen sollen, in der Seitenansicht eines mehrseitigen Berichtes manchmal verschiedene Werte anzeigen, abhängig davon, ob der Anwender die Seiten einzelnen bis zur letzten durchblättert (korrekte Werte) oder direkt zur letzten Seite springt (falsche Werte).

Eine Lösung ist mir nicht bekannt, beim Ausdruck scheint das Problem nicht aufzutreten.

UNTERFORMULARE lassen sich ebenfalls als UNTERBERICHTE einsetzen:

Das erspart die Erstellung eines speziellen Berichtes, der spätestens bei Veränderungen am Formular obendrein veralten würde. Das farbliche Erscheinungsbild des Formulares wird dann aber mit auf den Ausdruck übertragen.

Doch bevor zuviel Freude aufkommt, muß vor einem ganz eigenartigen Phänomen gewarnt werden:

Wird ein solcher Bericht, der ein Formular als Unterbericht enthält, das selbst in diesem Augenblick geöffnet ist, aufgerufen, kommt es zu einem Verlust der Formular-globalen Variablenwerte. Typisch: Der Anwender will einen
Formularausdruck einer Adresse, die er gerade auf dem Monitor darstellt. Mit dieser Technik funktioniert das zwar, aber beim Blättern zum nächsten Datensatz treten Schaltflächen-Farbfehler etc. auf .

Der Reiz dieser Lösung war aber zu groß, als daß ich das unerledigt adakta legen wollte.

An dem unerfreulichen Phänomen der Reinitialisierung der Formular-globalen Variablen ließ sich nichts ändern; also begab ich mich an der Abspeckung der deklarierten Variablen, und siehe da, so können z.B. Farbwerte auch ruhig mal
hart codiert im Sourcecode stehen und Werte, auf die in verschiedenen Routinen innerhalb des Formulares zugegriffen werden muß, können dann anstatt als Wertezuweisung in Form_Open auch schon mal durch eine simple Funktion gesetzt
werden. Das entspricht nicht unbedingt den Lehren der hohen Schule der Programmierkunst, erlaubt mir aber, die charmante Sache mit den sich selbst aktualisierenden Unterformular-Berichten aufrecht zu erhalten und Knalleffekte
in den Formularen trotz Reinitialisierung zu vermeiden.