q_rep Problem

[Geri12]

Eine neue GDB ist auf jeden Fall gut. Ich hatte die beiden Felder in Tabelle, Tabellen-Trigger, View und View-Trigger in 10 Minuten eingefügt. Das geht allemal schneller als noch weiter mit der (versemmelten) bisherigen GDB rumzutesten.

Bei den beiden Domains kann man nichts falsch machen, egal ob D_ALPHA30NULL oder D_ALPHA50NULL.

[schluppenmann]

Die GDB war definitiv "versemmelt"
Mit der neuen GDB gehts nämlich auf Anhieb...

RIESEN DANKESCHÖN erstmal...

Jetzt sprichst du gerade Tabellen-Trigger an... Bisher hab ich immer nur die View-Trigger erweitert (ich meine ich habe bei dem SWIFT Beispiel aus der Tabelle BSBANK in den Tabellen-Triggern keinen Eintrag über das Feld SWIFT gefunden und habe mich deswegen nur auf die View-Trigger konzentriert)
Was änderst du denn, auf unser Beispiel bezogen, an den Tabellen-Triggern ?

[Geri12]

PRIMA und Glückwunsch

Meine Herren, das war aber eine schwere Geburt ! Wie nennen wir den Kleinen denn jetzt

Bei den Tabellen-Triggern brauchst Du im Moment nichts einzutragen.

Ansonsten läßt sich dort z.B. bei einem BU-Trigger eintragen, dass leere Textfelder auf den Zustand NULL zurückgesetzt werden. Wenn man nämlich in ein Textfeld was einträgt und danach wieder löscht, dann kann man in der Maske nicht mehr über IS (NOT) NULL suchen. Wenn Du dann alle Sätze _OHNE_ Eintrag suchst, musst Du 2* suchen: einmal nach Feldinhalt IS NULL und einmal nach Feldinhalt =''
Ist alles Leere automatisch auf NULL zurückgesetzt, ist es für den Benutzer einfacher bei der Suche.
Oder Relationsfelder, die keine Pflichtfelder sind und nach Eintrag + Löschen den ID-Wert = 0 haben lassen sich wieder auf NULL zurücksetzen. Oder es lassen sich Felder mit einem Vorgabewert füllen (Bsp.: Ländercode 'D'). Oder oder ...

Da gibt's schon noch schöne Sachen

[schluppenmann]

Mit einer sauberen DB wäre das Ganze sicherlich schneller über die Bühne gegangen Aber aus Fehlern lernt man ja bekanntlich.
Jetzt muss ich die drei Felder nur noch auf den DruckReport bekommen

Ist das viel Aufwand ? Ich les gerade parallel in der Doku... Aber das Thema ist hier recht dürr gehalten, bzw mit Verweis auf die englischsprachige Doku des FastReport...

[Geri12]

Das ist genau so "viel" Aufwand wie der Einbau der Felder in die Datenmaske

Report: FRDCMLISMB
Designer -> Werkzeuge -> (DB-Feld einfügen)
Im Fenster DB-Feld einfügen -> q1 auswählen
Von q1 -> entspr. Felder mit Maus greifen und auf das Formular ziehen
Speichern nicht vergessen

Et voila ...

[schluppenmann]

*APPLAUS*
es klappt

Riesen Dank für deinen Support und deine Geduld.


Mal ne Frage zum Label....
Statische Labels sind ja kein Problem, aber gibts es auch Labels im Report, die nur dann im Druck erscheinen, wenn auch etwas vorher in der Maske in meine Felder eingetragen wird.
Es kommt ja auch vor, dass wir Ersatzteile per Kurier/Paketdienst verschicken, bei denen zwar ein Lieferschein gedruckt werden muss, aber keine Angaben zur Spedition. Wenn ich jetzt feste Labels im FastReport gesetzt habe ( zB: Name der Spedition, Fahrername und Kennzeichen) werden diese ja dann mitgedruckt, auch wenn keine Eingabe in die drei neuen Felder erfolgt....
Ist das möglich ?

[Geri12]

Ja, ist machbar: entweder im Band.OnBeforePrint oder auf dem Label.Memo selbst. Einfach mal ein paar davon anschauen, das ist die beste Übung ...

[schluppenmann]

Ja, ist machbar: entweder im Band.OnBeforePrint oder auf dem Label.Memo selbst. Einfach mal ein paar davon anschauen, das ist die beste Übung ...

Muss ich auf etwas Besonderes achten ? Habe mir beide angeschaut, aber der Groschen ist jetzt nicht unbedingt gefallen. Wo sehe ich denn wovon AvERP es anhängig macht das Label zudrucken oder halt nicht zu drucken. Ich für mich weiß ja, dass er nicht drucken soll, wenn keine Eingabe in dem entsprechenden Feld gemacht worden ist...

[Geri12]

Muss ich auf etwas Besonderes achten ?

Die Eigenschaft "visible". Durch Voranstellen des Objektnamens kann bei entspr. Bedingung jedes Element "unsichtbar" geschaltet werden. Bei Textobjekten besteht noch die Möglichkeit, den Inhalt zu löschen (z.B. durch "memo.clear();").

Bsp. siehe Ausdruck FRDCMAUSMB
1. Band "bdSeriennummern", Methode "OnBeforePrint"
2. Objekt "LB_ZZGLMWST", Methode "Memo"

[schluppenmann]

Na da beißt doch die Maus ...

Das würde ich nicht als "Rechtsangelegenheit" betrachten. Hier stimmt die Relations-Zuordnung Feld <-> View nicht.

Bitte scrolle mal in der Designsteuerung horizontal. Direkt die nächste Spalte nach SOURCETABLE ist CONTEXTNAME. Steht hier bei Deinen neuen Feldern jeweils "A"

Übrigens weiß ich jetzt wieso es zu dem Fehler kam.
Ich bin gerade dabei die drei Felder in die echte DB zu übertragen und der Fehler kam wieder...
Ursache: Ich habe in der View V_BRLS die drei neu-angelegten Felder an das Ende der CREATE Liste gepackt und in der SELECT-Liste ans Ende der "a." Aufrufe (--> BRLS A), da diese drei Felder ja noch zur BRLS gehören. Jetzt stimmt aber das Verhältnis nicht zwischen den beiden Listen, da die drei Felder in der CEATE Liste an den Positionen 61/62/63 liegen, aber in der SELECT Liste schon auf 31/32/33...
Die View fügt immer Position <=> Postion ein, ergo wird der CREATE Position 61 auch die SELECT Position 61 zugewiesen, was in meinem Beispiel die Tabelle BANSP ist (siehe Screenshot in einem meiner letzteren Beiträge)...
Man muss also darauf achten, dass die Position der Feldes in beiden Listen identisch ist.

Ich hoffe das habe ich jetzt verständlich rübergebracht Ansonten fragt nochmal nach, wenn ich mich nicht korrekt ausgedrückt habe...

[Geri12]

Hätte man eigentlich nach genauestem Studium der ff. Zeilen erkennen sollen ...

Code: Alles auswählen

CREATE VIEW V_BRLS ( 
... 
SPEDNAME, 
SPEDFAHRER, 
SPEDKZ) 
AS 
SELECT 
... 
A.SPEDNAME, 
A.SPEDFAHRER, 
A.SPEDKZ, 
... 
FROM BRLS A 
... 
; 

... dass die neuen Felder in der Spaltenbezeichner-Liste am Ende liegen, in der Liste der Tabellenspalten im SELECT allerdings mitten drin

Nichtsdestotrotz Fehler selbst gefunden und beseitigt

[schluppenmann]

Die Eigenschaft "visible". Durch Voranstellen des Objektnamens kann bei entspr. Bedingung jedes Element "unsichtbar" geschaltet werden. Bei Textobjekten besteht noch die Möglichkeit, den Inhalt zu löschen (z.B. durch "memo.clear();").

Bsp. siehe Ausdruck FRDCMAUSMB
1. Band "bdSeriennummern", Methode "OnBeforePrint"
2. Objekt "LB_ZZGLMWST", Methode "Memo"

Frage hierzu...
Ich habe die drei Felder in den Report eingefügt und jedem Feld je ein Memo voran gestellt... im Objektinspector habe ich unter Memo folgendes eingetragen

Code: Alles auswählen

if ([q_rep1."SPEDNAME"] <> '') then memo.clear;

Ich habe daraufhin in der Maske alles ausgefüllt (auch die drei neuen Felder) und des Lieferschein gedruckt. Die Labels wurden allerdings nicht gedruckt.
Was bewerkstelligt den memo.clear genau bzw was wird denn gelöscht ?

Wäre dieser Code nicht logischer

Code: Alles auswählen

if ([q_rep1."SPEDNAME"] <> '') then memo.Visible := False;

Konnte es bis dato nicht testen, weil der Server momentan gewartet wird...

[Geri12]

Schreibe ich doch: "visible" schaltet das komplette Objekt (Memofeld oder Band oder ...) un-/unsichtbar, "memo.clear()" löscht nur den Inhalt eines Memofeldes. Das Feld bleibt dabei sichtbar und wird mit angedruckt, ist aber leer.

Code: Alles auswählen

if ([q_rep1."SPEDNAME"] <> '') then memo.clear;

Diese Abfrage löscht das Memofeld des Labels, wenn SPEDNAME gefüllt ist. Das sollte genau anders herum sein: Löschen, falls SPEDNAME leer

Wäre dieser Code nicht logischer

Code: Alles auswählen

if ([q_rep1."SPEDNAME"] <> '') then memo.Visible := False;

Hier darf nicht "memo.visible" stehen, sondern es sollte "Labelname.visible" heißen ...