OpenOffice.info

Barlee hat geschrieben:Hallo rso,

Es mag sein, daß man hier mit Hilfe eines Views weiterkommt, in den Du das Konstrukt

Code: Alles auswählen

casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2)

mit einbaust. Als Ergebnis hättest Du denn in Deiner virtuellen Tabelle eine Spalte namens 'Bruttogehalt', mit der Du beliebig weiterrechnen könntest. Es käme auf einen Versuch an...

Gruß Barlee

Hallo Barlee

Ich habe es mit einer View probiert und es klappt tatsächlich. Die Erkenntnis ist also die, dass berechnete Datenfelder, mit denen man weiterrechnen will, auf diese Weise definiert werden müssen. Der Nachteil ist der, dass man die Formel in der View nicht angeben kann. Man sieht nur den Spaltennamen und die korrekte Berechnung, aber man sieht überhaupt nicht, wie die Berechnung zustande kommt. Wenn ich also diesen Weg gehe, heisst das, dass ich die Berechnungsformel in einem separaten File dokumentieren muss, und das finde ich schwerfällig. Mal sehen, ob ich doch noch einen direkten Weg - z.B. mit UPDATE, INSERT oder SET - über SQL finde.

Wenn Du dazu was finden solltest, würde mich dies freuen.

Gruss
rso

Hallo rso,

klar, ich gebe Dir Recht. Es ist schon galanter mit Aliasen zu rechnen anstatt die Berechnung wiederholt einzugeben.
Auch ist klar, daß dieses gerade bei umfangreichen Abfragen zu Lasten der Übersichtlichkeit geht.

Es mag sein, daß man hier mit Hilfe eines Views weiterkommt, in den Du das Konsrukt mit einbaust. Als Ergebnis hättest Du denn in Deiner virtuellen Tabelle eine Spalte namens 'Bruttogehalt', mit der Du beliebig weiterrechnen könntest. Es käme auf einen Versuch an...

Gruß Barlee

Hallo Barlee

Ja, das könnte ich so machen; aber Du gibst mir recht, das ist nicht die "elegante" Methode. Bei diesem kleinen Beispiel macht es zwar tatsächlich keinen Unterschied, aber wenn die Bedingung umfangreicher ist, dann hat man aufgrund der Formelwiederholung eine rechte Menge redundanten Code, was sich nebst der Performance auch auf die Übersichtlichkeit (wegen Wartung und Weiterentwicklung) auswirkt.

Mein aufgeführtes Beispiel ist nämlich nur eine extrem vereinfachte Problemstellung zum Erlernen, wie man diese in SQL grundsätzlich lösen kann. Tatsächlich kommen diese Problemlösungen nachher in viel komplexeren Problemstellungen zum Tragen, wie sich aus nachfolgendem Formelbeispiel - dargestellt in der SQL-Syntax von MS Access - ableiten lässt:

Abfrage: 11 Position tracking

SELECT [10 Transactions].TransactionNo, [10 Transactions].Date, [10 Transactions].Operation, [10 Transactions].Quantity, [10 Transactions].Title, [10 Transactions].Currency, [10 Transactions].UnitPrice, IIf([10 Transactions]![Operation]="Buy",[10 Transactions]![Quantity]*[10 Transactions]![UnitPrice]*-1,[10 Transactions]![Quantity]*[10 Transactions]![UnitPrice]) AS [Market Value], [10 Transactions].Commission, IIf([10 Transactions]![Operation]="Dividend",[10 Transactions]![UnitPrice],[Market Value]+[10 Transactions]![Commission]) AS Total, [10 Transactions].ExchangeRate, IIf(IsNull([10 Transactions]![ExchangeRate]),[Total],[Total]*[10 Transactions]![ExchangeRate]) AS [Total CHF], IIf([10 Transactions]![Operation]="Buy",[Quantity],IIf([10 Transactions]![Operation]="Sale",[Quantity]*-1,0)) AS [Adjusted Quantity], CInt(DSum("[Adjusted Quantity]","11 Position tracking","[Date]*1<=" & [Date]*1)) AS [Total Units], IIf([10 Transactions]![Operation]="Buy",[Total CHF]*-1,IIf([10 Transactions]![Operation]="Sale",[Quantity]*DLast("[ø-Unit Cost]","11 Position tracking","[Date]*1<" & [Date]*1)*-1,0)) AS [Adjusted Total CHF], CCur(DSum("[Adjusted Total CHF]","11 Position tracking","[Date]*1<=" & [Date]*1)) AS [Total Cost], IIf([Total Units]=0,0,[Total Cost]/[Total Units]) AS [ø-Unit Cost], IIf([10 Transactions]![Operation]="Sale",[Total CHF]*-1+[Quantity]*DLast("[ø-Unit Cost]","11 Position tracking","[Date]*1<" & [Date]*1),0) AS [Real P/L], 0 AS [Unreal P/L], IIf([10 Transactions]![Operation]="Dividend",[Total CHF]*-1,0) AS Dividend FROM [10 Transactions] ORDER BY [10 Transactions].Date

Wenn in diesem Beispiel noch Formelwiederholungen zum Tragen kommen, dann befürchte ich, den Überblick zu verlieren.

Aus diesem Grund wäre ich sehr interessiert daran zu wissen, wie man in Base bzw. der dazugehörigen SQL-Syntax mit Bezug auf einen Alias weiterrechnen könnte. Möglicherweise geht das irgendwie mit der UPDATE-, INSERT- oder SET-Funktion oder mit einem Umweg über Tabellenansichten (auch View oder Sicht genannt), da man diese auch mit SQL definieren kann.

Mein einfaches Beispiel sähe dann so aus:

1) casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2) as Bruttogehalt

2) Bruttogehalt*Sozialzuschlag as Gehalt

In MS-Access ist das simpel zu realisieren, man gibt einfach in der gleichen Abfrage den Alias ein und schon wird das neue Feld berechnet.

Hast Du eine Idee, wie man das in Base machen könnte?

Danke und Gruss
rso

Hallo rso,

das ließe sich doch evtl. so abprüfen: ...und weiter rechnen kannst Du damit auch
Um nochmal auf Dein vorheriges Beispiel zurückzukommen:
Gruß Barlee

Hallo Barlee

So wie mein Beispiel konstruiert ist, ist Dein Lösungsvorschlag ok. Aber was machst Du, wenn sich 'Bruttolohn' nicht einfach aus einer Summe ergibt, sondern aus einer Bedingung, z.B.:

Bruttolohn=wenn(Tarifgehalt<=100'000;Tarifgehalt+Zulage1;Tarifgehalt+Zulage2)

Dann hast Du je nach dem, ob die Bedingung wahr oder falsch ist, eine andere Formel zur Ermittlung des Bruttolohnes. Genau ein solches Beispiel führt eben dazu, dass es nötig wird auf ein berechnetes Feld referenzieren zu können, weil nicht einfach eine einfache Formel wiederholt werden kann.

Weisst Du hierzu eine Lösung?
Gruss
rso

Hallo rso,

Bruttolohn kann nicht gefunden werden, da es eben keine Spalte in der Tabelle ist, sondern nur ein Alias für eine Berechnung, die mit Spalteninhalten durchgeführt wurde. Er setzt sich zusammen aus Tarifgehalt und Zulage. Möchtest Du dazu nun den Sozialabzug multiplizieren, dann benutze

( "Tarifgehalt" + "Zulage") * "Sozialabzug"

Gruß Barlee

Hallo zusammen

Ja, es ist tatsächlich einfach, berechnete Felder mit einem Alias-Namen zu erstellen.

Was mir indes noch fehlt ist Folgendes: Wenn ich ein berechnetes Feld erzeuge - z.B. mit dem Aliasname 'Bruttolohn' als Summe von "Tarifgehalt" + "Zulage" - und dann mit diesem Feld weiterrechnen möchte - z.B. "Bruttolohn"*Sozialabzug(%) - bekomme ich eine Fehlermeldung 'Die Dateninhalte konnten nicht geladen werden. Spalte nicht gefunden: Umsatz'.

Kann mir hier jemand weiterhelfen, wie man das macht?

Gruss
rso

Hallo zusammen,
so einfach erstellt man also berechnete Felder. Um einen entsprechenden Feldnamen zu bekommen, gibt man ihn im Abfrageentwurf einfach unter "Alias" ein. Fertig!
Grüße, Uli

Hallo Fritz,

ich bin genau wie Du Umsteiger von Access auf Base und probiere gerade verschiedenes aus.

Um ein berechnetes Feld in der Abfrage anzulegen gibst Du in die "Feld"-Zeile der Abfrage die Rechenformel ein, z.B.: "Tarifgehalt" + "Zulage", wenn die Inhalte der beiden Datenfelder "Tarifgehalt" und "Zulage" addiert werden sollen. Übrigens die "..." braucht man nicht einzugeben, die erscheinen automatisch!

Es ist mir allerdings noch nicht gelungen, die Spaltenüberschrift wie bei Access festzulegen - vielleicht geht das mit SQL.

Gruß Günter

Hallo. Ich möchte Base nutzen, um Kalkulationen zu erstellen.
Hierzu müssen einige Datenfelder miteinander mathem. verknüpft werden.
Wie macht man das ? Habe im Forum keine Informationen hierüber gefunden.
Gruß aus Soest