Startseite » Papyrus allgemein » Noch besser machen » Verhalten des Report-Button
| Verhalten des Report-Button [Beitrag #9689] |
Fr, 27 Januar 2012 11:29  |
DeGeFe
Beiträge: 14 Registriert: August 2008
|
Junior Member |
|
|
|
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.
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9765 ist eine Antwort auf Beitrag #9689] |
Di, 21 Februar 2012 15:22   |
DeGeFe
Beiträge: 14 Registriert: August 2008
|
Junior Member |
|
|
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
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9810 ist eine Antwort auf Beitrag #9765] |
Di, 28 Februar 2012 20:06   |
blake
Beiträge: 273 Registriert: Januar 2008
|
Senior Member |
|
|
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.
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9965 ist eine Antwort auf Beitrag #9961] |
Mo, 19 März 2012 00:01   |
blake
Beiträge: 273 Registriert: Januar 2008
|
Senior Member |
|
|
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.
[Aktualisiert am: Mo, 19 März 2012 00:05] Den Beitrag einem Moderator melden
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9975 ist eine Antwort auf Beitrag #9974] |
Mo, 19 März 2012 20:44   |
blake
Beiträge: 273 Registriert: Januar 2008
|
Senior Member |
|
|
| dotpap schrieb am Mo, 19 März 2012 19:39 | Die Lösung stellt zum Thema "Report" meiner Ansicht nach kein schlüssiges Bedienkonzept für die BASE-Umgebung dar.
|
Versteh ich jetzt nicht...
|
|
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9983 ist eine Antwort auf Beitrag #9965] |
Di, 20 März 2012 15:04   |
Markus Lutz
Beiträge: 237 Registriert: Januar 2010
|
Senior Member |
|
|
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.
Gruß
Markus
Papyrus Autor
ubuntu & wine
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9985 ist eine Antwort auf Beitrag #9983] |
Di, 20 März 2012 17:50   |
blake
Beiträge: 273 Registriert: Januar 2008
|
Senior Member |
|
|
| Markus Lutz schrieb am Di, 20 März 2012 15:04 | Wenn man nun über "REPORT" auch gleich die Dateinamen vergeben könnte, wäre das für mich eine große Arbeitserleichterung.
| 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.
| Zitat: | Das hat aber niemand in die Hilfe übertragen.
|
Tja, das wär mal was...
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9986 ist eine Antwort auf Beitrag #9985] |
Di, 20 März 2012 18:11   |
Markus Lutz
Beiträge: 237 Registriert: Januar 2010
|
Senior Member |
|
|
| blake schrieb am Di, 20 März 2012 17:50 |
| Markus Lutz schrieb am Di, 20 März 2012 15:04 | Wenn man nun über "REPORT" auch gleich die Dateinamen vergeben könnte, wäre das für mich eine große Arbeitserleichterung.
| Naja, das wird nicht recht funktionieren.
|
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.
Gruß
Markus
Papyrus Autor
ubuntu & wine
[Aktualisiert am: Di, 20 März 2012 18:12] Den Beitrag einem Moderator melden
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #9988 ist eine Antwort auf Beitrag #9986] |
Di, 20 März 2012 18:38   |
glucose
Beiträge: 791 Registriert: Januar 2008 Ort: Berlin
|
Senior Member |
|
|
| Markus Lutz schrieb am Di, 20 März 2012 18:11 | Sondern ich dachte an den Namen der Ergebnisdatei, die z.B. "Rechnung-" + Rechnungsnummer + ".pap" heißen könnte.
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #10097 ist eine Antwort auf Beitrag #10096] |
Do, 05 April 2012 09:59   |
blake
Beiträge: 273 Registriert: Januar 2008
|
Senior Member |
|
|
Also ich finde es sehr angenehm flott, das Papyrus hier nicht fragt. Man sollte sich vorher eben überlegen, ob und was man automatisch (!) speichern will.
Bei einer Namenskombination aus Datum und Uhrzeit und so benötigt auch dem Benutzerkonto KANN hier eigentlich keine bestehende Datei überschrieben werden.
Normale Texte werden ja über das Dateimenü gespeichert, da gibt es die Überschreibungswarnung ja.
Ich benutze die SAVE funktion nur für Rechnungen, Name, Datum und gut. Wenn ich dann die Rechnung noch mal korrigieren muss, wird die falsche(!) Datei automatisch überschrieben. Angenehm, weil flott. Eine wegzuklickenden Hinweis fände ich da nur störend.
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #10100 ist eine Antwort auf Beitrag #10097] |
Do, 05 April 2012 10:41   |
Markus Lutz
Beiträge: 237 Registriert: Januar 2010
|
Senior Member |
|
|
| blake schrieb am Do, 05 April 2012 09:59 | Also ich finde es sehr angenehm flott, das Papyrus hier nicht fragt. Man sollte sich vorher eben überlegen, ob und was man automatisch (!) speichern will.
Bei einer Namenskombination aus Datum und Uhrzeit und so benötigt auch dem Benutzerkonto KANN hier eigentlich keine bestehende Datei überschrieben werden.
Normale Texte werden ja über das Dateimenü gespeichert, da gibt es die Überschreibungswarnung ja.
|
Das stimmt für Reports, die nicht nachbearbeitet werden.
Da ich die bei mir in Frage kommenden Reports immer auch noch von Hand weiterbearbeiten muss, könnte es sehr wohl sein, dass dieselbe Datei dann bereits existiert.
Also ich kann nur nochmals betonen, es wäre wichtig, auch eine Funktion zu haben, bei der Pfad und Name von Reports vorgegeben werden kann, aber eben nicht automatisch abgespreichert wird.
| Zitat: |
Ich benutze die SAVE funktion nur für Rechnungen, Name, Datum und gut. Wenn ich dann die Rechnung noch mal korrigieren muss, wird die falsche(!) Datei automatisch überschrieben. Angenehm, weil flott. Eine wegzuklickenden Hinweis fände ich da nur störend.
|
Ich möchte ja auch nicht, dass die SAVE-Funktion wegfällt. Die ist sinnvoll, aber es sollte auch die andere Möglichkeit geben.
Gruß
Markus
Papyrus Autor
ubuntu & wine
|
|
|
|
| Re: Verhalten des Report-Button [Beitrag #10111 ist eine Antwort auf Beitrag #10100] |
Do, 05 April 2012 17:03  |
glucose
Beiträge: 791 Registriert: Januar 2008 Ort: Berlin
|
Senior Member |
|
|
| Markus Lutz schrieb am Do, 05 April 2012 10:41 |
Da ich die bei mir in Frage kommenden Reports immer auch noch von Hand weiterbearbeiten muss, könnte es sehr wohl sein, dass dieselbe Datei dann bereits existiert.
|
Genau das ist auch mein Problem. Deshalb bräuchte ich zumindest eine Funktion, mit der die Existenz einer Datei geprüft werden kann.
|
|
|
|
Gehe zum Forum:
aktuelle Zeit: So Mai 19 21:14:07 CEST 2013
Insgesamt benötigte Zeit, um die Seite zu erzeugen: 0.01794 Sekunden
|