Deutsch

Hintergrund

Optimale Gestaltung Arbeitsumgebung im Designer

Code-Bereich einblenden

Konvertieren von MS-Access-Berichten

Datenquellen-Design

Immer ein Selektionselement benutzen!

Das richtige Ein- und Ausblenden von Elementen

Deutsch

Hintergrund

Beim Bauen von Berichten mit dem Sage AppDesigner gibt es einige Punkte , die als Anforderungen immer wieder auftauchen und die man beachten sollte.

Die AppDesigner-Berichte basieren auf der Report-Engine von https://www.stimulsoft.com/en.

Optimale Gestaltung Arbeitsumgebung im Designer

Eine ausreichende Bildschirm-Auflösung vorausgesetzt , ist es empfehlenswert , den "Eigenschaften"-Zweig im Designer zu separieren.

Durch das Entkoppeln hat man den Vorteil , dass die "Eigenschaften" (Properties) eines ausgewählten Elements immer sofort sichtbar sind.

Code-Bereich einblenden

Sage blendet den Code-Bereich standardmäßig aus!

Um den Code-Bereich zu aktivieren , klickt man im "Berichtsbaum" den gesamten Bericht an. Dann benutzt man im oberen Teil auf der Seite die rechte Maustaste und aktiviert den Code-Bereich wieder.

Konvertieren von MS-Access-Berichten

Ein häufiges Anforderungszenario ist die Übernahme von MS-Access-Berichten aus alten Legacy-Projekten in den AppDesigner.

Es ist möglich , den Übernahme-Assistenten im AppDesigner anzustoßen.

Dazu legt man im AppDesigner im Bereich für die "Berichte" eine Unterkategorie an , falls noch nicht geschehen.

Auf der Unterkategorie benutzt man dann die rechte Maustaste.

Im Konvertierungsprogramm kann man die MS-Access-Datei und den Bericht auswählen , den man konvertieren möchte.

⚠️Folgende Tipps sollte man beachten:

• Man sollte zuerst dringend die Datenquelle des Berichts prüfen , den man übernehmen will , und dann diese Datenquelle zuerst im AppDesigner vorbereiten und korrekt anlegen. Dann gibt man im Konvertierungsprogramm die Datenquelle an.

  Das Konvertierungsprogramm bezieht sich auf die Haupt-Datenquelle des Berichts.

• Die Feldzuweisungen des Konvertierungsprogramms zur Datenquelle im AppDesigner wird von Sage oft als fehlerhaft bemängelt 😱. D.h. obwohl die Feldnamen richtig im StimulSoft-Berichtsdesigner zugwiesen sind , kommen z.B. bei der Druckvorschau "abstruse" Fehler mit Bezug zu angeblich falschen Feldnamen! In diesem Fall empfehlen wir , im konvertierten Bericht alle Feldnamen wieder zu entfernen , den Berichtsentwurf abzuspeichern und in den Eigenschaften des Berichts die Datenquellen neu zu setzen.

• Das Konvertierungsprogramm konvertiert keinen Quellcode. Dieser wird auskommentiert in den Code-Bereich übernommen.

• Summenfunktionen werden vom Konvertierungsprogramm oft falsch übernommen. Mit der MS-Access-Syntax , die in StimulSoft nicht richtig funktioniert. Eine korrekte Summenfunktion sieht in StimulSoft wie folgt aus:

{Sum(dtsAvisPos.ZAHLBTR)}

• Der in VBA weit verbreitete Ansatz , z.B. über VBA-Code Felder ein-/auszublenden ist in StimulSoft obselet und sollte nicht benutzt werden. Stattdessen empfiehlt es sich , mit Bedingungen zu arbeiten (siehe nachfolgende Tipps).

Datenquellen-Design

Ein Bericht kann nur eine Haupt-Datenquelle , jedoch n untergeordnete Datenquellen haben.

Es empiehlt sich dringend , SQL-Datenquellen zu benutzen , d.h. "normale" Datenquellen im AppDesigner , da diese performant sind. Datenquellen , die an Geschäftsprozesse gebunden sind , sind deutlich langsamer!

Wenn man mehrere Datenquellen benutzt , dann hat man verschiedene Wege , diese an ein einheitliche Schlüssel-Struktur zu binden.

Wenn man im Bericht mit diversen untergeordneten Datenquellen arbeitet , dann kann man die Datenquellen im Berichtsentwurf in einer Beziehung zu einander bringen.

Dies ist sinnvoll , wenn man mit verschachtelten Berichtsbändern arbeitet , so dass der Berichtsgenerator beim Rendern des Berichts weiß , wie die Daten zueinander in Beziehung stehen.

Der klassische und sicherste Weg ist es allerdings , direkt in der WHERE-Bedingung der Datenquelle die entsprechenden Parameter immer anzugeben , mit denen sich die Datensätze gezielt filtern lassen.

Beispiel:

Hdr.Mandant = @Mandant 
  AND Hdr.[Tan] = CFN_Parameter('pSAGAvisTan') 
  AND Hdr.[Typ] = CFN_Parameter('pSAGAvisTextTyp')

Hier kommen die "berühmt berüchtigten" Sage-Parameter-Funktionen wie "CFN_Parameter" zum Einsatz. Berichte sollten immer sinnvolle Parameter-Filter direkt enthalten , da davon auszugehen ist , dass die Daten immer sinnvoll gefiltert werden müssen!

Sobald man einen solchen Parameter in der Datenquelle in der WHERE-Klausel definiert hat , erkennt dies der AppDesigner und bietet bei der Vorschau der Datenquelle einen Dialog an , um Test-Parameter zu befüllen.

Beim Definieren der Parameter sollte man dringend darauf achten , die korrekten Datentypen anzugeben.

In Selektionselementen (siehe nächster Punkt) legt man in der Datenstruktur (str) die Parameter mit genau diesen Namen an , wie in der Datenquelle angegeben! Diese Parameternamen sind auch bei der Verwendung von "OpenReport" in Makros so anzugeben.

Beispiel:

Beispiel für den Aufruf des Berichts mit "OpenReport" aus einem Makro:

Immer ein Selektionselement benutzen!

Es empfiehlt sich , auch dann ein Selektionselement (sel) mit einer Datenstruktur (str) zu benutzen , wenn man den Bericht später z.B. aus einem Makro mit Parameter-Übergabe aufrufen möchte.

Das Selektionselement trägt man im Bericht ein: es kann später problemlos bei Makro-Aufrufen unterdrückt werden , wenn man selber die Berichtsparameter aus Makros befüllt!

Der Grund dafür , dass man immer ein Selektionselement vorschalten sollte , ist ganz einfach:

Auf diese Weise lassen sich Berichtsentwürfe sehr schnell direkt im AppDesigner testen - das spart in der Praxis enorm viel Zeit! 👍🏻

Das richtige Ein- und Ausblenden von Elementen

Inbesondere Techpartner , die aus der MS-Access-Welt kommen , bevorzugen das Ein- und Ausblenden von Elementen in Abhängigkeit von Bedingungen per Quellcode.

Dieser Ansatz per Quellcode ist nicht performant und nicht der von StimulSoft empfohlene Ansatz; außerdem funktioniert das in der Praxis oft gar nicht (mehr).

Stattdessen sollte man dringend mit Bedingungen arbeiten und diese an Ausdrücke binden.

Nachfolgend ein einfaches Beispiel.

Die Definition der Bedingung ist recht einfach. Man kann Ausdrücke verwenden und entsprechend logisch kombinieren.

Im vorliegenden Fall wird auf einen an den Bericht übergebenen Parameter zugegriffen.

Ist dieser Parameter deaktiviert (=False) , dann soll in diesem Fall die Komponente nicht aktiviert werden , was im Quellcode folgende Anweisung wäre:

Me.MyComponent.Enabled = False 

Die Verwendung von Bedingungen ist performanter , der von StimulSoft empfohlene Weg und funktioniert i.d.R. viel zuverlässiger als das Aktivieren/Deaktivieren von Elementen in Quellcode.