emw 0 Geschrieben 11. Oktober Melden Teilen Geschrieben 11. Oktober Hallo Leute, ich hoffe, es kann mich jemand erleuchten - ich bin zu doof! Ich arbeite mit cobra CRM und wollte eine Provisionsabfrage erstellen mit SQL. Der Gedanke: Wenn ein Team [TEXT23] den Job erledigt und ein H verkauft wird, dann ist die Prov. Auftragswert [CALCULATE3] * 19 %, wenn gleiches Team verkauft und es ist ein K dann 12 %. Wenn Team anderes ist und H verkauft wird und kein Rabatt gewährt wird, dann 7 % - die letzten Statements beziehen sich dann auf die Höhe des gewährten Rabatts und es gibt jeweils Staffel-Provision. wenn ich das teste, funktioniert alles bis auf die Statements mit dem Range-Bereich - da kommt 0,00 als Ergebnis und ich weiß nicht was schief läuft. Ich habe schon zig Möglichkeiten durch - mit Between getestet, die 3 Rangebereiche umgestellt. die Rangezahlen geändert. (Eigentlich müsste es durch /100 geteilt werden, aber zum Test habe ich jetzt nur /1 geteilt, damit der Multiplikator auf keinen Fall zu klein ist..... (SELECT CASE WHEN ([TEXT23] = 'JA') AND ([TEXT59] ='H') THEN [CALCULATE3]/100*19 WHEN ([TEXT23] = 'JA') AND ([TEXT59] !='H') THEN [CALCULATE3]/100*12 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='H') THEN [CALCULATE3]/100*7 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] = 0 THEN [CALCULATE3]/1*7 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] >= 10 AND [CALCULATE6] <= 100 THEN [CALCULATE3]/1*5 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] >= 1 AND [CALCULATE6] <= 4 THEN [CALCULATE3]/1*6 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] >= 5 AND [CALCULATE6] <= 9 THEN [CALCULATE3]/1*3.5 ELSE [CALCULATE3]*0 END FROM [ADDRESSES] WHERE [ID]=@recid) Wenn hier kein Fehler meines SQL von euch zu sehen ist, dann muss ich wohl kapitulieren - der CRM-Hersteller fühlt sich für die SQL-Abfragen nicht zuständig - finde ich klasse! Von dort kommt keine Hilfe Beste Grüße Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 11. Oktober Melden Teilen Geschrieben 11. Oktober Zunächst würde ich mit Between arbeiten: https://www.w3schools.com/sql/sql_between.asp Welchen Datentyp hat "CALCULATE6"? Wenn der zufällig VARCHAR o.ä. ist, würde mich das Ergebnis nicht wundern, Zitieren Link zu diesem Kommentar
emw 0 Geschrieben 11. Oktober Autor Melden Teilen Geschrieben 11. Oktober Hallo, das Feld ist im CRM ein Rechenfeld (CALCULATE=Rechenfeld) - Formatiert hab ich zum Test als Zahl optional als Prozent - fährt alles an die Wand. Da aber die Berechnung mit =0 korrekt mit 7 % Rabatt berechnet wird, kann es an den Feldern und ihrer Formatierung nicht liegen - oder? alles was mit = geprüft wird, klappt, nur wenn ich stattdessen einen Range abfrage, dann ...... Hoffe Ihr könnt mir einen Tipp geben! Beste Grüße Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 11. Oktober Melden Teilen Geschrieben 11. Oktober Das ist dann aber kein Datentyp, sondern da steckt eine Rechenformel oder Sub-Query für das Feld hinter. MS macht hier gelegentlich merkwürdige Sachen. Meine Ansicht nach, packt man sowas komplett ein eine View. Schaue Dir mal das DDL der Tabelle an, sonst kommst Du nicht weiter. Da muss als Ergebnis auch nicht zwangsläufig ein Datentyp rauskommen, mit dem man rechnen kann. https://www.sqlshack.com/an-overview-of-computed-columns-in-sql-server/ Zitieren Link zu diesem Kommentar
t-sql 18 Geschrieben 11. Oktober Melden Teilen Geschrieben 11. Oktober Setz einfach mal die Klammern richtig. Zumindest um den Rangebereich müssen Klammern. ([TEXT23] = 'NEIN' AND [TEXT59] ='K') AND ([CALCULATE6] >= 10 AND [CALCULATE6] <= 100) Zitieren Link zu diesem Kommentar
NilsK 2.932 Geschrieben 11. Oktober Melden Teilen Geschrieben 11. Oktober Moin, vor 3 Stunden schrieb emw: das Feld ist im CRM ein Rechenfeld (CALCULATE=Rechenfeld) vor 2 Stunden schrieb zahni: MS macht hier gelegentlich merkwürdige Sachen. Cobra CRM ist aber nicht von Microsoft, die können an der Stelle nichts dafür. Was das auf SQL-Ebene für ein Datentyp ist, müsste man noch rausbekommen. Dass es mit dem Wert 0 geht, mit anderen aber nicht, kann tatsächlich ein Indiz für einen Datentyp-Fehler sein. Gruß, Nils Zitieren Link zu diesem Kommentar
winmadness 79 Geschrieben 12. Oktober Melden Teilen Geschrieben 12. Oktober (bearbeitet) Ich vermute dass das Calculate Field zum Zeitpunkt der Abfrage noch gar nicht „berechnet“ ist und somit der Wert immer 0 ist. Zum Testen eine der Abfragen in >= 0 ändern, z.B. ... WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] >= 0 AND [CALCULATE6] <= 100 THEN [CALCULATE3]/1*5 ... bearbeitet 12. Oktober von winmadness Zitieren Link zu diesem Kommentar
Lian 2.421 Geschrieben 12. Oktober Melden Teilen Geschrieben 12. Oktober Seid so gut und verwendet im Editor den Code Button </> im Format SQL. Danke Zitieren Link zu diesem Kommentar
t-sql 18 Geschrieben 12. Oktober Melden Teilen Geschrieben 12. Oktober Nützt alles nix solange keine Klammern gesetzt sind. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 14. Oktober Melden Teilen Geschrieben 14. Oktober Da ich MS-SQL nur begrenzt kenne: Wozu sind die eckigen Klammern gut? Wir nutzen hier umfänglich DB2. Sowas gibt es dort nicht. Zitieren Link zu diesem Kommentar
NilsK 2.932 Geschrieben 14. Oktober Melden Teilen Geschrieben 14. Oktober Moin, vor einer Stunde schrieb zahni: Da ich MS-SQL nur begrenzt kenne aber genug, um dich drüber zu mokieren? SCNR Die eckigen Klammern unterscheiden Bezeichner von Schlüsselwörtern. Die braucht man eigentlich nur, wenn man einen Bezeichner ungünstig wählt, aber Code-Generatoren setzen die vorsichtshalber immer. Gruß, Nils Zitieren Link zu diesem Kommentar
emw 0 Geschrieben 14. Oktober Autor Melden Teilen Geschrieben 14. Oktober Hallo, leider hat auch der Tipp mit der Klammer nichts geholfen - es klappt nur bis Rabtt 0 Prozent -> Provision 7 %. ab der folgenden Zeile rechnet SQL immer mit 6 % Provision - egal ob ich 0.99 % oder 16 % Rabatt habe - völlig wurscht - ich schätze ich muss kapitulieren und das ärgert mich maßlos. Hat vielleicht noch irgend wer einen logischen Fehler gefunden?? Ich habe extra zuerst mit 16 % Rabatt getestet - er kann eigentlich nicht in die darauffolgende Zeile ..... nehme ich anschließend wieder = 0 Rabatt, dann wird wieder korrekt mit 7 % Prov gerechnet, also die Felder richtig befüllt - ich habe leider hier keinerlei Debugg um Zwischenschritte prüfen zu können! (SELECT CASE WHEN ([TEXT23] = 'JA') AND ([TEXT59] ='H') THEN [CALCULATE3]/100*19 WHEN ([TEXT23] = 'JA') AND ([TEXT59] !='H') THEN [CALCULATE3]/100*12 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='H') THEN [CALCULATE3]/100*7 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] = 0 THEN [CALCULATE3]/100*7 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND ([CALCULATE6] > 10 AND [CALCULATE6] <= 100) THEN [CALCULATE3]/100*3 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND ([CALCULATE6] > 0 AND [CALCULATE6] <= 5) THEN [CALCULATE3]/100*6 WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND ([CALCULATE6] > 5 AND [CALCULATE6] <= 10) THEN [CALCULATE3]/100*5 ELSE [CALCULATE3]*0 END FROM [ADDRESSES] WHERE [ID]=@recid) Für eure Bemühungen herzlichsten Dank! Zitieren Link zu diesem Kommentar
NilsK 2.932 Geschrieben 14. Oktober Melden Teilen Geschrieben 14. Oktober Moin, Also ist das Ergebnis jetzt ein anderes als vorher, aber immer noch falsch? Oder wie? Und was meinst du mit vor 14 Minuten schrieb emw: ab der folgenden Zeile rechnet SQL immer mit 6 % Provision ? Was für eine folgende Zeile? Vielleicht solltest du uns auch noch erzählen, wie du deine Tests durchführst. Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 14. Oktober Melden Teilen Geschrieben 14. Oktober vor einer Stunde schrieb NilsK: aber genug, um dich drüber zu mokieren? SCNR Man darf sich aber generell mit SQL auskennen? Microsoft ist hier sicher nicht der Erfinder. Der war IBM https://learnsql.com/blog/history-of-sql/ Zitieren Link zu diesem Kommentar
NilsK 2.932 Geschrieben 14. Oktober Melden Teilen Geschrieben 14. Oktober Moin, Ja, das ist mir bekannt. Und IBM hat in DB2 seinen Dialekt, Oracle hat einen anderen, Microsoft noch einen, Postgres wieder einen anderen. Alle haben ihre Eigenheiten. Und nun? Was hier diskutiert wird, hat mit Spezialitäten einzelner Dialekte bislang wenig zu tun. Möglicherweise sind "seltsame" Dinge in der Art dabei, wie Cobra CRM seine Daten verwaltet, aber nicht mal das wissen wir bisher genauer. Eine launige Bemerkung von dir habe ich mit einer launigen Bemerkung beantwortet. Auf den Schlips treten wollte ich dir nicht. Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.