RTC+CC, Datumskomprimierung, warum wird abgeraten ?

Hallo zusammen,

ich erhoffe mir hier mal ein paar Informationen...

Ein Kunde hat 2009R1 am laufen, und möchte eine Postenkomprimierung haben... Dabei geht es gar nicht um Speicherplatz, aber es sind seit 2002 Datensätze vorhanden, und die Konten, Posten etc. sind ihnen zuviel und unübersichtlich.

Rein vom Impuls her bietet sich ja eine Datumskomprimierung an, ist ja auch offiziell von Microsoft intergriert... Aber egal wohin ich schau oder frag (auch intern, und auch hier) ständig hört man nur "mit Vorsicht zu genießen" oder "Finger weg" etc. Wie kommt das ? Warum ist das Zeug offiziell drin wenn es nicht funktioniert ?

Wie würdet ihr eine Vorgehensweise empfehlen, und hat schon jemand Erfahrung damit ? Bietet sich evtl. an, nur einen Teil der Reports zu verwenden ? Gibt es evtl. auch Testroutinen die man durchlaufen kann, um zu verhindern das ein Fehler erst nach Monaten entdeckt wird ?

Mein Kunde besteht darauf, aber ich bin hier doch etwas unsicher und werde garantiert nicht damit durch seine Datenbank fahren ohne mich abzusichern. In welcher Weise komprimiert werden soll ist noch nicht geklärt, aber monatlich bietet sich aus meiner Sicht an (so würde ich das haben wollen, bzw. der Buchhalter in mir)

Wäre dankbar für Informationen und etwas Austausch.

Viele Grüße
Michael

Warum ist das Zeug offiziell drin wenn es nicht funktioniert ?

Das es nicht funktioniert, hat keiner gesagt. Aber ob ich das haben will, was dabei herauskommt ist die andere Frage.

Da in NAV alles auf der Summierung basierend auf Postennr. 1 basiert, ist das mit sehr sehr viel Bedacht einzusetzen.
Besipiel:
Du möchtest die Sachposten komprimieren, und hast mehrere Dimensionen. Vergisst aber bei der Komprimiereung anzugeben, das er die Dimensionen behalten soll. Wenn du jetzt komprimierst, bucht er alle Komprimierungsposten ohne Dimensionen, was wiederum dazu führt, das sämtliche Auswertungen nach Dimensionen danach unwiederbringlich nicht mehr aussagekräftig sind.

Deshalb musst du vor einer Komprimierung sehr sehr genau überlegen, welche Daten erhalten bleiben müssen, und welche nicht. Und danach kann man überlegen, ob eine Komprimierung noch was bringt.

Auf alle Fälle muss man vor der Komprimierung eine komplette Datensicherung fahren, und am besten auch noch testen, ob sie sich wiederherstellen lässt.

Außerdem solltest du vorher zwingend die Komprimierung vorher in einer Testdatenbank ausführlichst testen.

Gruß, Fiddi

Danke für den Hinweis mit den Dimensionen, das ist auf jeden Fall wichtig.... :)

Ich bin mir nicht so schlüssig in Bezug auf die Auswertungsgeschichte... Kunde hat aktuell wieder die Prüfer im Haus, daher geh ich davon aus das bereits mehrere Geschäftsjahre im System sind, die auch schon geprüft wurden, und dadurch eher "uninteressant"...

Falls die Komprimierung keine "technischen" Probleme verursachen kann (wobei das schwer zu sagen ist, das System ist stark angepaßt) wäre das ja dann gar nicht so schlimm... Ich würde ohnehin soweit gehen und sagen : Heb dir eine Datensicherung auf, oder mach eine zweite DB mit den alten Daten FALLS ihr was auswerten wollt". Und dann wären die alten Jahre eher egal aus meiner.

Das mit dem Testen ist natürlich so eine Sache, da hab ich eben die Befürchtung was zu übersehen was unter Umständen erst viel später auffällt, und dann wirds lustig. Ich mach mir mehr Sorgen um irgendwelche Fehler in Programmcodes, die mit dem komprimierten Posten nicht klarkommen, oder womoöglich Posten die benötigt werden dadurch ganz fehlen....

Irgendwelche Erfahrungswerte in dieser Richtung ?

Das mit dem Testen ist natürlich so eine Sache, da hab ich eben die Befürchtung was zu übersehen was unter Umständen erst viel später auffällt, und dann wirds lustig. Ich mach mir mehr Sorgen um irgendwelche Fehler in Programmcodes, die mit dem komprimierten Posten nicht klarkommen, oder womoöglich Posten die benötigt werden dadurch ganz fehlen....

Genau das ist das Problem.

Und denk daran, auch alte Jahre werden in die Berechnung aktueller Werte einbezogen.

Gruß, Fiddi