unter Access kann man in einer Abfrage ja mit DSUM () arbeiten, Unter SQL
ist dies nicht möglich.
Wie muß denn dazu der genaue Syntax lauten, damit ich die Abfrage auf dem
SQL ausführen kann?
Hatte mal versucht mit
Select *, (Select Sum(Datenfeld2) as Test FROM Tabelle2 WHERE Kriterium)
FROM Tabelle1
dann bekomme ich im QueryAnalyser den Fehler
"Nur ein einziger Ausdruck kann in der Auswahlliste angegeben werden, wenn
die Unterabfrage nicht mit EXISTS eingeleitet wird."
zurück.
Wie realisiert ihr so etwas. SQL-FAQ von Bernd Jungbluth hab ich schon
einmal durchsucht, aber nix gefunden (vielleicht auch blind gewesen)
Grüße
Helge
> Select *, (Select Sum(Datenfeld2) as Test FROM Tabelle2 WHERE
> Kriterium) FROM Tabelle1
...
> Wie realisiert ihr so etwas. SQL-FAQ von Bernd Jungbluth hab ich schon
> einmal durchsucht, aber nix gefunden (vielleicht auch blind gewesen)
Ich hab' Deine Abfrage mal mit (unsinnigen) Tabellen bei mir nachgebaut,
lief ohne Fehlermeldung.
Zum Vergleich:
SELECT *, (SELECT SUM(Nr) FROM Bezirk WHERE Plz='4711') FROM Anrede
Gruss,
Juergen
danke für die super turbo schnelle Antwort.
Hmm, vielleicht liegt mein Problem ja auch in den Kriterien. Hier habe ich
das Problem, daß das Datenfeld in beiden Tabellen den gleichen Namen hat.
Also:
Select Lfdnr, Datenfeld1, (Select Sum(Datenfeld2) as Test FROM Tabelle2
WHERE Lfdnr=Lfdnr) FROM Tabelle1
Im VBA-Code würd ich das Kriterium mit "LfdNr=" & Me!LfdNr bilden. Aber im
SQL ????
Grüße
Helge
>
> Gruss,
> Juergen
schreit das nicht nach einem InnerJoin ?!
HTH Jürgen
> Select Lfdnr, Datenfeld1, (Select Sum(Datenfeld2) as Test FROM
> Tabelle2 WHERE Lfdnr=Lfdnr) FROM Tabelle1
>
> Im VBA-Code würd ich das Kriterium mit "LfdNr=" & Me!LfdNr bilden.
> Aber im SQL ????
Ja, hier würde ich auch JOINen.
Aber auch dann musst Du die Felder mit ihren Tabellen-Namen qualifizieren:
WHERE/ON dbo.Tabelle1.Lfdnr = dbo.Tabelle2.Lfdnr
Gruss,
Juergen
> unter Access kann man in einer Abfrage ja mit DSUM () arbeiten, Unter SQL
> ist dies nicht möglich.
> Wie muß denn dazu der genaue Syntax lauten, damit ich die Abfrage auf dem
> SQL ausführen kann?
>
> Hatte mal versucht mit
>
> Select *, (Select Sum(Datenfeld2) as Test FROM Tabelle2 WHERE Kriterium)
> FROM Tabelle1
>
> dann bekomme ich im QueryAnalyser den Fehler
> "Nur ein einziger Ausdruck kann in der Auswahlliste angegeben werden, wenn
> die Unterabfrage nicht mit EXISTS eingeleitet wird."
> zurück.
Sieht dein Statement exakt so aus, wie du es oben geschrieben
hast? - Denn eigentlich funktioniert es so!
Etwas besser (eindeutiger und Aliasvergabe) wäre es so:
SELECT Tabelle1.*,
(SELECT Sum(Datenfeld2)
FROM Tabelle2
WHERE Kriterium) AS Test
FROM Tabelle1
Aber deine Variante sollte auch funktionieren!
Gruß
Phil
--
Bitte verwendet für Fragen zu Access mit DBMS-Server-Backends
die Newsgroup microsoft.public.de.access.clientserver! Danke!
Richtig zitieren im Usenet -> http://got.to/quote
> schreit das nicht nach einem InnerJoin ?!
Hab das auch mal versucht (in einer Access-Abfrage), erhalte dann aber einen
Fehler mit Aggregat-Funktion
Bevor ich euch hier mit evtl. falsch ausgedrückten Bezeichnungen aufhalte,
habe ich mal die ORIGINAL Access-Abfrage eingefügt
##### Schnipp ##########
SELECT
[Rezeptur, Einsatzstoffe].RezeptNr,
[Produktion, Einsatzstoffe].[KalkulationspreisMonat]*[Teile]/
(DSum("Teile","Rezeptur, Einsatzstoffe","RezeptNr=" & [RezeptNr]))
AS KalkulationspreisMonat
FROM [Produktion, Einsatzstoffe]
INNER JOIN [Rezeptur, Einsatzstoffe]
ON [Produktion, Einsatzstoffe].LfdNr = [Rezeptur,
Einsatzstoffe].Einsatzstoff
ORDER BY [Rezeptur, Einsatzstoffe].RezeptNr;
##### Schnipp ##########
Muß allerdings eingestehen, daß ich mit dem Verständnis von JOINS (als
SQL-Syntax) noch so meine Anlaufprobleme habe.
Grüße
Helge
> Muß allerdings eingestehen, daß ich mit dem Verständnis von JOINS (als
> SQL-Syntax) noch so meine Anlaufprobleme habe.
Mal komplett ungetestet als Denkansatz:
SELECT
RE.RezeptNr,
PE.[KalkulationspreisMonat]* PE.[Teile]/SUM(RE2.Teile) AS
KalkulationspreisMonat
FROM [Produktion, Einsatzstoffe] AS PE
INNER JOIN [Rezeptur, Einsatzstoffe] AS RE
ON PE.LfdNr = RE.Einsatzstoff
INNER JOIN [Rezeptur, Einsatzstoffe] AS RE2
ON RE.RezeptNr = RE2.RezeptNr
GROUP BY RE.RezeptNr
ORDER BY RE.RezeptNr;
Gruss,
Juergen
> Mal komplett ungetestet als Denkansatz:
>
> SELECT
> RE.RezeptNr,
> PE.[KalkulationspreisMonat]* PE.[Teile]/SUM(RE2.Teile) AS
> KalkulationspreisMonat
> FROM [Produktion, Einsatzstoffe] AS PE
> INNER JOIN [Rezeptur, Einsatzstoffe] AS RE
> ON PE.LfdNr = RE.Einsatzstoff
> INNER JOIN [Rezeptur, Einsatzstoffe] AS RE2
> ON RE.RezeptNr = RE2.RezeptNr
> GROUP BY RE.RezeptNr
> ORDER BY RE.RezeptNr;
Wenn ich das so umsetzte erhalte ich nun den Fehler
"Die PE.KalkulationspreisMonat-Spalte ist in der Auswahlliste ungültig, da
sie nicht in einer Aggregatfunktion und nicht in der GROUP BY-Klausel
enthalten ist."
Mal ein anderer Denkansatz ...... wäre es nicht besser, sich für die
DomSumme eine SP zu programmieren? Evtl gibt es so etwas ja schon. Habe beim
Googeln die Seite http://www.kulpa-online.de/tipps/msaccess/409.htm
entdeckt. Evtl ist so etwas ja auch in einer SP nachbildbar.
Was hällst Du davon?
Grüße
Helge
Grüße
Helge
Helge Wehrmann <helge.w...@gmx.de> schrieb ...
>> Mal komplett ungetestet als Denkansatz:
>>
>> SELECT
>> RE.RezeptNr,
>> PE.[KalkulationspreisMonat]* PE.[Teile]/SUM(RE2.Teile) AS
>> KalkulationspreisMonat
>> FROM [Produktion, Einsatzstoffe] AS PE
>> INNER JOIN [Rezeptur, Einsatzstoffe] AS RE
>> ON PE.LfdNr = RE.Einsatzstoff
>> INNER JOIN [Rezeptur, Einsatzstoffe] AS RE2
>> ON RE.RezeptNr = RE2.RezeptNr
>> GROUP BY RE.RezeptNr
>> ORDER BY RE.RezeptNr;
>
> Wenn ich das so umsetzte erhalte ich nun den Fehler
> "Die PE.KalkulationspreisMonat-Spalte ist in der Auswahlliste
> ungültig, da sie nicht in einer Aggregatfunktion und nicht in der
> GROUP BY-Klausel enthalten ist."
Jürgens Ansatz umgestellt:
SELECT
RE.RezeptNr,
PE.[KalkulationspreisMonat]* PE.[Teile]/SUM(RE2.Teile) AS
KalkulationspreisMonat
FROM [Produktion, Einsatzstoffe] AS PE
INNER JOIN (SELECT
RezeptNr,
SUM(Teile) AS KalkulationspreisMonat
FROM [Rezeptur, Einsatzstoffe]
GROUP BY RezeptNr) AS RE2
ON RE.RezeptNr = RE2.RezeptNr
ORDER BY RE.RezeptNr;
> Mal ein anderer Denkansatz ...... wäre es nicht besser, sich für die
> DomSumme eine SP zu programmieren? Evtl gibt es so etwas ja schon.
Das würde letztendlich etwas sinnfrei sein:
In SQL gehören Aggregate jeglicher Art und Weise zum Grundhandwerkszeug.
Schon bei Access/Jet schlich sich mir DomXXX nicht in einer SQL-Anweisung
ins Haus. Weil a) ineffizient und b) fehleranfällig durch die dynamische
WHERE Klausel Verknüpferei, die letztendlich hintersteht.
Wenn Du so genau den Ausdruck da mehrmalig brauchst und nur
einmalig schreiben willst, wäre bei SQL Server 2000 eine
Inline-Funktion eher das geeignete Mittel.
> Habe beim Googeln die Seite
> http://www.kulpa-online.de/tipps/msaccess/409.htm entdeckt.
So eine Funktion kann bestenfalls (in Maßen eingesetzt) eher in
einer ADP helfen, um eine effizientere DomSumme für Feldfunktionen
zu verwenden (DomSumme ist noch ineffizienter).
Gruss
Elmar
Funzt auch nicht. Bekomme dann den Fehler
"Das Spaltenpräfix 'RE' stimmt mit keinem in der Abfrage verwendeten
Tabellen- oder Aliasnamen überein."
>
> > Habe beim Googeln die Seite
> > http://www.kulpa-online.de/tipps/msaccess/409.htm entdeckt.
>
> So eine Funktion kann bestenfalls (in Maßen eingesetzt) eher in
> einer ADP helfen, um eine effizientere DomSumme für Feldfunktionen
> zu verwenden (DomSumme ist noch ineffizienter).
War ja auch nur als Ansatz gedacht. Quasi als SQl-Funktion, welche dann in
einem View oder SP aufgerufen werden kann. Ähnlich der DomSumme-Funktion.
Grüße
Helge
Dann füge bitte wieder
>>> INNER JOIN [Rezeptur, Einsatzstoffe] AS RE
>>> ON PE.LfdNr = RE.Einsatzstoff
ein. Da ist beim Copy'n Paste etwas durchgeschlüpft,
das Suchen ist die Strafe für solche Tabellennamen ;-)
Gruss
Elmar
danke für Deinen Nachtrag. Wegen einer Dienstreise kam ich allerdings noch
nicht zum testen.
Werde es nächste Wochen testen und berichtet.
Gepflegtes Wochenende
Helge
"Elmar Boye" <Elm...@gmx.net> schrieb im Newsbeitrag
news:brsf2u$6avti$1...@ID-28695.news.uni-berlin.de...