| |
 Anzeigen |
|
|
| Social Bookmark Script |
|
|
|
  |
 Felder dynamisch berechnen |
Remo
Jungspund
Dabei seit: 25.09.2007
Beiträge: 11
 |
|
| Felder dynamisch berechnen |
     |
Hallo VDF Freunde,
ich arbeite erst seit Kurzem mit VDF, habe aber ein paar Erfahrungen mit Datenbanken & Softwareentwicklung und stosse daher auf einige Unterschiede gegenüber anderen System die ich kenne (Oracle, SSAS, Centura, .NET usw.).
Dieses Forum hat ja noch ziemlich wenig Beiträge, da dachte ich, ich poste die Frage nicht in der Newsgroup sondern hier 
Ich hab mir das Order Entry Beispiel etwas genauer angeschaut und gesehen, das die Spalte "Total" in der Auftragsposition über die Update Routine berechnet wird. Dies ist für mich etwas ungewöhnlich da wir inzwischen mehr als genügend Leistung um bei der Anzeige kurz 23*34 zu rechnen so dass wir keine "quasi Redundanzen" speichern müssen.
Ich sehe fast nichts das ich mit dieser Funktionsweise von VDF nicht lösen könnte, es ist aber etwas problematisch wenn man eine bestehende Applikation hat die man portieren möchte. Ein Kandidat den ich ev. portieren könnte hat doch ein paar Dutzend Felder die berechnet werden, dies umzuschreiben ist ein ziemlich grossen Aufwand (sind nicht nur Multiplikationen sondern auch decode, translate,... anweisungen)
Besten Dank & Gruss
Remo Laubacher
|
|
25.09.2007 22:07 |
|
|
Matthias 
Super Moderator
Dabei seit: 09.07.2007
Beiträge: 233
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Niedernhausen
Betriebssystem: XP, Vista, Win7, 2008 Ser
|
|
| RE: Felder dynamisch berechnen |
|
Hallo Remo,
das ist die (seit Jahren) bewährte Vorgehensweise für die embedded DataFlex Datenbank, um möglichst schnell Ergebnisse ausweisen zu können. Bei einem neuen Projekt sicherlich auch keine Problem, ein Feld Total mitzuführen. Natürlich besteht auch hier die Möglichkeit, die Daten permanent online zu berechnen, erfordert aber bei DataFlex entsprechende Datenbankzugriffe, die zwar sehr schnell sind, aber eben auch programmiert sein müssen.
Bei Nutzung einer SQL-Datenbank eröffnen sich natürlich die Möglichkeiten, die SQL bietet. Die gängigsten Datenbanktreiber für SQL Datenbanken sind in einer VDF Entwicklungslizenz bereits mit enthalten. Weitere findet man unter www.mertechdata.com.
Matthias
|
|
|
26.09.2007 10:14 |
|
|
Remo
Jungspund
Dabei seit: 25.09.2007
Beiträge: 11
Themenstarter 
|
|
Vielen Dank für die prompte Antwort!
Ich seh schon ein das es Vorteile dieser Methode gibt aber wenn ich eine Buchhaltungssoftware entwickeln möchte und gleich bei jeder Buchung den Saldo des Monats- und Jahresabschlusses, der Mittelflussrechnung, der Deckungsbeiträge usw. ausrechnen muss, so wird dies etwas unschön enden..
Wenn ich das richtig Verstehe: Eine weitere Unschönheit wäre die Trennung der Applikationen: Wenn Person A die FIBU Funktionalität implementiert hat und Person B die Mittelflussrechnung aufbereiten müsste, so muss Person B in die Applikation von Person A eingreifen. Je nach Arbeitsweise etwas unpraktisch..
Werde mich aber wohl dem Thema externe SQL DB & VDFQuery annehmen um da einen besseren Durchblick zu erlangen!
Danke für die Unterstützung!
Remo
|
|
|
26.09.2007 23:01 |
|
|
Roman Köhler
Administrator
Dabei seit: 29.08.2007
Beiträge: 202
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Mannheim
Betriebssystem: Windows XP
|
|
Hallo Remo,
wir haben seit Jahren eine eigene Buchhaltungssoftware im Einsatz. Das Einzige, was beim Speichern des Buchungssatzes verändert wird ist der Saldo des Kontos.
Falls man andere Berechnungen starten will (Bilanz...), sind diese Berechnungen in eigene Programme gepackt, die dann die von Ihnen benötigten Daten ermitteln und evtl. in Summenfeldern zwischenspeichern. Dies bietet einerseits Vorteile in der Übersichtlichkeit des Buchungsvorgangs, und man ist deutlich flexibler in der Gestaltung der Auswertungsprogramme.
Du schlägst vor, dass gewisse Berechnungsfelder bereits im DD während der Buchung ermittelt werden sollen. Irgendwann ergibt sich dann aber eine Anforderung, die diese bereits berechneten Felder nicht braucht. Bsp.: Du lässt den Monatssaldo des aktuellen Jahres eines Kontos mitprotokollieren. Irgend wann kommt dann die Anforderung einen Monatssaldo des vergangenen Jahres auszuweisen. Spätestens dann musst Du eh wieder eine Auswertung programmieren. Also warum nicht gleich so?
LG
Roman
|
|
|
27.09.2007 08:41 |
|
|
Remo
Jungspund
Dabei seit: 25.09.2007
Beiträge: 11
Themenstarter
|
|
Hallo Roman,
nein ich schlage nicht vor die Daten beim Insert zu berechnen, mir ist nur aufgefallen das die VDF Beispielapplikationen dies tun..
Ich hab in den letzten Jahren einige hundert Tabellen in Oracle angelegt und daher bin ich doch etwas vorbelastet was SQL angeht und deswegen fühle ich mich in VDF etwas verloren, hab allerdings VDFQuery noch nicht im Detail angeschaut!
Das mit der Buchhaltung war nur ein theoretisches Beispiel, deswegen auch etwas übertrieben. Ich hab von der Ausbildung her einen umfangreichen Background in diesem Gebiet, hab aber definitiv nicht vor eine Anwendung dafür zu erstellen...
Ich muss mir den Punkt "eine Auswertung programmieren" etwas genauer anschauen.. Mir fehlt da wohl die Erfahrung mit VDF noch etwas!
Gruss
Remo
|
|
|
28.09.2007 22:59 |
|
|
Peter Bosch
Mitglied
Dabei seit: 04.09.2007
Beiträge: 30
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Wien
|
|
Hallo Remo!
Du kannst natürlich bei jedem Feld zur Anzeige eine Funktion verwenden:
Entry_Item (Func(Parm1,Parm2,...,Parmx))
statt direkt einem Datenbankfeld - in der Funktion kannst du berechnen, was du willst. Natürlich kann das aufwändig werden, wenn du viele Datensätze lesen musst, aber generell funktioniert es.
LG
Peter
|
|
|
10.10.2007 09:23 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
| RE: Felder dynamisch berechnen |
|
Hallo Remo
Es ist in der tat unschön, dass man dazu angehalten wir die Berechnungen in die Update Methode zu verbannen. Wir haben uns schon lange daran gestört.
Den End-Kunden klar zumachen, dass sie F2 drücken müssen um das Ergebnis der Berechnung (Bsp Anzahl Artikel*Preis pro Artikel) zu sehen, war nie einfach.
Man kann Berechnungen via DD-Buffer machen, die sich ja sofort auf die Anzeige auswirken. Das Problem ist dann aber, dass man die Berechnungen nicht 2x definieren will (im UDPATE und dann eben mittels DD Notation). Man vergisst garantiert die eine Anzupassen, wenn was ändern würde.
Wir definieren Berechnungen innerhalb derselben Table (also keine Totale 'nach oben' zu dem Parents) mit der DD Notation, get_file_field_current_value / set_file_field_Changed_Value in einer Methode DoCalcAll.
Die DoCalcAll Methode rufen wir einerseits beim field_exit_msg der gewünschten Felder auf (kann ebenfalls im DD pro Feld festgelegt werden) und andererseits als Teil von request_validate.
Das führt dazu, dass die Berechnungen sofort ausgeführt werden und nach dem verlassen des Feldes sichtbar sind. Auf eine Umsetzung (eigentlich eine Nachberechnung) in Update haben wir konsequent verzichtet.
Diese Vorgehensweise garantiert auch, dass alles im DD hinterlegt ist - was ja auch zu empfehlen ist.
Das automatische Nachführen von Totalen (also von parents) war eigentlich nie ein Thema; es war immer möglich den Kunden klar zu machen, dass erst nachdem die Eingaben durch speichern bestätigt wurden, das Total nachgeführt wird.
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
24.10.2007 17:14 |
|
|
|
|
|
|
|
