Hallo!
Erweitere gerade im Rahmen meiner Hausarbeit eine bestehende Datenbank (Bestellverwaltung) und hänge nun schon länger an folgender Problemstellung fest:
Gefordert ist eine Bericht der auf einer Abfrage mit Parameterübergabe basiert und der alle derzeit lieferbaren Artikel ausgeben soll.
Der Bericht soll Name, Artikelnummer, Menge, Einheit, Brutto-Preis in €, Brutto-Gesamtwert in € und den Netto-Gesamtwert in einer beliebigen weiteren Währung enthalten.
Die Artikel sind nach Name alphabetisch aufsteigend zu sortieren und auszugeben. Alle Informationen sind in einer Zeile darzustellen.
In der Kopfzeile sollen die Spaltenüberschriften stehen. Bei jedem Öffnen des Berichtes soll der Benutzer aufgefordert werden, die weitere Währung (Umrechnungsfaktor und Kürzel) einzutragen.
Ok...
Probleme bereitet mir hier hauptsächlich der Aufbau der Abfrage und die weitere Währung die als Umrechnungsfaktor und Kürzel beim Öffnen eingegeben werden soll!
Wie kann man an so eine Abfrage heran gehen? :-\
Vielen Dank schon mal im voraus!
Hallo,
schreib im Abfrageentwurf über all dort, wo ein solcher Parameter gefordert wird, einen aussagekräftigen Namen und eindeutigen (Text) in Eckklammern gesetzt hin. Dieser Name (Parameter) sorgt dafür , dass bei Ausführen der Abfrage (Öffnen des Berichtes entspr. Parameterfenster aufgehen, in denen Du den akt. Wert für diesen Parameter (ist ja nur ein Platzhalter) eingeben kannst/musst.
etwa so (Woher kommt Netto-Gesamtwert, bzw. wie soll der berechnet werden?)
Select [Name], Artikelnummer, Menge, Einheit, [Brutto-Preis], Menge * [Brutto-Preis] as [Brutto-Gesamtwert in €] , [Netto-Gesamtwert] , Menge * [Brutto-Preis] *[Umrechnungsfaktor eingeben] as [Weitere Währung] , [Kürzel eingeben] from tblDeine LieferbareArtikelTabelle
btw: auf Sonder- /Leerrzeichen und reservierte Wörter in Namen dringend verzichten. Solche Ausdrücke MÜSSEN ansonsten in Eckklammern gesetzt werden.
Hallo,
danke für deine schnelle Antwort. Ich habe nun folgende Abfrage erstellt (die wichtigen Stellen habe ich rot hervorgehoben)...
SELECT [Artikel-T].Artikelnummer, [Artikel-T].Artikelname, [Artikel-T].Menge, [Artikel-T].Einheit, [Artikel-T].Lagerbestand, [Artikel-T].[Preis(Brutto)], [Preis(Brutto)]*[Lagerbestand] AS [Gesamtwert(Brutto)], (([Preis(Brutto)]/1.19)*[Lagerbestand])*[Bitte den Umrechnungsfaktor eingeben] AS [Fremdwährung(Netto)], [Bitte das Kürzel der Währung eingeben] AS [Währung(Kürzel)]
FROM [Einheit-T] INNER JOIN ([Artikel-T] INNER JOIN [DS_Bestellpositionen-T] ON [Artikel-T].Artikelnummer = [DS_Bestellpositionen-T].Artikelnummer) ON [Einheit-T].Name = [Artikel-T].Einheit
GROUP BY [Artikel-T].Artikelnummer, [Artikel-T].Artikelname, [Artikel-T].Menge, [Artikel-T].Einheit, [Artikel-T].Lagerbestand, [Artikel-T].[Preis(Brutto)], [Preis(Brutto)]*[Lagerbestand]
HAVING ((([Artikel-T].Lagerbestand)>0))
ORDER BY [Artikel-T].Artikelname;
Soweit funktionierts und bin auch recht zufrieden!
Habe aber noch eine Frage bezüglich dem Kürzel das eingegeben werden soll für die Fremdwährung.
Im Moment erscheint mein Kürzel immer in der Spalte hinter den Zahlenwerten also hinter [Fremdwährung(Netto)] in der Spalte mit dem Namen [Währung(Kürzel)]. Gibt es eine Möglichkeit dass das Kürzel was man bei der Abfrage angeben soll in der Spalte [Fremdwährung(Netto)] als Feldname steht? So das es nach der Eingabe stellvetretend für die Fremdwährung angezeigt wird, so dass ich mir die letzte Spalte, die nur das Kürzel anzeigt sparen könnte?
Ist ein bisschen schwer zu erklären... Hoffe ich habs einigermaßen verständlich beschrieben...
Aufpoppende Parameternachfragen, besonders in Vielzahl, empfinde ich als anstrengend, als Nutzer würde ich mich erschrecken.
Übersichtlicher wäre es, notwendige Daten in einem Formular zu sammeln (inkl. Gültigkeits- und Vollständigkeitsprüfung) und dann diese Angaben bei Berichtsaufruf an die Abfrage zu übergeben.
Eine Variante, die immer funktioniert, ist folgende:
- Der Bericht erhält als Datenherkunft eine gespeicherte Abfrage.
- Vor Aufruf des Berichts wird die Abfragedefinition der gespeicherten Abfrage an eigene Vorstellungen angepasst:
CurrentDb.QueryDefs("NameDerAbfrage").SQL = "SELECT ..."
In den SQL-String kann man beliebig vorhandene Textbausteine und Variablen/Formularfelder einbauen.
MfGA
ebs
Hallo,
"So das es nach der Eingabe stellvetretend für die Fremdwährung angezeigt wird, so dass ich mir die letzte Spalte, die nur das Kürzel anzeigt sparen könnte?
Im Grunde ist das Ziel, die Ergebnisse in Abfrageansicht für den User darzustellen (so vermute ich mal) , nicht zu empfehlen. Für die Anzeige solcher (formatierten) Ergebnisse sollten (Endlos-)Formulare, evt. auch Listenfelder , bzw. Berichte herangezogen werden. Die Abfragen selber liefern nur Tabellendaten, evtl. auch berechnete Werte, aber ohne Formatierungen oder sonstige Zusätze. Die Formatierungen werden im Formular selber behandelt.
Wie ebs17 schon angemerkt hat, sollte man auf solche Parameter in Abfragen gänzlich verzichten.
http://dbwiki.net/wiki/Access_Design:Parameterabfrage
Hallo,
natürlich haben ebs17 und DF6GL recht wenn sie das mit Formular lösen wollen.
Aber: Im Rahmen einer Lehrerfortbildung habe ich Lehrer in ACC unterrichtet. Dabei habe ich
festgestellt das manche Vorgaben praxisfremd, um nicht zu sagen Blödsinn, sind.
Aufgabe ist eine Parameterabfrage zu machen. Dafür gibt es Punkte. Die richtig Lösung mit
dem Formular ist nicht gefragt, und obwohl besser gibt es dafür keine Punkte.
Da kann man sich aufregen aber es ist halt so.
PS: Die meisten Lehrer waren sehr motiviert und haben selber den Kopf geschüttelt. Also nicht pauschal auf die
Lehrer schimpfen.
Gruß
Johann
Hallo,
naja, das muss halt nur der eine Lehrer die Kritik vertragen... ;D
ok, ich habe das Anfangs-Posting nicht mehr gelesen:
"Gefordert ist eine Bericht der auf einer Abfrage mit Parameterübergabe basiert "
Dazu ist aber mein Vorschlag, die Formatierungen nicht in der Abfrage, sondern eben im Bericht zu machen, weiterhin gültig.
Weiterhin könnten selbst die Berechnungen im Bericht und nicht in der Abfrage (die dann nur gefilterte Tabellendaten mit den evtl. statischen Parameterwerten liefert) stattfinden.
ZitatWie ebs17 schon angemerkt hat, sollte man auf solche Parameter in Abfragen gänzlich verzichten.
So hatte ich das nicht angemerkt. Parameterabfragen sind schon sehr sinnvoll, weil deren optimierter Ablaufplan in kompilierter Form vorliegt und sie daher (gemessen nur an diesem Punkt, es gibt weitere) schneller ausgeführt werden als eine live zusammengesetzte SQL-Anweisung.
Abfragen sind die erste Bearbeitungsschicht auf den Tabellen, und sie können eben durch die Parameter aus einer direkten Abhängigkeit und Verkopplung zu Formularen befreit werden. Der Vorteil wird dann klarer, wenn man eine Mehrfachnutzung seiner durchdachten Abfragen und Formulare vorsieht.
Allerdings muss man beim Begriff Parameterabfrage ein wenig differenzieren. Das macht der Beitrag im DBWiki derzeit auch noch nicht.
Die Parameterabfrage für Arme und Einfache (häufig verwendet) ist die, wo man für die Abfrage unbekannte Bezeichner in eckigen Klammern verwendet, die dann bei Abfrageausführung nach zugehörigen Werten abgefragt werden. Das ist wie gesagt schnell erstellt, aber im Bedienkomfort anstrengend und durchaus fehleranfällig. Dazu nimmt der DBWiki-Beitrag Stellung. Ein fehlerhafter Feldbezeichner hat übrigens die gleiche Wirkung. Darüber könnte man nachdenken.
Eine richtige Parameterabfrage hat in der Abfragedefinition zusätzlich eine Parameter-Auflistung (jeweils Bezeichnung und Datentyp), und damit kann man bereits mit Abfrageaufruf die benötigten Werte an die Parameterfelder übergeben, vgl. donkarl FAQ6.16.
Hier hat man dann die Möglichkeit, errechnete oder per Formular eingegebene Werte weiter zu reichen inkl. einer vielleicht notwendigen Prüfung auf Plausibilität.
Und: Dass Lehrmeinungen und reale (gute) Praxis voneinander abweichen können, ist nun kein besonderer neuer Fall. Manchmal sollte Planer von Lehrinhalten weniger in ihre eigenen Bücher schauen und im eigenen Saft schmoren, sondern sich in der gelebten Praxis erden.
Axel J. Bertling sagte: >>Früher gab es Postkutschen. Heute gibt es Raketen. Was sagt uns das?<<
MfGA
ebs