Wieder hilfe bei Datenbankabfrage...

[AJRames]

Hi Leute! Ich weiss wieder nicht wie ich das lösen sollt.

Folgender Aufbau. Ich habe Firmen in der Datenbank. Diese Firmen besitzen mehrere Produkte. Auf diese gekauften Produkte haben die Firmen jeweils Supportverträge.

Z.b. Die Firma "FISI" hat ein Produkt "EINS" dessen Support am 31.05.2009 endet. und ein Produkt namens "ZWEI" dessen Support am 31.06.2009 endet.

Nun möchte ich mit meiner Abfrage alle Firmen (und deren infos) ausgeben bei denen ein Produkt bis zum 31.07.2009 ausläuft.

Theoretisch so ähnlich:

SELECT DISTINCT KDNR FROM TABELLE WHERE SUPPORT < '31.07.2009'

liefert das korrekte Ergebnis. Aber ich benötige mehr als nur die KDNR...

Ein SELECT DISTINCT * geht ja nicht....

SELECT * FROM TABELLE WHERE SUPPORT < '31.07.2009');

Zeigt mir die eine Firma öfter an...das sollte auch nicht sein...

Ich brauche die Firma nur einmal, damit ich weiß das bei Firma "Heinz" der support bis zum 31.07.2009 ausläuft.

Jemand ne Idee?

[Amstelchen]

und du hast nur eine "firmen"-tabelle?

wo in deiner abfrage referenzierst du denn auf ein "produkt"?

wenn du zwei tabellen für firma und produkt hast, verwende einen JOIN.

SUPPORT ist ein feld vom datumstyp?

s'Amstel

[perdian]

Jemand ne Idee?

Du möchtest dich noch einmal mit einem Tutorial zu den Grundlagen von SQL beschäftigen, ganz speziell mit dem GROUP BY Kapitel.

[AJRames]

Ja Group by hab ich mir auch gedacht, aber das kann ich meines wissens nur auf aggregatsfunktionen anwenden, das geht hier ja nicht.... (so ganz unwissend bin ich dann doch nicht ^^ )

@Amstelchen: Jep, ist ein Datumsfeld.

Eigentlich führe ich die Abfrage auf einer Tabelle durch.

Diese hat die Spalten: KDNR, Produkt, noch einige, Support.

Ich bräucht die Infos vom "ältesten" (wenn mans so nennen will)

[perdian]

Ich bräucht die Infos vom "ältesten" (wenn mans so nennen will)

Aus dem Bauch heraus:

select min(datefield), customer_id from source group by customer_id

Dann im zweiten Schritt mit den Daten weiterarbeiten, evtl. zweiten Request durchführen oder eine nested query verwenden.

[AJRames]

SELECT * FROM (SELECT MAX(SUPPORT) AS SUPPORT, KDNR FROM TABELLE GROUP BY KDNR) WHERE SUPPORT < '"+end+"';

'end' ist hierbei das Datum das ich manuell in mein Programm eingebe.

Prizipiell ists das! Doch ich kann nicht mehr Als KDNR und das Supportdatum ausgeben. Ich bräuchte eigentlich dort auch alle felder.....Also:

SELECT * FROM (SELECT * , MAX(SUPPORT) AS SUPPORT FROM....

Aber das nimmter nicht weil ja Support in dem * auch drin ist...

Sobald ich mehr eingeb, gibts ne Fehlermeldung, zb:

SELECT * FROM (SELECT MAX(SUPPORT) AS SUPPORT, KDNR, ANSPRECHPARTNER... FROM ...

Fehler: Not in aggregate function or group by clause...

[Reinhold]

Moin,

SUPPORT ist ein feld vom datumstyp?

extrem unwahrscheinlich, da es auch den "31.06.2009" enthält, IMHO kein gültiges Datm.

*duck*

Reinhold

[AJRames]

Ja, 31.07 sollte da stehn Mein Fehler...

Aber anscheinend kann mir wohl keiner grad weiter helfen...

[dimikar]

Wenn ichs es richtig verstehe dann sind Firmen und Produkte in einer Tabelle zusammengespeichert?

Meine Empfehlung wäre diese "Tabelle" zu normalisieren und diese Daten zu trennen.

Wenn Du es nicht kannst oder besser gesagt nicht darfst dann solltest Du in deinem Select Statement ein Bisschen vom "*" weg denken dann klappt das schon.

ZB:

SELECT DISTINCT tab.kdnr

               ,tab.kdname

               ,tab.[alle weitere Spalten die [B][COLOR="Red"]nur [/COLOR][/B]mit dem Kunden zu tun haben]

FROM tabelle tab

WHERE tab.suport < '31.07.2009'

Ein weiterer Hinweis: Je nach DBMS musst Du das 'Datum' IN ein echtes Datum umwandeln. Meistens wird ein implizites Casting vorgennomen aber drauf verlassen sollte man sich nicht.

Manch mal ist nämlich der "01.12.2009' ganz schnell der 12. Januar.

[T3D]

WHERE tab.suport < '31.07.2009'

rein logisch duerfte das nicht das richtige ergebnis zurueckgeben, denn 30.08.2009 < 31.07.2009

Aber hast ja auch dazugeschrieben das du das datum "umcasten" wuerdest

Wollts nur noch mal gesagt haben

[dimikar]

Ja genau der falsche ( quasi String) Vergleich ist ein weiterer Grund warum man sich nicht auf implizite Castings verlassen sollte.

Gut dass hier noch einen gibt der gut aufpasst.

[Amstelchen]

der fehler an solchen ansätzen ist halt oftmals, dass unbedarfte anfänger wider besseren wissens viele dinge implementieren, die die datenbank ohnehin schon seit jahrzehnten als feature anbietet.

datumsfelder die aber als textfelder angelegt werden, in denen z.b. der 32. (sic!) des monats kein problem darstellt und die durch falsch angelegte sortieralgorithmik dann auch daten falsch verarbeiten, sind da nur die spitze des eisberges, an denen natürlich auch grosse schiffe (=projekte) untergehen können.

es kann hier eben niemals schaden, sich mit den grundlagen (philosophie einer datenbank, normalisierung, relationalität, unterstützte datentypen, spezifika des eingesetzten DBMS) auseinanderzusetzen, bevor man überhaupt eine zeile code schreibt.

aber darüber wurden auch schon bücher geschrieben.

s'Amstel