Access-o-Mania

Hallo,

nach langem Experimentieren mit meinem Problem benötige ich Eure Unterstützung, da ich nicht weiterkomme und wäre dankbar, wenn Ihr mir (erneut) helfen könntet.

Ich nutze Access 2010 und besitze ein Formular frmA, dessen Datenherkunft auf Tabelle tblA beruht. Das frmA besitzt für bessere Übersichtlichkeit auch mehrere Registerkarten. Die in das frmA (bzw. dessen Registerkarten) eingegebenen Daten werden (neben den Daten weiterer Tabellen) in mehreren unterschiedlichen Abfragen, Formularen und Berichten weiterverarbeitet.

Der Ausgangspunkt meines Problems liegt darin, dass es mir bisher nicht gelungen ist, die in frmA (in einem Steuerelement auf einer Registerkarte) vorgenommene Berechnungen mit den Ergebnissen XY in den entsprechenden Feldern der zugrundeliegenden Tabelle (tblA) zu speichern.

Mir ist bewusst, dass dieses Vorhaben unüblich und idR nicht zu empfehlen ist, aber in meinem Fall sinnvoll, denn die Werte XY werden nur einmal berechnet und dann nicht mehr verändert. Sie sollen aber für einen späteren Vergleich in  bzw. für diesen Datensatz weiterhin zur Verfügung stehen.

Weil ich die Werte XY bisher nicht speichern kann, berechne ich diese Werte statt in dem frmA nun in der qryA, in der auch sonst alle weiteren Berechnungen zentral durchgeführt werden. Die Daten gelangen dann in das frmA per DomWert-Abfrage. Die Daten werden in frmA angezeigt, da sie eine Entscheidungsgrundlage für die Eingabe der weiteren Daten bilden.

Diese Vorgehensweise ist leider nicht optimal, denn zum einen wird die qryA aufgebläht und die Berechnung erfolgt für XY unnötigerweise stets aufs Neue. Das Rückspielen von XY in das frmA per DomWert ist auch zeitraubend und die Performance insgesamt leidet.

Folgendes habe ich bisher versucht:

1. Mittels einer Ereignisprozedur im berechneten Steuerelement:

a) Berechnung XY im frmA; in Eigenschaften ,,NachAktualisieren" des berechneten Steuerelementes habe ich
Me![MeinTabellenfeld] = Me![MeinBerechnetesSteuerelement]
eingegeben (Quelle: DonKarl FAQ 4.11). Das funktioniert leider nicht. ,,VorAktualisieren" hilft auch nicht. Was mache ich falsch ?
b) Liegt dies evtl daran, dass das berechnete Steuerelement sich auf einer Registerkarte befindet und ich es anders ansteuern muss ? Ich habe allerdings in Erinnerung, dass Registerkarten für die Ansteuerung bzw. Verwendung eines Steuerelementes keine Bedeutung besitzen.

2.) Berechnetes Feld in tblA

Eine gute Lösung für mich wäre ein berechnetes Tabellenfeld, auch wenn die Nutzung eines berechneten Feldes nicht den üblichen Konventionen entspricht. Daher habe ich meine ursprüngliche Access-mdb (2000) in das Format Access 2007-2010 konvertiert und alles importiert. Das hat grundsätzlich (bis auf wenige Ausnahmen) gut geklappt.
Einzelne Felder in der Tabelle liessen sich testweise auch reibungslos berechnen, also grundsätzlich eine gute Alternative für mich.

Leider bestehen die Wertermittlungen für XY auch aus komplexen Formeln (Wenn...dann etc.). Leider erhalte ich dann die Fehlermeldung: ,,Die Eigenschaftseinstellung kann nicht grösser als 2KB sein, Fehler 3309." Dies stellt mich vor neue ungeahnte Herausforderungen.... Kann man die Speichergrösse für die ,,Eigenschaften" irgendwo (in der Registry ?) ändern, und wie ?

3. Datenherkunft frmA ändern

Es ist leider idF auch keine Lösung, die Datenherkunft von frmA auf eine qry umzustellen, da ich dann überhaupt keine eingegebenen Werte aus frmA mehr in tblA speichern kann. Das hatte ich vorher und auf Anraten in diesem Forum in tblA geändert http://www.access-o-mania.de/forum/index.php?topic=21298.msg121015#msg121015 (http://www.access-o-mania.de/forum/index.php?topic=21298.msg121015#msg121015).

4. Separate Tabelle für XY

Ich könnte vermutlich auch die Felder für XY in eine separate Tabelle tblB auslagern und die Tabellen verküpfen, dennoch muss ich die Berechnungen dann auch erst einmal in tblB bekommen....

Lange Rede kurzer Sinn:
Wie bekomme ich die in frmA errechneten Werte in die Datenfelder der tblA, bevorzugt mittels einem der Lösungsansätze aus 1. oder 2. ?

Ich hoffe, ich habe mein Problem verständlich geschildert und würde mich freuen, wenn mir jemand aus diesem Forum den entscheidenden Lösungshinweis für diesen Schlamassel geben könnte !

Vielen Dank und Grüße,
Jochen

Hallo,
Du hast viel geschrieben, aber nichts gesagt.
Me![MeinTabellenfeld] = Me![MeinBerechnetesSteuerelement]Das müsste funktionieren. Beide Felder müssen aber auf dem Formular vorhanden sein und das Formularfeld "MeinTabellenfeld" muss an das entsprechende Tabellenfeld gebunden sein. Die Registerkarten spielen keine Rolle. Das Speichern von berechneten Werten ist aber zu vermeiden, wie Du ja bereits erkannt hast.

ZitatLeider bestehen die Wertermittlungen für XY auch aus komplexen Formeln (Wenn...dann etc.).

Formeln mit wenn ... Dann sind fast immer ein Hinweis auf ein nicht normalisiertes Datenmodell. Auch Domwert sollte in einer korrekt aufgebauten Datenbank nicht erforderlich sein.

Ich denke, da ist bereits die Grundstruktur ungeeignet und eher excellastig.
Kannst Du mal ein Bild des Beziehungsfensters posten.
Auch in Deinem (verlinkten Thema) ist zum Datenmodell nichts zu finden.

Ich beschränke mich hier mal auf einen Kommentar zu dem berechneten Tabellenfeld...

Zitat von: Jochen1 am Oktober 08, 2018, 17:49:37
Eine gute Lösung für mich wäre ein berechnetes Tabellenfeld,
[....]
Eigenschaftseinstellung kann nicht grösser als 2KB sein, Fehler 3309." Dies stellt mich vor neue ungeahnte Herausforderungen.... Kann man die Speichergrösse für die ,,Eigenschaften" irgendwo (in der Registry ?) ändern, und wie ?

Nein, das Limit für die Textlänge des Ausdrucks lässt sich nicht ändern.
Macht aber auch nichts, weil dir ein Berechnetes Feld in der Tabelle nicht wirklich weiterhilft. Das Berechnete Feld wird bei einer Änderung der Ausgangswerte immer automatisch neu berechnet. Bringt dir also gar nichts, wenn du das in der Vergangenheit errechnete Ergebnis als Referenz speichern willst.

Grundsätzlich schließe ich mich Klaus' Meinung an. Dass dein Ausdruck länger als 2000 Zeichen sein muss, kann ein Anzeichen für ein suboptimales Datenmodell sein.

Berechnungen -  was steckt wirklich dahinter?
Eine Multiplikation mit 1 würde ich nicht speichern, das berechnete Klima für die nächsten 10 Jahre schon (weil es einfach Riesenaufwand ist).

Zitatwird die qryA aufgebläht

Wie darf man sich das vorstellen?
Ich habe schon einige Abfragen geschrieben und andere bei solchen unterstützt, ein solches Phänomen ist mir noch nie begegnet.

ZitatLeider bestehen die Wertermittlungen für XY auch aus komplexen Formeln (Wenn...dann etc.).

Auch da fehlt mir eine Vorstellung. Was ist an Wenn-Dann komplex?
Formeln sind eine Anleihe aus Excel, Wenn-Dann-Kaskaden auch. Wenn Du also versuchst, Excellogik in einer Datenbank 1:1 umzusetzen, so kann das durchaus anstrengend sein. Vielleicht versucht man es mit Datenbanklogik ...? Es könnte die Herausforderungen in ganz andere Bereiche verschieben.

Hallo,

vielen Dank für die Antworten.

ZitatCode: [Auswählen]

Me![MeinTabellenfeld] = Me![MeinBerechnetesSteuerelement]

Das müsste funktionieren. Beide Felder müssen aber auf dem Formular vorhanden sein und das Formularfeld "MeinTabellenfeld" muss an das entsprechende Tabellenfeld gebunden sein.

Vielen Dank für diesen Hinweis, ich hatte bisher [MeinTabellenfeld] nicht zusätzlich auf dem Formular, das habe ich nun nachgeholt. Das Feld besitzt den gleichen "Namen" und "Steuerelementinhalt" wie das Feld der zugrundeliegenden Tabelle (damit ist es doch an diese Tabelle gebunden ?).

In den Eigenschaften von [MeinBerechnetesSteuerelement] steht in "NachAktualisieren" die obige Formel.

Leider funktioniert die Speicherung des Wertes in [MeinTabellenfeld] (immer noch) nicht, in tblA wird nichts geschrieben.

Meine Vermutung ist, dass durch "NachAktualisieren" das Ereignis nicht ausgelöst wird.

Zu Euren Anmerkungen:
Vielen Dank dafür. Es mag sein, dass die Datenbankstruktur (nach Euren Massstäben) nicht optimal ist, ich glaube aber, dass dies in diesem Fall und für meine Frage zunächst von untergeordneter Bedeutung ist. Ich denke selbstverständlich darüber nach, sie zu verbessern (was aber zu anderen Problemen und Mehraufwand an anderer Stelle führt).

Die "Wenn Dann Berechnung" benötige ich für die Berechnung unterschiedlicher Werte, je nach zugrundeliegendem Datensatz. Beispiel "Positionsgrössenberechnung" für Wertpapiere: Die Anzahl der zu erwerbenden Wertpapiere ermittelt sich nach einer anderen Formel, je nachdem, ob es sich um eine Aktie oder z.B. ein Zertifikat (wg. Basispreis und Bezugsverhältnis) handelt. Dieser ermittelte Wert, nämlich die "Plan-Anzahl" wird im Formular angezeigt (und für die Ermittlung voraussichtlicher Anschaffungskosten weiterverwendet). Er soll für einen späteren Vergleich gespeichert werden. Wie bereits geschrieben, ändern sich die Ausgangswerte in der Zukunft nicht mehr. Das Ergebnis muss daher auch nicht stets neu in der Abfrage qryA berechnet werden (in qryA). Dann entfällt auch die DomWert-Zurückspiegelung ins Formular.

M.E. ist daher die Wenn..Dann Formel m.E. nicht excellastig, sondern der Berechnungsstruktur geschuldet. Für ein berechnetes Tabellenfeld ist sie allerdings offensichtlich zu lang (nicht zu "komplex"), so dass die Summe der Eigenschaften dann die 2KB überschreitet.

Daher wäre ich Euch wirklich sehr dankbar, wenn Ihr mir helft, den Wert irgendwie in die Tabelle zu speichern. Evtl. teile ich die Tabelle später weiter auf, um die Struktur zu verbessern, zunächst muss ich aber dieses Problem lösen.

Viele Grüße,
Jochen

Hallo,

es ist (mir) nicht klar, wie und wo diese Berechnungen denn nun gemacht werden...

Das Ergebnis steht in einem Feld namens "MeinBerechnetesSteuerelement",  aber wo und wie gibst Du die Anfangswerte und den Algorithmus ein?

Bei allen Steuerelementen, die in die Berechnung einfließen, muss das Nach Aktualisierung Ereignis herangezogen werden, damit der Feldinhalt in das berechnete Feld eingetragen wird. Hast Du z.B. Einzelpreis, Steuersatz und Mengenangabe, um den Gesamtpreis zu ermitteln, müsste für jedes der drei Steuerelemente das Nach Aktualisierung Ereignis genutzt werden, weil jede Änderung in einem der Steuerelemente das Ergebnis der Berechnung beeinflusst. Im Feld mit dem Rechenausdruck findet kein Aktualisieren statt.
Die zweite Variante ist bei vielen abhängigen Feldern weitaus weniger aufwendig.
Eine andere Methode wäre, die Berechnung von einer Aktualisierungsabfrage erledigen zu lassen.

PS: Es muss kein Steuerelement im Formular für den Emmpfang der Berechnung bereitgestellt werden. Es genügt, wenn das Feld in der Datenherkunft (bei einer Tabelle ist das immer der Fall, bei einer Abfrage ist das Feld in die Feldliste aufzunehmen) vorhanden ist.

Hallo,

danke für Eure Antworten.

@Klaus:
Das frmA ist an die tblA gebunden. Die Tabellenfelder A, B, und C befinden sich jeweils als Steuerelement auf dem Formular. Hier werden die Ausgangsdaten eingegeben (und mithin in der Tabelle in A, B, und C gespeichert). D ist ein Tabellenfeld. Das berechnete Steuerelement "E_Berechnet"] befindet sich auch auf dem Formular. Steuerelementinhalt von E_Berechnet: 'A+B+C'. Das Ergebnis soll gespeichert werden.

@Lachtaube:
Das klingt nach einem echten Lichtblick ! Etwas Ähnliches hatte ich schon einmal in einem anderen Forum gelesen, aber irgendwie nicht verstanden, es umzusetzen.
Wenn ich es nun richtig verstehe, muss ich nun in allen zugrundeliegenden Feldern auf dem Formular (d.h. hier den Feldern A, B und C) jeweils in "NachAktualisierung" eingeben:

Me![D] = Me![E_Berechnet]

Stimmt das so ? Dann werde ich es so ausprobieren.

Die Aktualisierungsabfrage ist auch eine gute Idee.

Viele Grüße,
Jochen

@Lachtaube:
Bei "NachAktualisieren" passiert in "E_Berechnet" leider nichts.
Wenn ich aber den Ausdruck  "Me![D] = Me![E_Berechnet]" in "BeiFokusverlust" eingebe, erhalte ich eine Fehlermeldung:

ZitatDieser Ausdruck hat einen Fehler verursacht: Das Objekt enthält das Automatisierungsobjekt `Me`nicht.

Die Erläuterung zu dem Fehler (Eigenschaft des Formulars bei OnOpen steht auf "Field") verstehe ich auch nicht, denn ich sehe in den Eigenschaften des Formulars nichts diesbezügliches, oder wo muss ich nachsehen ?

Viele Grüße,
Jochen

Hallo Jochen,

ZitatMe![D] = Me![E_Berechnet]
Stimmt das so ? Dann werde ich es so ausprobieren.

Nein.
Me!E_Berechnet = DeinBerechnungsergebnis
gruss ekkehard

Hallo ekkehart,

danke, nur: Das verstehe ich nicht. Um im Beispiel zu bleiben, bedeutet es im Feld A (und B,C) dann unter "NachAktualisieren":

Me!E_Berechnet = A+B+C
oder vielmehr
Me!D = A+B+C

(denn E_Berechnet ist ja kein Tabellenfeld) ? Und 'Me!E_Berechnet = A+B+C' wird ja nicht benötigt, denn das Feld wird ja bereits auf dem Formular automatisch mit A+B+C berechnet und muss ja nicht extra durch "NachAktualisieren" angestossen werden.

Ich stehe auf dem Schlauch, vielleicht, weil ich nicht weiss, was mit "DeinBerechnungsergebnis" in diesem Beispiel gemeint ist.
Jochen

@Jochen,

damit wir vom selben sprechen. Alle hier und in den bei Don Karl gezeigten/erwähnten Anweisungen stellen VBA-Code dar. Du musst also für die Ereignisse jeweils eine Ereignisprozedur einstellen (über den Dropdown-Pfeil im Eigenschaftsblatt) und danach auf den Knopf rechts daneben mit der Ellipse (...) klicken. Dann bist Du (anfangs einmalig nach kurzer Wartezeit) im VBA-Editor. Access erstellt dabei den Rumpf der Ereignisprozedur selbstständig. Der Code gehört dann in eine leere Zeile zwischen Private Sub Steuerelementname_AfterUpdate() und End Sub.

Hallo Jochen,

Zitatbedeutet es im Feld A (und B,C) dann unter "NachAktualisieren":

Ja bzw.
Me!DeinTabellenFeldMitErgebnis = A+B+C
(NULL-Werte müssten dabei noch abgefangen werden)

Zitatweil ich nicht weiss, was mit "DeinBerechnungsergebnis

Na, dies

ZitatDie "Wenn Dann Berechnung" benötige ich für die Berechnung unterschiedlicher Werte

Hier kommt doch ein Wert zurück, den du speichern willst; - oder habe
ich das falsch verstanden?
Vielleicht zeigst uns diesen Code auch einmal.

gruss ekkehard

edit:
Gerade Lachtaubes Post gelesen, also
Private Sub FeldA_AfterUpdate()   ' oder B oder C
    Me!DeinTabellenFeldMitErgebnis = DeinBerechnungsergebnis
End Sub

Hallo,

danke, das klappt leider nicht. Ich glaube, es ist am Einfachsten, ich erstelle eine kleine Beispielsdatenbank mit Formular und Werten und lade sie morgen früh hoch. Dann wird mein Fehler wahrscheinlich deutlich.

Danke,
Jochen 

Gute Idee.

Hallo,

nun glaube ich, dass ich es Dank Eurer Hilfe nun hinbekommen habe, der Hinweis von Lachtaube hat auch geholfen, denn ich hatte vorher offensichtlich keine Ereignisprozedur (sondern den Ausdruck nur in das Feld geschrieben).

Das zu berechnende Tabellenfeld D gibt den in E berechneten Wert wieder, das klappt also  :).

Noch eine kleine Frage: Wie kann ich vermeiden, dass das berechnete Feld E erst den Focus erhalten muss, damit die Speicherung im Feld D erfolgt (zumindest war das bei mir so) ?

Schon mal vielen Dank, das war ein grosser Schritt nach vorne.

Jochen

P.S.: Ich nehme auch mit, dass es zielführender ist, das Problem zunächst anhand einer Beispieldatenbank nachzustellen. Leider kann ich sie nicht nicht hochladen, da (Access 2010) im accdb-Format. Wie kann ich das bewerkstelligen ?

Hallo,

ZitatWie kann ich das bewerkstelligen ?

Beispieldb erstellen > Komprimieren/reparieren > Zipfile erstellen > Zipfile hochladen.

Verwende das Vor Aktualisierung Ereignis des Formulars. Und wie gesagt, genügt es, wenn das Zielfeld in der Datenherkunft des Formulars vorhanden ist. Du musst kein Steuerelement dafür verwenden. Dasselbe Ergebnis zweimal anzuzeigen bringt ja schließlich keinen Mehrwert.

Guten Morgen,

so, nun die gezippte Beispieldatenbank.

Im Formular ist -für Testzwecke- noch das Tabellenfeld D enthalten, um zu sehen, in welchem Zeitpunkt der Wert in die Tabelle geschrieben wird.

Ich habe die Formel nun in der Ereignisprozedur "VorAktualisierung" (der einzelnen Felder), nur leider scheint auch in diesem Fall D erst nach Fokusverlust von E aktualisiert zu werden.

Wenn wir das noch lösen könnten, wäre es perfekt.

Schon jetzt vielen Dank für Eure Geduld und Unterstützung !

Jochen

P.S. Nun hoffe ich auch, dass es keine Zeichenbeschränkung gibt.....

Hallo,


siehe Anhang

btw:
wie schon erwähnt, ist das Speichern  berechneter Werte Unsinn.

@Jochen,

die Berechnung in VBA zu wiederholen ist dann doch etwas kontraproduktiv.

VBA-Modul des Formulars
Option Compare Database
Option Explicit

Private Sub A_BeforeUpdate(Cancel As Integer)
   'Me!D = [A] + [B] + [C]
   Me.Text24 = Me.E 'über den Namen des Steuerelements
End Sub

Private Sub B_BeforeUpdate(Cancel As Integer)
   'Me!D = [A] + [B] + [C]
   Me.D = Me.E 'das sieht man erst nach dem Speichern des Datensatzes
End Sub

Private Sub C_BeforeUpdate(Cancel As Integer)
   'Me!D = [A] + [B] + [C]
   Me.Text24 = Me.E
End Sub

'Mit einem weiteren Feld 'F' als Zielfeld der Berechnung
'in der Tabelle, ohne dass es an ein Steuerelement gebunden
'ist, erfordert weitaus geringeren Aufwand.''Datenherkunft neu setzen, damit das Formular 'F' kennenlernt.
Private Sub Form_BeforeUpdate(Cancel As Integer)
   Me.F = Me.E
End Sub

Eine Aktualisierungsabfrage für ein Feld G, könnte so aussehen. (In die SQL-Ansicht einer neuen Abfrage kopieren.)
UPDATE tbl_A AS a
SET    G = a.A + a.B + a.CWHERE  G Is Not Null;

PS:wenn Deine Ausgangsfelder auch Null-Werte enthalten können, verwende in den Ausdrücken die Nz() (https://support.office.com/en-us/article/nz-function-8ef85549-cc9c-438b-860a-7fd9f4c69b6c)-Funktion. Also in E: =Nz([A];0)+Nz(;0)+Nz([C];0). In der SQL-Ansicht wäre das Semikolon gegen ein Komma auszutauschen.

PPS: und findet eine Änderung von A, B oder C außerhalb des Formulars statt, ist das Ergebnis garantiert falsch und muss durch eine Aktualisierungsabfrage erneuert werden. Besser sicherer wäre es jedoch, ab Access 2010 ein Datenmakro zu verwenden.


Generell sei noch angemerkt, dass die Datenform im Beispiel der Aufzählungsfelder A, B, C wegen, besser in eine andere Struktur übergeführt werden sollte, um dann z.B. mit der Sum()-Aggregatfunktion das Ergebnis ermitteln zukönnen.

ID	Herkunft	A
1	A	10
3	A	20
4	A	40
5	A	50
1	B	20
3	B	30
4	B	50
5	B	60
1	C	30
3	C	40
4	C	60
5	C	70

Hallo,

zunächst vielen Dank für die überarbeitete Datenbank und die Vielzahl von Anregungen, die ich mir als Access-Laie noch zu Gemüte führen muss.

@Klaus:
Danke, ich habe auch grundsätzlich verstanden, keine berechneten Werte in der Tabelle zu speichern.

Vielleicht ist mein Ausgangspunkt aber ein etwas anderer:
Den berechneten Wert E müsste ich (ausserhalb von Access) zunächst mit Excel oder einem Taschenrechner ermitteln. Es ist in der Tat keine Aufgabe für Access. Ich benötige dieses Berechnungsergebnis jedoch, um mit ihm weiterzuarbeiten. Folglich müsste ich also sowieso dafür ein Tabellenfeld definieren und den Wert dann manuell in mein Ausgangsformular (und damit die Tabelle) eingeben. Um mir aber Arbeit zu sparen und gleichzeitig etwaige Berechnungsfehler zu vermeiden, dachte ich, dies gleich durch Access in einer Art Vorstufe in einer Registerkarte erledigen zu lassen. Und der Wert muss auch nicht stets aufs Neue z.B. in einer Abfrage ermittelt werden. Daher denke ich, dass meine Idee in diesem Ausnahmefall erlaubt sein sollte...

@Lachtaube:
Auch Dir vielen Dank auch für die Aktualisierungsabfrage und die VBA Darstellung. Mir glüht nun der Kopf zwischen Ereignisprozedur, VBA und Datenmakro.... Ich muss nun sehen, was das Beste wäre, aber mir gefällt die Lösung mit der Ereignisprozedur in der Beispielsdatenbank ziemlich gut; da ich nicht so bewandert bin, suche ich auch etwas, was ich auch nach einem Jahr noch nachvollziehen kann, sollte ich etwas ändern wollen.

Danke auch für den Strukturhinweis -Das Beispiel und die Zahlen waren jedoch rein fiktiv, ich wollte nur den Mechanismus und die Aktualisierung testen. Dein Vorschlag und der Thread insgesamt ermahnt mich, regelmässig über die Struktur nachzudenken.

Zum PPS: Mir ist klar, dass eine Berechnug dort keinen Sinn macht, wenn sich Daten ändern und dann der Wert im Tabellenfeld "veraltet" ist. Aber: Die Werte ändern sich nicht. Und wenn doch, dann nutze ich ja ausschliesslich dieses Formular. Der Wert, den ich übrigens ermittele, steht ausschliesslich in einer 1:1-Beziehung im Datensatz.

Also nochmals vielen Dank für die Geduld und Hilfe, Ihr habt mir sehr weitergeholfen.

Jochen

Hallo,

Zitat@Klaus:
Danke, ich habe auch grundsätzlich verstanden, keine berechneten Werte in der Tabelle zu speichern.

wieso ich, ich habe ja gar nichts mehr dazu gesagt.

Entschuldigung Klaus, ich habe den Franz gemeint.
Jochen