Meines Erachtens nach ist es nicht sinnvoll, die Frage, ob ein Standardreport ausgeführt, oder das Menü Report geöffnet werden soll, global, für alle Datenbanken, einzustellen. Eigentlich wäre diese Einstellung in den spezifika einer Datenbank besser aufgehoben.
… ja, dieser Meinung möchte ich mich auch anschließen.
Hallo ,
ich möchte mich noch einmal zu meinem Vorschlag äußern, da er m.E. eine hilfreiche Sache ist, die nicht sofort ins Auge springt. Die Frage, ob ein Standardreport sofort ausgeführt wird, oder ob ich lieber in einer Liste von möglichen Reports auswählen möchte, hängt vom Zweck der Datenbank ab. Allerdings gibt es da verschiedene Zwecke und Komplexitätsgrade. Ein “kleines Helferlein” mit nur einem Datensatz und ein paar Rechenfunktionen drin, braucht nur einen Standardreport und man drückt den Reportbutton und hat das Ergebnis sofort in sein Dokument eingefügt, Eine Kundendatenbank, aus der ich entweder eine Rechnung, eine Monatsübersicht oder sonstwas rauslassen möchte braucht die Wahlmöglichkeit. Die bisherige Lösung in Papyrus sieht eine globale Einstellung vor, also einmal eingestellt – gilt für alles gleichermaßen …
Mein Vorschlag ist, das Verhalten des Reportbuttons in den Einstellungsdialog jeder einzelnen Datenbank aufzunehmen anstatt in den globalen Einstellungen zu belassen.
Gruß,
DEGEFE
Ich denke, das das gewünschte Verhalten von Datenbank zu Datenbank variiert, sogar von Tabelle zu Tabelle.
Allerdings ist mir auch die Lösung “in Datenbank speichern” hier zu kurz gesprungen, wie gesagt, das gewünschte Verhalten ändert sich ja sogar bei einzelnen Tabellen. Mein absoluter Favorit wären Hyperlinks, die einen Report auslösen könnten, am besten mit der Option, sie Bildern zuzuordnen. Dann könnte ich den einzelnen Reports in der Eingabemaske Bilder zuweisen, als optisch orientierter Mensch liegt mir das am meisten.
Allerdings gibt es schon jetzt eine bequeme Möglichkeit, verschiedene Reporte mit EINEM Mausklick auf Report auszuführen: Man legt ein Feld, z.B “gewünschter_Report” an und programmiert hier das gewünschte Verhalten, also:
IF gewünschter_Report=“Rechnung” THEN REPORT(“Rechnung.pap”) ELSE
IF gewünschter_Report=“Mahnung” THEN REPORT(“Mahnung.pap”) usw.
Das ist besonders komfortabel, weil so auch mehrere Reporte mit einem klick ausgelöst werden können. Mein Highscore ist hier Rechnung drucken, Versandetikett drucken und Email an Kunden. Mit einem Klick.
Hallo blake,
deine Bemerkungen zu der Reportauswahl klingen sehr interessant und ich bräuchte genau diese Möglichkeit für eine komplexere Datenbank, bei der Reports abhängig von bestimmten Werten ausgewählt werden sollen. Leider kann ich anhand deiner Kurzbeschreibung allerdings nicht nachvollziehen wie das von dir geschilderte Verfahren genau funktioniert.
Ich habe es so verstanden, dass in der Tabelle ein Datenfeld mit dem Namen “gewünschter_Report” vom Typ Text(?) angelegt wird, in dem man auswählt, welche Art von Report man haben will. Dann braucht man vermutlich noch ein zweites Feld mit einem beliebigen Namen, das die besagte Rechenformel enthält. Wie das dann aber konkret einen Report erzeugen soll oder gar mehrer Reporte über einen Mausklick anstoßen soll, ist mir völlig schleierhaft.
Vermutlich sitze ich hier auf der Leitung oder habe das Handbuch und das Forum eine Stunde zu wenig lang durchsucht, aber mir fällt nichts dazu ein. Deshalb wäre ich um eine nähere Erläuterung oder gar eine Beispieldatei sehr dankbar…
Mit neugierigem Gruß
Papyrusfan
Du brauchst in der Datenbank nur **ein **neues Feld anlegen, ich nenne es mal Reportbefehl.
In einer Wertetabelle (zur Vermeidung von Tippfehlern) hinterlegst du die (beliebigen) Namen, bei einer Faktura also Rechnung, Mahnung, usw.
Gerade wenn der Druck von Werten abhängt (Mahndatum o.ä.) kann das Feld den Wert sogar automatisch errechnen.
Der Trick ist, jetzt einen zusätzlichen Standardreport anzulegen, ich nenne ihn mal Druckzentrum.
Und der sollte einfach nur aus einem (!) Datenfeld bestehen, mit den schon erwähnten Formeln. Diese müssen die Namen/Dateipfad deiner für diese Tabelle schon angelegten Reporte haben. Als Ausgabe kein Dokument wählen, sondern “nur Formeln ausführen”
Dann passiert folgendes:
bei Aufruf des Reportbuttons wird der Standardreport ausgeführt.
Das ist der neue Report **Druckzentrum **und der schaut nach, was im Feld Reportbefehl steht und führt den entsprechenden Report aus. Das kann ein neues Dokument erzeugen, drucken, weiter Befehle usw. sein.
Rumprobieren, ist ein bißchen kniffelig, aber es funzt und ist seeehr flexibel.
Hallo.
Eine clevere Lösung. 
Von Praktiker für Praktiker.
Die Lösung stellt zum Thema „Report“ meiner Ansicht nach kein schlüssiges Bedienkonzept für die BASE-Umgebung dar.
Versteh ich jetzt nicht…
Hallo blake.
Papyrusfan hat seinen Angaben nach eine “komplexere Datenbank”. Er hat Wissen. Dennoch versteht er (sie) Deine clevere Lösung nicht auf Anhieb.
Ich denke die Umsetzung des guten Vorschlags von DeGeFe im Zusammenhang mit der Weiterentwicklung von BASE ist der bessere Weg. Wie weit das vorangetrieben werden kann liegt an R.O.M.
Hier gilt: je weiter desto besser.
Achso, ja klar, das sehe ich ja genauso!
Das ist ja eine sehr interessante Lösung, die ich mir mal gleich zu eigen gemacht habe.
Wenn man nun über “REPORT” auch gleich die Dateinamen vergeben könnte, wäre das für mich eine große Arbeitserleichterung.
Ulli, wenn das noch nicht geht, würde ich mich über eine Erweiterung freuen. Dann könnte ich nämlich ganz einfach und automatisch die Dateinamen von Reports im bisher verwendeten Format vergeben.
Wo ist der Befehl eigentlich dokumentiert. In der Hilfe habe ich dazu nichts gefunden.
Er war mal in den Neuerungen 2008 dokumentiert (siehe Anlage). Das hat aber niemand in die Hilfe übertragen.
History_2008.pap (37.4 KB)
Naja, das wird nicht recht funktionieren. Meine Reporte haben sich schon öfters verbessert, also geändert. Das charmante an der Methode ist unter anderem, das die Werte des Datenbankfeldes sich nicht ändern müssen, während die Reporte und deren Namen sich ändern können. Zum Beispiel habe ich einen Report Rechnung mit Briefpapier um Rechnungen auf vorgedrucktem Firmenpapier auszudrucken. Für alle Fälle habe ich aber auch einen Rechnungsreport für den Fall, das das Briefpapier mal alle ist. Für den Bediener ändert sich nichts, den Report für den Datenbankfeldwert “Rechnung” leite ich dann einfach um.
Desweiteren kann man auch Reporte verketten, also mit AND mehrere Reporte hintereinander ausführen lassen. Das kann Papyrus schlecht automatisch bewerkstelligen.
Tja, das wär mal was…
Ich weiß nicht recht, vielleicht habe ich mich etwas unverständlich ausgedrückt. Ich meine nicht den Namen des Reports - warum sollte ich den anders als manuell ändern? (obwohl es da evtl. auch Möglichkeiten gäbe, über andere Felder zusätzlich unterschiedliche Reports anzusteuern) -.
Sondern ich dachte an den Namen der Ergebnisdatei, die z.B. “Rechnung-” + Rechnungsnummer + “.pap” heißen könnte. Oder eben:
“Ergebnis-” + Datum + “.html” oder so ähnlich.
Ich stelle mir das z.B. so vor: REPORT (“Report.pap”,“Report-” + CURDATE() + “.pap”) ergibt dann eine Datei, die dann “Report-20120320.pap” heißt. Wenn man dann noch als dritten Parameter den Zielordner angeben könnte, wäre das ziemlich cool.
Hallo Markus Lutz.
Dann musst Du “SAVE()” benutzen.
Mit akt. papyrus-Version wird wohl auch der Ordner (so noch nicht vorhanden) automatissch erzeugt.
Mit der Report-Funktion kann man nur festlegen, welche Reportvorlage verwendet und ausgeführt werden soll.
Dein Wunsch lässt sich aber mit der SAVE()-Funktion realisieren, die jedoch in der entsprechenden Reportvorlage untergebracht werden muss:
SAVE(“Rechnung-” + STR(Rechnungsnumer) + “.pap”)
sollte funktionieren. Normalerweise wird im gleichen Ordner gespeichert wo auch die Reportvorlage liegt. Gegebenenfalls muss man also noch einen Pfad voranstellen. Am besten als Variable in der Datenbank, sodass man sie auch an anderer Stelle verwenden und im Bedarfsfall einfach ändern kann.
Wie oben zu sehen, sollten Zahlenwerte vorsichtshalber in Zeichenketten gewandelt werden (mit STR()), sonst kann es zu Nebeneffekten kommen. Auch ein Datum sollte so behandelt werden.
Das größte Problem der SAVE-Funktion ist aus meiner Sicht, dass sie ohne Rücksicht auf Verluste speichert. D.h. wenn die Zieldatei schon existiert, wird sie stillschweigend überschrieben.
Danke.
Die SAVE-Funktion funktioniert ganz gut.
Ich fände aber eine Warnung beim Überschreiben - und nur da! - unbedingt notwendig!
Vielen Dank,
das klappt überraschend gut …
Hallo in die Runde.
nur der Vollständigkeit wegen…
Das nicht beeinfussbare Überschreiben von Dateien … kann oft darüber entscheiden, ob save() überhaupt genutzt werden kann oder nicht.
Um sofort einen Schutz vor dem Überschreiben einer Datei unter Verwendung von “save()” zu haben, könnten ggfs. die Möglichkeiten von WSH (Windows Script Host) geprüft und ggfs. genutzt werden.
Prinzipielle Vorgehensweise.
Die entsprechende DB-Tabelle erhält zwei neue DB-Felder - nämlich “Script” und “ZuVergebenderDateiname”.
“Script”
Das DB-Feld entält das Script.
Besonderheit: Es wird automatisch an den neuen zu vergebenden Dateinamen angepasst.
Dazu muss es mit dem u.g. DB-Feld “ZuVergebenderDateiname” korrespondieren (Rechenfeld).
“ZuVergebenderDateiname”
In dieses DB-Feld gibt der Anwender den von ihm angedachten Dateinamen inkl. Pfad in Anführungszeichen ein.
So, dann wird ein geeignetes VBS-Script (VBS = Visual Basic Script) wohl am Besten in den Windows-Systemordner gelegt.
Außerdem werden der Datenbank noch zwei Report-Vorlagen hinzugefügt:
- Report-Vorlage
sie leistet, dass sich die im Windows-Systemordner befindliche VBS-Datei bei jeder Anfrage selbst überschreibt.
Report-Einstellung: “Keine Ausgabe (nur Formeln ausführen)”
- Report-Vorlage
Führt den Anwender mittels MessageBox solide durch den eigentlichen Speicher-Vorgang.
U.a. wird die Report-Vorlage unter 1. aufgerufen und natürlich wird ggfs. mit save() gespeichert.
Report-Einstellung: “Keine Ausgabe (nur Formeln ausführen)”
Viele Anwender wissen nicht, ob sie WSH überhaupt (noch → Windows 7) auf ihren Windows-PC installiert haben.
Diese Frage kann schnell und unkompliziert (u.a. auch mit einem kleinen Script) gecheckt werden.
Hmm, ich finde das reichlich kompliziert. Die Datenbank wäre dann auch nur noch unter Windows lauffähig. Und ob wohl der Windows-Systemordner der richtige Ort für ein Datenbank-spezifisches Script ist? Ein Unterordner “scripts” im Datenbankordner erscheint mir da passender.
Am liebsten wäre mir, das Papyrus einfach nachfragt, bevor es eine Datei überschreibt. Alternativ wäre eine Funktion file_exists(filename) hilfreich, mit der man das Überschreiben selbst verhindern könnte.