@column

[koehlerbv]

Wenn alles 0 wird, dann kann das nur zwei Gründe haben:
- Entweder, Du hast die Formel falsch umgesetzt, oder
- da stehen doch keine Zahlen drin. Was aber nicht sein kann, wenn Deine Summenformel funktioniert.

Wegen der Aktualisierung:
Doch, das geht. Ich hoffe, Du hast Deine Mittelwert-Felder angelegt als "Berechnet zur Anzeige" (denn diese Werte zu speichern, wäre ja totaler Schwachsinn, sie stellen ja nur eine Momentaufnahme dar).
Trage in den Maskeneigenschaften ein, dass sich "Felder automatisch aktualisieren".

HTH,
Bernhard

[Marie]

Hallo Bernhard,

sorry, aber ich musste nochmal weg...

Also, ich habe in der Spalte für die Auftragssumme jetzt folgende Formel:

auftragssumme;
@If (@IsNumber (Value); 0; Value_3 = ""; 0; Value_3),

Die Werte sind jetzt alle auf 0 ?!?

Warum ist denn diese Überprüfung so wichtig?

Gruß Marie

[koehlerbv]

Marie, der Fehler müsste Dir nun eigentlich selber auffallen:

@If (@IsNumber (Value); 0; Value_3 = ""; 0; Value_3)

@If (@IsNumber (Value_3); 0; Value_3 = ""; 0; Value_3)

Warum diese Prüfung so wichtig ist, sollte Dir aus dem bisherigen Threadverlauf auch klar sein. Das zu verstehen, ist nun wirklich Dein Part.

Bernhard

[Peter Klett]

Wie heißt denn das Feld für die Auftragssumme? auftragssumme oder Value_3?

auftragssumme;
@If (@IsNumber (Value); 0; Value_3 = ""; 0; Value_3),

Wenn es auftragssumme heißt, warum prüfst Du danach Value_3? Und falls es Value_3 heißt, was ist dann mit auftragssumme in der ersten Zeile gemeint?

Ich übersetze mal Deine Formel ins Deutsche

Zeige in der Spalte den Wert des Feldes auftragssumme
Wenn Value eine Zahl ist, zeige 0
sonst wenn Value_3 leer ist, zeige 0
sonst zeige Value_3

Was Du brauchst ist aber folgendes

Wenn die Auftragssumme KEINE Zahl ist, zeige 0
sonst wenn die Auftragssumme leer ist, zeige 0
sonst zeige die Auftragssumme

Um es richtig zu machen, kannst Du die erste Zeile komplett streichen, denn die wird von der zweiten ungültig gemacht.

Unter der Annahme, dass das Feld auftragssumme heißt, wäre also die korrekte Formel

@If (!@IsNumber (auftragssumme); 0; auftragssumme= ""; 0; auftragssumme),

Falls das Feld doch Value_3 heißen sollte, hast Du zwei Fehler in der ersten Bedingung der zweiten Zeile.

1. Du prüfst Value anstelle von Value_3
2. Du schreibst 0, wenn Value (korrekt Value_3) eine Zahl ist. Korrekt ist aber, eine 0 zu schreiben, wenn Value_3 KEINE Zahl ist. Wichtig ist das Ausrufezeichen vor dem @, das dreht die Bedingung um

Dass alle Werte 0 sind, liegt wohl daran, dass das Feld tatsächlich auftragssumme heißt. Die Bedingungen werden dann so übersetzt:

Value ist keine Zahl -> nächste Bedingung
Value_3 ist leer -> Ja -> 0 schreiben

Du fragst, wozu diese Überprüfung wichtig ist. Man kann sich darüber streiten, wo und wieoft eine solche Überprüfung eingebaut sein muss. In Deinem Fall sehe ich drei Möglichkeiten:

1. Beim Speichern des Dokuments
2. In der Ansicht
3. In der Berechnung der Summen

M.E. genügt es an einer Stelle, und dann nehme ich immer die erste. Wenn ich nicht zulasse, dass Dokumente mit falschen Feldwerten gespeichert werden, kann auch in Ansichten und Folgeberechnungen nichts falsch laufen. Auf der anderen Seite schadet es nicht, an allen Stellen, an denen Fehler auftreten können, diese sauber abzufangen. Da sollte man abwägen, welche Folgeschäden eintreten können. Wird in einem Dokument Quatsch angezeigt, ist das sicherlich vertretbarer, als wenn eine gesamte Verarbeitungskette (z.B. ein periodischer Reorganisationsagent) unterbrochen wird. Da könnte man sicher lange drüber philosophieren.

[koehlerbv]

Danke, Peter. Das Marie es geschafft hat, dass "!" wegzulassen, habe ich echt nicht gesehen. Mit der in der Programmierung erforderlichen Genauigkeit scheint sie es nicht so zu haben.

Was die "Philosophie" angeht: Ich baue die Sicherheitsmechanismen auf jeden Fall immer (auch) an der Stelle ein, an der sie jeweils gebraucht werden. In diesem Falle: Änderungen an der Maske, Agents, die Dokumente ggf. erneut modifizieren etc. - was weiss ich, was da noch kommt. Mein Ergebnis muss jeweils *an dieser Stelle* funktionieren.

Bernhard

[Peter Klett]

@Bernhard:

Mit den Sicherheitsmechanismen (zumindest von der Art, wie sie hier bisher diskutiert wurden), gewinnst Du aber nur eine technische Sicherheit.

Maries Anwendung ist ein gutes Beispiel dafür, wie eine technische Sicherheit eine fachliche Unsicherheit bedeuten kann. Annahme: In der Anwendung werden Aufträge dokumentiert, die Auftragssumme wird als Zahl im Dokument hinterlegt.

Beim Speichern des Dokuments den Wertebereich der Auftragssumme zu prüfen, ist ohne jeden Zweifel. Im manuell gespeicherten Dokument kann also nur ein richtiger Wert stehen.
Aus optischen Gründen könnte zugelassen sein, die Auftragssumme leer zu lassen (also nicht zwingend mit 0 angeben, falls keine Auftragssumme vorhanden ist, vielleicht im Falle einer kostenlosen Nachbesserung oder einer Werbeaktion).

Jetzt kommen wir zu der Ansicht, aus der später die Summen gerechnet werden. Ist die Auftragssumme leer, muss sie zweifelsfrei in 0 umgewandelt werden (selbstverständlich sind solche Ansichten immer versteckt, so dass optische Gründe hier niemals ziehen können). Aber was passiert, wenn durch spätere Einflüsse (Agenten, Importe aus anderen Systemen, kaputt reparierte Masken usw.) Auftragssummen im falschen Format auftauchen (z.B. "20TEUR")? In der bisher angegebenen Sicherheitsformel werden die zu 0 umgewandelt.

Die Summenberechnung klappt dann auch problemlos, weil in der Ansicht nur saubere Zahlen stehen. Auch die Abrechnung der Aufträge läuft später sauber durch, weil alle Zahlen technisch korrekt sind, aber sie sind fachlich falsch. In meinem Beispiel ist das Programm zwar störungsfrei durchgelaufen, auf dem Konto fehlen aber 20.000 Euro (das täte mir mehr weh, als ein "type mismatch" oder ein "Falscher Datentyp: Zahl erwartet"). Ohne den Sicherheitsmechanismus in der Ansicht hätte es in der Abrechnung einen Fehler gegeben, der dazu hätte führen müssen, dass die Auftragsdokumente manuell überprüft und korrigiert werden.

[koehlerbv]

Insbesondere der letzte Abschnitt stimmt schon - ich gehe da mit Dir, Peter. Jetzt wird es aber zu komplex in Angesicht einer Anwendung, die wir eigentlich überhaupt nicht kennen.

Für derart wichtige (weil monetäre u.ä.) Auswertungen habe ich übrigens immer Routinen, die vorher einen "Blick" auf die Integrität der vorhandenen Daten werfen. *Derzeit* habe ich das nirgendwo in Kombination im Einsatz (also Anzeige eines Fehlers, beispielsweise in (eh kaum auffällig) oder durch Ansichten und dann die Möglichkeit, eine Analyse zu starten), d.h., bevor etwas "ernst wird", läuft der Integritätscheck.

Auf jeden Fall wäre dieses Thema tatsächlich einen Erfahrungsaustausch-Thread wert!

Bernhard