schwierige sql-abfrage

Re(10): schwierige sql-abfrage

kombipaket — Wed, 23 Jul 2008 22:00:27 GMT

Hmmm... Gibts unter der Access nicht das berühmte "Iif" (echt so geschrieben), daß im Prinzip einem case entspricht ???

Re(10): schwierige sql-abfrage

kombipaket — Wed, 23 Jul 2008 22:00:27 GMT

Hmmm... Gibts unter der Access nicht das berühmte "Iif" (echt so geschrieben), daß im Prinzip einem case entspricht ??? Und ja, es ist eh wurscht

Re(17): schwierige sql-abfrage

Dr. Watson — Wed, 23 Jul 2008 21:51:34 GMT

Das sehe ich anders. Aber kann mir auch egal sein, soll jeder verwenden was er möchte.

Re(16): schwierige sql-abfrage

hellbringer — Wed, 23 Jul 2008 21:49:13 GMT

Eine Alternative verwenden, die besser ist, UND nichts kostet.

Ja, aber du brauchst trotzdem Leute, die einerseits die Datenbank betreuen und andererseits dafür programmieren können. Und das ist bei MySQL eben deutlich einfacher und kostensparender.

Re(15): schwierige sql-abfrage

Dr. Watson — Wed, 23 Jul 2008 21:41:59 GMT

Eine Alternative verwenden, die besser ist, UND nichts kostet.

Re(15): schwierige sql-abfrage

Dr. Watson — Wed, 23 Jul 2008 21:41:59 GMT

Eine Alternative verwenden, die besser ist, UND nichts kostet.

[edit]
Bezogen auf die Lizenz.

Re(14): schwierige sql-abfrage

hellbringer — Wed, 23 Jul 2008 21:40:29 GMT

... und in jedem Fall gibts irgendwann den Punkt, wo man rasant wächst, die Sache geschäftskritisch wird, und dann krachts - nein Danke.

Was ist dein Vorschlag? Jahrelang für etwas Geld ausgeben, was eigentlich nicht gebraucht wird?

Re(13): schwierige sql-abfrage

Dr. Watson — Wed, 23 Jul 2008 21:35:06 GMT

... und in jedem Fall gibts irgendwann den Punkt, wo man rasant wächst, die Sache geschäftskritisch wird, und dann krachts - nein Danke.

Re(12): schwierige sql-abfrage

hellbringer — Wed, 23 Jul 2008 21:33:09 GMT

Ja. MySQL ist zwar keine wirklich gute Datenbank, aber brauchbar ist sie trotzdem. Kommt halt immer auf die Anforderungen an.

Und zwischen Monsterdatenbanken mit Millionen von Einträgen und primitive Gästebücher existiert noch eine große Bandbreite an Anwendungen, die problemlos mit MySQL funktionieren.

Re(11): schwierige sql-abfrage

Dr. Watson — Wed, 23 Jul 2008 21:26:52 GMT

Worauf willst du hinaus? Dass MySQL etwas abseits von Gästebüchern, Foren und Blogs taugt?

Re(10): schwierige sql-abfrage

hellbringer — Wed, 23 Jul 2008 21:20:53 GMT

dass es da keine Cases gibt, war fast klar.

Wie kommst du darauf?

http://dev.mysql.com/doc/refman/5.0/en/control-flow-functions.html

Re(10): schwierige sql-abfrage

hellbringer — Wed, 23 Jul 2008 21:20:53 GMT

dass es da keine Cases gibt, war fast klar.

Wie kommst du darauf?

http://dev.mysql.com/doc/refman/5.0/en/case-statement.html

Re(10): schwierige sql-abfrage

hellbringer — Wed, 23 Jul 2008 21:20:53 GMT

dass es da keine Cases gibt, war fast klar.

Wie kommst du darauf?

http://dev.mysql.com/doc/refman/5.0/en/case-statement.html

Aber warum überhaupt CASE? Ist doch ein typischer IF..ELSE Fall IMHO.

http://dev.mysql.com/doc/refman/5.0/en/if-statement.html

Re(11): schwierige sql-abfrage

Dr. Watson — Wed, 23 Jul 2008 21:17:10 GMT

MySQL kann auch mit InnoDB - gemessen an anderen, ernsthaften Datenbanken - nix.

Re(10): schwierige sql-abfrage

TomCat — Wed, 23 Jul 2008 18:54:37 GMT

Access und MySQL sind nicht unbedingt das, was ich unter "Datenbank" verstehe

ACCESS verstehe ich, aber MySQL (zumindest die Enterprise Version) kann schon so einiges. Darf man nicht mit der alten Open Source Version ohne Transaktionsverarbeitung verwechseln.

Re(10): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 11:13:46 GMT

Unter MySQL gehts sogar

Aber unter Access nicht. Und ich habe ja nur schnell ne DB angelegt um das für den TE zu testen.

Re(5): schwierige sql-abfrage

_flump — Tue, 22 Jul 2008 11:04:58 GMT

jetzt funktionierts:

select to_char(b.BELEGDATUM,'YYYY-MM-DD') as Belegdatum, b.gptnrkdb, g.name1, b.STEUERLBEH as Steuercode, CASE WHEN b.steuerlbeh=12 THEN sum(b.rechnungsbetrag/1.2) ELSE sum(b.rechnungsbetrag) END AS nettobetrag, sum(b.RECHNUNGSBETRAG) as Rechnungsbetrag, to_char(b.belegdatum,'YYYY-MM') as Periode
from bhtfakt b
join geschpartner g on b.gptnrkdb = g.gptnr
where b.belegdatum >= to_date('2008-01-01', 'YYYY-MM-DD') and b.mandantnr = 41
group by to_char(b.belegdatum, 'YYYY-MM-DD'), b.gptnrkdb, b.STEUERLBEH, g.name1, to_char(b.belegdatum, 'YYYY-MM')

vielen dank für eure hilfe!

lg, flump

Re(9): schwierige sql-abfrage

Dr. Watson — Tue, 22 Jul 2008 11:00:49 GMT

Access und MySQL sind nicht unbedingt das, was ich unter "Datenbank" verstehe.
Eher eine Notlösung um simple Aufgaben schnell zu erledigen, dass es da keine Cases gibt, war fast klar.

Re(8): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 10:46:00 GMT

Suchst du deinen Namen im Forum?

Und ich meinte nicht dich, sondern Pervasive die Datenbank!
http://www.pervasive.com/

Hast du was mit denen zum tun?

Re(7): schwierige sql-abfrage

Pervasive — Tue, 22 Jul 2008 10:24:30 GMT

und bei Pervasive hats gesponnen

Re(4): schwierige sql-abfrage

_flump — Tue, 22 Jul 2008 10:20:58 GMT

das bekomm ich so leider nicht hin.

meine abfrage schaut so aus:

select to_char(b.BELEGDATUM,'YYYY-MM-DD') as Belegdatum, b.gptnrkdb, g.name1 as KDB, b.STEUERLBEH as Steuercode, sum(b.RECHNUNGSBETRAG) as Rechnungsbetrag, to_char(b.belegdatum,'YYYY-MM') as Periode, CASE WHEN b.steuerlbeh=12 THEN b.rechnungsbetrag/1.2 ELSE b.rechnungsbetrag END AS nettobetrag
from bhtfakt b
join geschpartner g on b.gptnrkdb = g.gptnr
where b.belegdatum >= to_date('2008-01-01', 'YYYY-MM-DD') and b.mandantnr = 41
group by to_char(b.belegdatum, 'YYYY-MM-DD'), b.gptnrkdb, b.STEUERLBEH, g.name1, to_char(b.belegdatum, 'YYYY-MM')

fehlermeldung:

< DBD::Oracle::db prepare failed: ORA-00979: not a GROUP BY expression (DBD ERROR: error possibly near <*> indicator at char 231 in 'select to_char(b.BELEGDATUM,'YYYY-MM-DD') as Belegdatum, b.gptnrkdb, g.name1 as KDB, b.STEUERLBEH as Steuercode, sum(b.RECHNUNGSBETRAG) as Rechnungsbetrag, to_char(b.belegdatum,'YYYY-MM') as Periode, CASE WHEN b.steuerlbeh=12 THEN <*>b.rechnungsbetrag/1.2 ELSE b.rechnungsbetrag END AS nettobetrag from bhtfakt b join geschpartner g on b.gptnrkdb = g.gptnr where b.belegdatum >= to_date('2008-01-01', 'YYYY-MM-DD') and b.mandantnr = 41 group by to_char(b.belegdatum, 'YYYY-MM-DD'), b.gptnrkdb, b.STEUERLBEH, g.name1, to_char(b.belegdatum, 'YYYY-MM')') [for Statement "select to_char(b.BELEGDATUM,'YYYY-MM-DD') as Belegdatum, b.gptnrkdb, g.name1 as KDB, b.STEUERLBEH as Steuercode, sum(b.RECHNUNGSBETRAG) as Rechnungsbetrag, to_char(b.belegdatum,'YYYY-MM') as Periode, CASE WHEN b.steuerlbeh=12 THEN b.rechnungsbetrag/1.2 ELSE b.rechnungsbetrag END AS nettobetrag from bhtfakt b join geschpartner g on b.gptnrkdb = g.gptnr where b.belegdatum >= to_date('2008-01-01', 'YYYY-MM-DD') and b.mandantnr = 41 group by to_char(b.belegdatum, 'YYYY-MM-DD'), b.gptnrkdb, b.STEUERLBEH, g.name1, to_char(b.belegdatum, 'YYYY-MM')"] at /www/docs/public/cqs/lib/CQSdb.pm line 891. >

Re(8): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 10:00:12 GMT

Ich will darauf hinaus, dass ich beim googeln auf die schnelle nur MS SQL Datenbanken gefunden habe wo case bestätigt wird.
Von daher dachte ich, dass es nur unter MS SQL funktioniert (wie ziemlich viele Dinge)
Habs jetzt auf oracle und mysql probiert und da gehts auch. Nur bei Access (war meine Test DB) gings nicht.

Re(7): schwierige sql-abfrage

Dr. Watson — Tue, 22 Jul 2008 09:55:40 GMT

Worauf willst du hinaus?

Meine Aussage war nicht, dass ein CASE dem SQL Standard entspricht, sondern dass sich mein Beispiel nicht auf MSSQL bezog. Soweit ich weiß kennt MSSQL kein TO_CHAR, welches der Autor jedoch in seinen Beispielen verwendet - ergo wird er Oracle oder Postgres verwenden, und da gibts CASES.

Re(6): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 09:53:21 GMT

Oho!
Dann ging das nur unter Access nicht und bei Pervasive hats gesponnen

Naja, so kann man sich täuschen

Re(5): schwierige sql-abfrage

Dr. Watson — Tue, 22 Jul 2008 09:23:55 GMT

Nein, ist keine MS SQL Funktion.

Davon abgesehen interessiert mich der SQL Standard Nüsse, wenn die DB die ich verwende, diese Features bereitstellt.

Re(4): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 09:21:30 GMT

Dir ist schon klar dass das eine MS SQL Funktion ist und kein SQL Standard!

Re(3): schwierige sql-abfrage

Dr. Watson — Tue, 22 Jul 2008 09:10:56 GMT

eines möchte ich noch einbauen, wenns denn möglich ist.
ich sollte noch eine spalte "nettobetrag" errechnen.
wenn der steuercode 12 ist dann soll "Rechnungsbetrag"/1,2 ausgegeben werden
ansonsten "Rechnungsbetrag" (da dieser sonst keine ust enthält)

SELECT fields, CASE WHEN steuercode=12 THEN rechnungsbetrag/1,2 ELSE rechnungsbetrag END AS nettobetrag FROm table WHERE conditions;

Re(3): schwierige sql-abfrage

Dr. Watson — Tue, 22 Jul 2008 09:10:56 GMT

eines möchte ich noch einbauen, wenns denn möglich ist.
ich sollte noch eine spalte "nettobetrag" errechnen.
wenn der steuercode 12 ist dann soll "Rechnungsbetrag"/1,2 ausgegeben werden
ansonsten "Rechnungsbetrag" (da dieser sonst keine ust enthält)

SELECT fields, CASE WHEN steuercode=12 THEN rechnungsbetrag/1,2 ELSE rechnungsbetrag END AS nettobetrag FROm table WHERE conditions;

[edit]

Evtl. musst du noch Casten.
Da du deine DB nicht angegeben hast, kann ich dir kein Beispiel liefern.

Re(2): schwierige sql-abfrage

_flump — Tue, 22 Jul 2008 08:54:15 GMT

hi!

danke für eure hilfe!
ich hab bis vor 5 jahren kleinere webdatenbanken bearbeitet (php, mysql), aber schon wieder viel zu viel vergessen.
in der firma werden aber meine (schon sehr geschrumpften) kenntnisse gerne angenommen...

meine abfrage sieht jetzt wie folgt aus:

select to_char(b.BELEGDATUM,'YYYY-MM-DD') as Belegdatum, b.gptnrkdb, g.name1 as KDB, b.STEUERLBEH as Steuercode, sum(b.RECHNUNGSBETRAG) as Rechnungsbetrag, to_char(b.belegdatum,'YYYY-MM') as Periode
from bhtfakt b
join geschpartner g on b.gptnrkdb = g.gptnr
where b.belegdatum >= to_date('2008-01-01', 'YYYY-MM-DD') and b.mandantnr = 41
group by to_char(b.belegdatum, 'YYYY-MM-DD'), b.gptnrkdb, b.STEUERLBEH, g.name1, to_char(b.belegdatum, 'YYYY-MM')

eines möchte ich noch einbauen, wenns denn möglich ist.
ich sollte noch eine spalte "nettobetrag" errechnen.
wenn der steuercode 12 ist dann soll "Rechnungsbetrag"/1,2 ausgegeben werden ansonsten "Rechnungsbetrag" (da dieser sonst keine ust enthält)

wäre toll wenn mir das noch jemand erklären könnte.

vielen dank, flump

Re(7): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 07:29:26 GMT

Naja, solange man nicht nach dem Weg fragt, sondern nur nach dem Ziel wirds schwierig.

Ich könnte ihm den Befehl ja auch erklären, aber das war nicht die Frage..

Re(5): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 07:21:42 GMT

Aber wenn diese Abfrage für den TE schon schwierig ist, dann sollte ich dem mal ein paar Subselects zeigen von mir zeigen (die 700 Zeichen lang sind )

Re(3): schwierige sql-abfrage

thE — Tue, 22 Jul 2008 07:15:55 GMT

Habs abgeändert.. OMG da war ein from und im sum war die Tabelle

Re: schwierige sql-abfrage

thE — Tue, 22 Jul 2008 07:13:05 GMT

select verkäufer, ustcode, datum, sum(betrag) from rechnung where datum > to_date('2008-01-01', 'YYYY-MM-DD') group by verkäufer, datum, ustcode

Ich muss es aber noch testen. Aber so würdes meiner Meinung nach gehen

Re: schwierige sql-abfrage

thE — Tue, 22 Jul 2008 07:13:05 GMT

select verkäufer, ustcode, datum, sum(rechnung) where datum > to_date('2008-01-01', 'YYYY-MM-DD') group by verkäufer, datum, ustcode

Ich muss es aber noch testen. Aber so würdes meiner Meinung nach gehen

schwierige sql-abfrage

_flump — Tue, 22 Jul 2008 06:56:52 GMT

guten morgen!

ich hoffe jemand kann mir bei meiner sql-abfrage helfen.

tabelle: rechnung
spalten: datum, verkäufer, ustcode, betrag

in dieser tabelle gibt es für jede rechnung einen datensatz.

folgendes ergebnis soll die abfrage bringen:
tagessummen pro verkäufer aufgeteilt nach ustcode.

da wir 3 verschieden ustcodes verwenden können also pro verkäufer/tag bis zu 3 summen gebildet werden.

meine abfrage ohne diese summenbildung lautet:
select datum, verkäufer, ustcode, betrag from rechnung where datum > to_date('2008-01-01', 'YYYY-MM-DD')

ich hoffe ich hab das verständlich beschrieben.

lg, flump