Office: (Office 2010) Wert aus ufrm in frm

Hatte ich auch schon mit den deutschen Bezeichnungen versucht.


Habe es jetzt mit dem VBA Code und der Verzögerung gelöst.

 

Wie steht's mit dem Versuch, die Zuweisung aus dem Ufo heraus zu machen?
Da müsste im Current-Ereignis doch alles fertig berechnet sein, oder nicht?

 

Hallo,
und wie wäre es mit dem Vorschlag in #15 ?

 

direkt im Hafo ermitteln.
Im Kriterium ist auf das Schlüsselfeld zu verweisen, das ohnehin als Primärschlüssel auf dem Hafo (bzw. dessen Datenherkunft) vorhanden sein muss, wenn Hafo und Ufo verknüpft sind.

Geht leider nicht.
Die Formulare sind nicht verknüpft und die Database des UF ist eine Abfrage, welche zwei Kriterien aus dem HF bezieht.

 

Das wäre eine Idee, muss ich mal versuchen.

 

Hallo,

Dann geht es erst recht, bzw. noch einfacher, denn die beiden Kriterien die sich auf dem Hafo befinden kannst Du auf die gleiche Art (nur ohne das Wort Where und ohne Bezug auf das Ufo) in DomSumme verwenden. Hafo und Ufo müssen nicht verknüpft sein bzw. es spielt keine Rolle.
Zeige mal den SQL Text der Abfrage für das Ufo.

 

Das ist die Abfrage:

SELECT [tbl-RE].REDat, [tbl-AT-Auftrag].ATRENR, [tbl-RE].REBezahlt, [tbl-AT-Auftrag].ATnetto, [tbl-AT-Auftrag].ATbrutto, [tbl-AT-Auftrag].ATUSt, [tbl-ST-USt].UStSatz, [tbl-RE].REEingang, [tbl-RE].REEingangBar, [tbl-RE].REStorno, [tbl-AT-Auftrag].ATNr, [tbl-AT-Auftrag].ATDatum, [tbl-AT-Auftrag].ATabgeschl, [tbl-AT-Auftrag].ATKM, [tbl-ST-Kunden].KDNR, [tbl-ST-Kunden].KDName
FROM [tbl-ST-USt] INNER JOIN ([tbl-ST-Kunden] INNER JOIN ([tbl-AT-Auftrag] INNER JOIN [tbl-RE] ON [tbl-AT-Auftrag].IDAT = [tbl-RE].IDAT) ON [tbl-ST-Kunden].IDKD = [tbl-AT-Auftrag].IDKD) ON [tbl-ST-USt].IDSTUSt = [tbl-AT-Auftrag].IDSTUSt
WHERE ((([tbl-RE].REDat) Like [forms]![frm-RE-Übersicht].[txtJahrTemp]) AND (([tbl-ST-Kunden].KDNR) Like [forms]![frm-RE-Übersicht].[txtKdNr]))
ORDER BY [tbl-RE].REBezahlt DESC , [tbl-AT-Auftrag].ATNr;


Die beiden Kriterien werden aus zwei Kombifeldern in temporäre ungebundene Textfelder(unsichtbar) geschrieben.

 

Hallo,
Auch wenn wir diese Diskussion in den letzter Zeit schon mal hatten, kann ich
nicht umhin es nochmal auf's Tapé zu bringen.
Code:

@bigrale
LIKE ohne Joker-Zeichen macht keinen Sinn, und bei einer KundenNr schon
gar nicht. Die ist "=" und nicht "so ähnlich wie". Sollte in ".[txtJahrTemp]" wirklich
nur eine Jahreszahl stehen, würde ich
Code:

verwenden.
gruss ekkehard

 

Vielleicht einmal zur Erklärung was da passieren soll.

Es werden zunächst aus den vorhandenen Rechnungsdaten die Jahreszahlen ermittelt, um diese einer Kombibox als Auswahl zur Verfügung zu stellen.
Ebenfalls werden aus den Kundennummern, in Abhängigkeit des gewählten Jahres, ermittelt die eine RE bekommen haben und ebenfalls in einer Kombibox zur Auswahl angeboten.
Somit ergeben sich zwei Auswahlkrieterien für die Abfrage ..... eine Jahreszahl und eine KdNr.

Im UF werden dann alle RE´s eines Kunden eines Jahres angezeigt.
Im UF werden nun einige Summen über die Spalten gebildet, welche zusammen mit einigen anderen Daten zur Übersicht in Textfelden im HF dargestellt werden sollen.

Fazit;
Es steht somit nur eine Jahreszahl drin, weil diese für diesen Zweck extra aus den vorhandenen Rechnungsdaten extraiert wurde.
Da hier NUR eine Jahresübersicht der Rechnungen für einzelne Kunden dargestellt werden soll wäre ein Joker kontraproduktiv.

 

Moin,

anstatt
Code:

besser
Code:

 

Hallo bigrala,

Nein, dann ist schon Like kontraproduktiv. Bestätigung siehe #25
gruss ekkehard

 

Hallo,

ich würde die Kriterien aus der Abfrage entfernen und im Formular ein Filter setzen.
Ist wesentlich einfacher, außerdem kannst das DSum was Klaus vorgeschlagen hat gut verwenden.
Dann hast eine Abfrage, die auch anderweitig zu gebrauchen ist und das kontraproduktive Like wäre auch weg!

Code:

Wenn redat das Jahr ist (was anzubezweifeln wäre), ist es auch so ok, aber wenn es ein Datum ist, dann so
Code:

oder wie in der nachstehenden Abfrage gezeigt...
Code:

Me.cboKunde muss mit der IDKD in Column(0) bestückt sein!
Wüsste nicht, wenn man eine ID hat, das man die KdNr verwendet, die ev. ein Text ist.
Zu...

...warum?
Zur Abfrage: wenn redat ein Jahr ist, Year(R.redat) AS J löschen,
K.IDKD, einfügen und die Kriterien löschen.
Die schönen Objektnamen könnte man auch etwas entschärfen *Smilie
Code:

PS: Code:

in ein Textfeld eingetragen funktioniert übrigens auch gut!

 

[etwas OT, ich will aber wieder einmal auf Indexfreundlichkeit hinweisen *wink.gif*]

Hallo!

Wenn in einer Tabelle Datumswerte eines Jahres gefiltert werden sollen, würde ich nicht where Year([Datumsfeld]) = 2016 filtern sondern where [Datumsfeld] >= #2016-01-01# and [Datumsfeld] < #2017-01-01# (Wenn keine Zeit im Datumsfeld enthalten ist, kann auch Between verwendet werden.)
Das hat einerseits den Vorteil, dass ein Index genutzt werden kann, und anderseits, falls einmal Tabellen eines aktiven DBMS zum Einsatz kommen, der Filterausdruck normalerweise per ODBC an das DBMS weitergereicht werden kann.

Beispiel von Alfred angepasst (ist aber Luftcode von mir!):
Code:

mfg
Josef

 

Hallo,

@josef,

wenn es besser ist über Datum abzufragen, warum nicht.
Aber, das geht nicht!
Code:

Muss eine Function werden!
Und wegen dem...

...beim Starten des Formular ist das Kombi Null...?
Ob da nicht ein Fehler kommt? Das gleiche gilt für with Me.cboJahr
Code:

wäre eine Möglichkeit.
Es sollen auch keine Daten angezeigt werden wenn nichts in den beiden Kombis ausgewählt wurde.

Habe es aber auch nicht getestet *wink.gif*

 

Hallo!

Eigentlich wollte ich nur auf eine indexfreundliche SQL-Anweisung hinweisen, aber einer Diskussion über Code-Gestaltung bin ich nicht abgeneigt. *wink.gif*

... dann würde ich erst dann filtern, wenn die Daten vorhanden sind.

Wieder nur Luftcode:
Code:

mfg
Josef