sportingt
15th March 2008, 11:11
Hallo,
ich möchte die Historiendaten der Verkaufsstatistik korrigieren.
Wir setzten Baan IV mit Informix 7 ein. Für ein Update möchte ich direkt ein SQL-Statement verwenden.
Im ersten Schritt habe ich das Feld t_creg (Region) in den Kunden-Stammdaten aktualisiert.
Nun möchte ich auf dieser Basis die Historie korrigieren. dazu setzte ich ein Vergleichbares Statement ein.
update history_data
set t_creg = '01'
where customerno in (select customerno from customers where t_creg = '01');
Ich habe auf diese Weise, alle Lieferpositionen korrigiert. Dies hat aber scheinbar keinen Einfluß auf die in der Statistik/Historie verwendeten Daten.
Kennt jemand die Namen der betroffenen Tabellen?
Gibt es nnoch weitere Schritte die ich beachten muss?
Bitte um Hilfe!!!
mfg
sportingt
hklett
17th March 2008, 20:05
Hallo,
eigentlich sollte es reichen, wenn die Region im Kundenstamm geändert worden ist, eine komplette VK-Statistikaktualisierung( tdsst0201m000 )
mit dem Schalter "Aktuelle Kundendaten" auf "Ja" laufen zu lassen.
Ansonsten wird die Region in der Auftragskopftabelle( tdsls040 ) und Auftragskopfhistorietabelle ( tdsls050 ) weggeschrieben.
Die Änderung in der tdsls050 wird in der Statistik aber auch erst nach einer vollständigen Aktualisierung sichtbar.
Gruß
Holger
Martin Jung
17th March 2008, 22:08
..Für ein Update möchte ich direkt ein SQL-Statement verwenden.... das ist keine wirklich gute Idee :eek:
Hallo sportingt,
mag der Update des Feldes Region in den Kundenstammdaten noch halbwegs unkritisch sein, so verbietet sich ein Aktualisieren von Bewegungsdaten per DB-Skript ohne genaue Kenntnis der Tabellenstrukturen, geschweige denn der Programmlogik welche die Tablellen verändert, quasi von selbst. Wie hklett schon richtig bemerkt hat: genau zu diesem Zweck gibt es die vollständige Aktualisierung der Statistik auf Basis der (neuen) Kunden- oder sonstiger Stammdaten - im Baan Standard!
Die normale Aktualisierung der Statistik beruht auf Daten in den VK- oder EK-Historietabellen. Hier wird ein Flag mitgeführt, welches die Aktualisierung triggert (Historiestatus oder so ähnlich). Den Update der eigentlichen Statistiktabellen würde ich niemals per Skript wagen.
Nix für ungut,
Martin
csecgn
18th March 2008, 01:25
Hallo,
es ist zwar spät Abends, ich habe kein Baan System zum Nachsehen zur Hand und wir nutzen die Statistik nicht da sie für uns ungeeignet war (wir haben ein Datawarehouse mit BO).
Wenn ich ich mein Wissen über die VK Statistik zusammensuche würde ich auch sagen es ist keine so gute Idee. Vor allem dann nicht wenn Du Dich anscheinend wenig in den Baan Tabellen auskennst (das soll keine Beleidigung sein. Es ist nur mein Eindruck.).
Aber egal: Die Statistiken sind Verdichtungen der historischen Bewegungsdaten. Der Schlüssel ist ein Stringfeld dessen Zusammensetzung von den Historie-Parametern abhängt. Du müsstest also in diesem Feld abhängig von den Parametern in verschiedenen Tabellen einen Teilstring durch einen anderen ersetzen.
Ohne genaue Kenntnis des Aufbaus der Tabellen und wie sie gefüllt werden ist es auch meiner Meinung nach keine gute Idee bzw. nicht möglich.
hth
Gruss
Christof
sportingt
18th March 2008, 09:17
Hallo,
danke, das sind doch schon einmal brauchbare Kommentare.
Hätte ja nicht gedacht, dass eine Statistik so schwer sein kann ;-)
Werde die Finger davon lassen. Werde immer wieder überrascht, wie ein System, das auf einer SQL-Datenbank basiert, nicht mit den Rohdaten auskommt!?
Habe leider durch eure Tips jetzt ein neues Problem. Habe die Statisik vollständig aktualisiert (tdsst0201m000). Also mit Baan-Bordmitteln. Jetzt habe ich einige Zahlen für die letzten Jahre verloren :-((((
Statistik ist scheinbar jetzt unbrauchbar!!!!
Haben vorher immer nur mit der Option vollständig = nein aktualisiert.
Das ist jetzt richtig sch...
Das war eigentlich der Grund, warum ich sowas auf dem "kleinen Dienstweg" erledigen wollte.
Haben schon einmal mit sowas in die sch... gegriffen!!!!
Warum kann man sich bei solchen Funktionen nicht auf Baan verlassen?
Ist doch nen Standardprogramm!!! Müsste also doch funktionieren!
Martin Jung
18th March 2008, 09:59
Hätte ja nicht gedacht, dass eine Statistik so schwer sein kann .. Werde immer wieder überrascht, wie ein System, das auf einer SQL-Datenbank basiert, nicht mit den Rohdaten auskommt!?..
Hallo sportingt,
Du musst bedenken, dass das Konzept der Baan Statistik aus einer Zeit stammt als leistungsfähige Reportingtools noch eine Seltenheit waren, das gleiche gilt für die damaligen DB-Systeme. Das Ur-Baan lief ja noch auf einer propritären DB names TBase.
Viele BaanIV Kunden wenden sich tatsächlich von der Standard VK-Statistik ab und betreiben flexiblere und leistungsfähigere Lösungen.
"Rohdaten" in eine Tabelle zu pumpen und zu hoffen, das (auch moderne!) ERP-Systeme damit zu recht kommen ist ein gewaltiger Trugschluss. Die Abhängigkeiten der Daten untereinander ist komplex und die Systeme reagieren in der Regel sehr allergisch darauf, wenn man versucht ihnen "falsche Tatssachen" vorzugaukeln.
Noch ein Tipp bezüglich der zerschossenen VK-Statistik: mir scheint Du hast kein Testsystem zum Ausprobieren solcher Aktionen. Das ist keine gute Strategie! Ohne so ein System wirst Du mittelfristig kaum überleben.
Gruss
Martin
csecgn
18th March 2008, 13:55
Ich hoffe für euch iht habt eine Datensicherung. Dann könntet ihr es flicken.
In vielen Firmen werden die Historientabellen archiviert. Dann ist bei einem vollständigen Wiederaufbau der Statistik die Datenbasis nicht mehr da. Ergo wird auch nichts mehr aufgebaut.
Werde immer wieder überrascht, wie ein System, das auf einer SQL-Datenbank basiert, nicht mit den Rohdaten auskommt!?
Alles eine Frage der gewünschten Performance ;-).
Unser Datawarehouse läuft auf einer Oracle Datenbank. Es kommt mit den Rohdaten auch nicht zurecht. Wir haben >> 60 Millionen Sätze in der VK Historie... . Ich traue mich nicht mehr sie zählen zu lassen. Dauert zu lange.
Gruß
Christof
sportingt
18th March 2008, 15:42
Hallo,
Das das Baan-reporting nicht berauschend ist weiß ich ja selbst. Für komplexere Sachen setzte ich auch externe Tools ein. Aber für einige basislisten ist es doch sehr nützlich.
Es ging mir ja nicht um ne große Sache nur ne Korrektur bestehender und funktionierneder Auswertungen.
Auch die komplexen Zusammenhänge innerhalb eines ERP-Systems sind mir bewußt.
Entscheidend ist komischerweise, dass wenn, ich bisher per SQL eingegriffen habe, weniger Fehler passiert sind, als wenn ich irgendwelche Standardprogramme gestartet habe :-(
Aber trotzdem danke für die Ratschläge. werde ich demnächst berücksichtigen.
Naja, die letzten sechs Monate von Baan brechen an, wenigsten ein Lichtblick.
sportingt
22nd March 2008, 10:47
So,
alles wieder da!!!
Lag daran, dass das Programm tdsst0201m000 nicht sauber durchgelaufen war.
(dbs_errno 1458). Da die Transaktion zu lang war, reichten die Logical Logs der Informixdatenbank nicht aus.
Ich habe die chunks des db-space baandb_llog gewaltig vergrößert und neue logische Logs dazugefügt.
Die Aktualisierung auf Basis der neuen Stammdaten ist damit natürlich auch wirksam geworden.
Übrigens, ein Kommentar kann ich mir dann doch nicht verkneifen:
Man kann unter Verwendung geschickten PL/SQL-scriptings auch sehr große Datenmengen performant händeln. Die meisten vergessen nur Methoden wie Sequenzen und Checkpoints gekoppelt mit geschickten where-Klauseln, bzw. Views.
Dazu kommt natürlich das richtige Datenbank- Instanztuning, was Indizes, Speicherverwaltung und Transaktionsprotokolle angeht.
Bei meinem alten Arbeitgeber hatten wir auch ne Oracle 9i-Datenbank unter Linux und ich muss sagen dass ich bei >60Mio Zeilen pro Tabelle keine Angst hatte zu zählen oder ne View zu erzeugen.
Ausserdem würde man ja mit Externen Tools, wie Crystal oder so auch nichts anderes machen.
so long...
sportingt
csecgn
23rd March 2008, 21:00
Übrigens, ein Kommentar kann ich mir dann doch nicht verkneifen:
Man kann unter Verwendung geschickten PL/SQL-scriptings auch sehr große Datenmengen performant händeln. Die meisten vergessen nur Methoden wie Sequenzen und Checkpoints gekoppelt mit geschickten where-Klauseln, bzw. Views.
Dazu kommt natürlich das richtige Datenbank- Instanztuning, was Indizes, Speicherverwaltung und Transaktionsprotokolle angeht.
Bei meinem alten Arbeitgeber hatten wir auch ne Oracle 9i-Datenbank unter Linux und ich muss sagen dass ich bei >60Mio Zeilen pro Tabelle keine Angst hatte zu zählen oder ne View zu erzeugen.
Ausserdem würde man ja mit Externen Tools, wie Crystal oder so auch nichts anderes machen.
Gut zu hören das die Daten wider da sind. Die Ursache ist ein Klassiker :D. Passiert uns auch ab und zu... . Dann schimpft unser DBA was wir wieder gemacht haben.
Nur das Zählen dauert in Baan ewig. Die Performance der Tabellen ist kein Problem. Wenn nicht jemand die Bewegungsdaten der letzten 3 Jahre für alle Kunden abfragt bekommt er auch eine schnelle Antwort.
Baan ist durch seinen Zwischenlayer extrem flexibel was die DB angeht. Der Nachteil ist, man kann nicht allles benutzen was die DB kann. Dafür kannst Du aber im Notfall (?) das halbe System auf Oracle laufen lassen, einen Teil auf Informix oder DB2 und den Rest auf SQL Server. Habs noch nicht probiert sollte aber gehen.
Zweiter Vorteil: Die Objects laufen ohne Änderung unter jedem OS auf jeder DB.
Gruß
Christof