Technischer Update auf 2009 R2

Wir haben einen Kunden, der derzeit mit Navision 2.60, technisch 3.70 arbeitet und bei dem ein Update auf 2009 R2 ansteht. Wegen der Größe der Datenbank und der komplexen Software dauert der Update sehr lange, so dass das Ganze in mehreren Schritten gemacht werden soll. Außerdem soll die alte Datenbank zum Nachschlagen erhalten bleiben.

Ich habe nun im ersten Schritt einen technischen Update von 3.70/2.60 auf 2009R2/2.60 vorgesehen, beides mit der nativen Datenbank. Im zweiten Schritt wird dann der Update auf 2009R2 CC in dieser Datenbank durchgeführt werden.

Nun gibt es für mich zwei Fragen:
1. Gibt es Bedenken gegen das technische Update? Bei mir lokal funktioniert es auf jeden Fall einwandfrei.
2. Was gibt es zu beachten, wenn ich die 2009 neben die 3.70 installiere? Laufe ich Gefahr, dass die 3.70 Clients gelöscht werden?

Gruß Rainer

1. Gibt es Bedenken gegen das technische Update?

Ja - Microsoft wird dich nicht unterstützen, falls es doch Probleme geben sollte.
Microsoft sagt, dass wenn du von einer Version < 2009 SP1 kommst (ist der Fall), dann musst du ein komplettes Update (also inkl. Objektupdate) durchführen. Für die Zeit vom technischen bis zum Objektupdate stündest du damit quasi alleine da.

Was gibt es zu beachten, wenn ich die 2009 neben die 3.70 installiere? Laufe ich Gefahr, dass die 3.70 Clients gelöscht werden?

Eigentlich sollte das kein Problem sein, da NAV 2009 andere Installationspfade benutzt. Dennoch ist es immer ratsam, sich das alte Clientverzeichnis an eine andere Stelle zu kopieren. Von dort kann es genauso gut benutzt werden.

Nun gibt es für mich zwei Fragen:
1. Gibt es Bedenken gegen das technische Update? Bei mir lokal funktioniert es auf jeden Fall einwandfrei.

Was nun aber genau garnix heist. Hast Du mit mehreren Benutzern in der DB Lasttest gemacht? Hast Du sämtliche Geschäftsvorfälle mit sämtlichen Besonderheiten durchgespielt etc.pp.

Wie unsere Nati schon sagte: wegen der Änderung der Architektur -> nur Komplettupdate oder halt die andere Alternative: Navision neu aufsetzen und nur das wirklich noch benötigte nachprogrammieren. Bei der Gelegenheit bietet sich dann auch die SQL-Migration an (Stichwort: DB-Grösse).

j. 2ct

Selbstverständlich wird es den Objekt-Update geben, und auch der SQL-Upgrade ist schon getestet. Ziel ist, in einem ersten Schritt die Vorbereitungen zu machen, d.h. Datenbank aufräumen, neue Clients installieren und dann eben auch schon einmal die Datenbank technisch auf 2009 zu bringen und auch schon entsprechend für den Objekt-Update zu erweitern. Geplant ist dann im zweiten Schritt, ca. 10 Tage später der echte Objekt-Update, und dann, eine weitere Woche später die SQL-Migration. Das Problem ist hier nicht die Performance, aber die Datenbankgröße von ca. 60 GB, die die Aufteilung in mehrere Schritte nötig macht.

Einige Probleme gibt es u.U. bei deinem technischen Update:
Wenn du den NAV2009-Client mit dem aktuellsten Patchlevel einsetzen möchtest, dann teste bitte vorher an Cronus, ob der neue Client auch mit dem Native- Server von der CD läuft. Der Native- Server ist schon seit der Veröffentlichung von R2 nicht mehr aktualisiert worden (ist anscheinend noch niemandem bei MS aufgefallen oder Absicht ). Bei meinem Test bin ich ziemlich auf die Nase gefallen: Der Client bricht dann mit der Fehlermeldung ab, das Client- und Server- Version nicht zusammen passen. Wenn du vorher schon eine DB-Konvertierung mit dem neuen Client ohne Server gemacht hast, dann hast du die A-Karte gezogen.
Daher wirst du wohl zuerst den SQL-Update machen müssen, und danach die restliche Umstellung.

weitere Gemeinheiten hier: viewtopic.php?f=40&t=16792

Gruß, Fiddi

Vielen Dank für die Informationen! Ich werde das Ganze dann wohl doch in einer anderen Reihenfolge machen, indem ich erst am Anfang des 2. Schrittes die dann saubere 3.70-Datenbank mit der 2009-Version lokal öffne und damit dann gleich den Objekt-Update mache. Der SQL-Upgrade wird dann aber trotzdem erst eine Woche später stattfinden.

Wenn du mit der 3.70er- Native das Objekt-Update machst, und das mit nem 2009er-Client lokal, ist die Datenbank mit dem Native-Server (zumindest bei aktuellem Patchlevel) nicht mehr zu benutzen.

Gruß, Fiddi

Sorry, jetzt muss ich noch mal ganz blöd fragen:

Ich mache folgendes: Ich nehme die 2.60-Datenbank, die bisher technisch unter 3.70 gelaufen ist und offne die lökal mit einem 2009R2-Client. Dann mache ich mit den Upgrade-Toolkits zunächst ein Upgrade auf 4 SP3 und schließlich, wieder mit UTK auf 2009R2. Diese Datenbank öffne ich mit dem 2009R2 Server (nativ) und greife mit dem 2009R2 Client darauf zu. Das funktioniert nicht mehr? Dann dürfte doch eigentlich auch eine 2009R2-Cronus-Datenbank nativ nicht mehr funktionieren, wenn sie unter dem Server läuft. Habe ich das richtig verstanden und was ist die Alternative? Soll ich das Ganze mit dem 2009SP1 machen?

Ich hatte genau das Problem mit mit einem aktuellen Build des Clients und dem Native-Server von 2009 R2 (der wird, wie schon gesagt, nicht mehr mit den MS-Patches aktualisiert). Wenn du nur den Client und den Server von der R2-CD verwendest, dann könnte das funktionieren, aber ich würde das testen.
Du hast also die Möglichkeit, das Update mit dem Client von der R2-CD zu machen, damit zu arbeiten, solange die Native-DB läuft, und erst dann den aktuellsten Client zu benutzen, wenn du auf SQL umsteigst. Dabei wiederum musst du das Problem mit Feld 27 in Objectmetadata beachten. Es kann aber sein, das du dieses Problem nicht hast, wenn sich die Clientversion der Datensicherung und die Clientversion der einspielenden Version unterscheiden. Oder du machst die Umstellung auf SQL auch mit der alten Version, und führst später die Schritte aus, um auf den aktuellen Patchlevel zu kommen.

Gruß, Fiddi

Ok, ich nehme einfach mal die CD-Version und teste das.

Mal eine ganz andere Frage in diesem Zusammenhang: Der Kunde hat von mir eine 2009-Testversion mit SQL. Fehler, die hier noch passieren, werden entsprechend korrigiert. Für den finalen Update werden die Objekte dann ausgespielt. Der Updateprozess läuft aber zunächst über die native Datenbank. Wenn ich dort die geänderten Objekte einlese, bleibt dann eigentlich ein für ein Feld geänderter SQL Data Type erhalten oder muss ich den nach dem SQL-Upgrade wieder neu setzen?

Also SQL-Objekte --> fob --> Einlesen in native Datenbank --> Upgrade auf SQL.

Wenn ich dort die geänderten Objekte einlese, bleibt dann eigentlich ein für ein Feld geänderter SQL Data Type erhalten oder muss ich den nach dem SQL-Upgrade wieder neu setzen?

Wenn du den SQL- Datentyp im Object-Designer gesetzt hast, dann sollte das erhalten bleiben.

By the way: machst du auch ein Update der Artikelposten aus 2.6. Falls ja, viel Spaß bei den Lagerwerten

Gruß, Fiddi

By the way: machst du auch ein Update der Artikelposten aus 2.6. Falls ja, viel Spaß bei den Lagerwerten

Damit kann ich umgehen. Schlimmer ist, dass die Posten so an die 50 Zusatzfelder haben, die dann auf Artikel- und Wertposten verteilt werden müssen, und das bei über 3 Mio. Datensätzen (nach Komprimierung).

Client + Server nativ funktioniert übrigens mit der CD-Version. Das sollte für die Übergangszeit genügen.

By the way: machst du auch ein Update der Artikelposten aus 2.6. Falls ja, viel Spaß bei den Lagerwerten

Damit kann ich umgehen. Schlimmer ist, dass die Posten so an die 50 Zusatzfelder haben, die dann auf Artikel- und Wertposten verteilt werden müssen, und das bei über 3 Mio. Datensätzen (nach Komprimierung).

Client + Server nativ funktioniert übrigens mit der CD-Version. Das sollte für die Übergangszeit genügen.

Hallo Rainer,

also wenn man die Möglichkeit hat sollte man den Kunden davon überzeugen das die Artikelposten nicht mitgenommen werden bei Update und nach Update eben eine Inventurbuchung durchzuführen mit der schönsten und besten Lagerbewertung. Ist nicht nur für die Update sondern auch spätere Performance extrem hilfreich. Da die alte Datenbank ja noch als Archivsystem vorhanden ist kann der Kunde ja dort die ganze Historie nachvollziehen.

also wenn man die Möglichkeit hat sollte man den Kunden davon überzeugen das die Artikelposten nicht mitgenommen werden bei Update und nach Update eben eine Inventurbuchung durchzuführen mit der schönsten und besten Lagerbewertung. Ist nicht nur für die Update sondern auch spätere Performance extrem hilfreich. Da die alte Datenbank ja noch als Archivsystem vorhanden ist kann der Kunde ja dort die ganze Historie nachvollziehen.

Da stimme ich dir zu.
Ich befürchte nur, das in den 50 Feldern in den 2.6er Artikelposten nicht nur heiße Luft steht, und damit Auswertungen gemacht werden sollen. Wenn jemand mit Service und Artikelverfolgung arbeitet, dann gibt das auch noch andere Probleme. Um das Problem zu beseitigen hilft es eigentlich nur, die kompletten Ausgleiche der Artikelposten nach dem Ausgleich aufzuheben, und danach einen neuen Ausgleich zu fahren, danach ist das Problem i.d.R. weg (Dafür stimmen dann die Lagerwerte pro altem Jahr nicht mehr, aber die weichen nach dem Update sowieso ab.)

Gruß, Fiddi

Eigentlich ist alles noch viel schlimmer. Der Kunde hat einen Einzelhandel (ich möchte aus Diskretionsgründen nicht näher darauf eingehen), und jeder einzelne verkaufte Artikel ist ein Artikelposten. Dazu gibt es noch zig FlowFields in allen möglichen Tabellen, die diese Artikelposten auswerten. Nach der Umstellung auf Artikel- und Wertposten mussten alle FlowFields neu definiert werden, teilweise gab es keine neuen Entsprechungen mehr. Wir haben uns schon von den Artikelposten vor 2009 getrennt, sonst wären wir bei über 6 Mio., aber die jetzt noch vorhandenen Jahre müssen auswertbar bleiben.

Ich möchte einfach nur dazu sagen, dass wir das Ganze nicht programmiert haben, der Kunde ist aber zu uns gewechselt und braucht den Update jetzt. Das was unsere Vorgänger da gemacht haben ist völlig für'n A..., wir baden es nur aus. Zur Ehrenrettung sei gesagt, dass die es heute höchstwahrscheinlich auch anders machen würden. Sorry, wenn ich nicht näher darauf eingehen kann.

Eigentlich ist alles noch viel schlimmer. Der Kunde hat einen Einzelhandel (ich möchte aus Diskretionsgründen nicht näher darauf eingehen), und jeder einzelne verkaufte Artikel ist ein Artikelposten. Dazu gibt es noch zig FlowFields in allen möglichen Tabellen, die diese Artikelposten auswerten. Nach der Umstellung auf Artikel- und Wertposten mussten alle FlowFields neu definiert werden, teilweise gab es keine neuen Entsprechungen mehr. Wir haben uns schon von den Artikelposten vor 2009 getrennt, sonst wären wir bei über 6 Mio., aber die jetzt noch vorhandenen Jahre müssen auswertbar bleiben.

Ich möchte einfach nur dazu sagen, dass wir das Ganze nicht programmiert haben, der Kunde ist aber zu uns gewechselt und braucht den Update jetzt. Das was unsere Vorgänger da gemacht haben ist völlig für'n A..., wir baden es nur aus. Zur Ehrenrettung sei gesagt, dass die es heute höchstwahrscheinlich auch anders machen würden. Sorry, wenn ich nicht näher darauf eingehen kann.

Hallo Rainer,

mal interessehalber ne Frage:

Wie habt ihr denn da die Abgrenzung bei den Artikelposten gemacht? Mit einfach Artikelposten < 2009 löschen ist es ja oft nicht getan, da ja dann je nach Postenprinzip die vorherigen Posten bei der Errechnung fehlen würden und dann z.B. am 01.01.2009 ein negativer Lagerbestand stehen würde. Oder hattet ihr da das Glück das zum 01.01.2009 alle Artikelbeständer sauber auf null waren und an dem Tag alle inventurmäßig neu eingebucht wurden? Dann würde das gehen.

Das Partner auch Mist programmieren ist ja nicht wirklich überraschend . Da gibt eben auch verschiedene Erfahrungs- und Wissensstände.

Einzelhandel ist immer schön , aber wenn man erst mal herausgefunden hat, wie es geht, funktionierte es auch in 2.6.

Da haben viele so ihre lieben Probleme mit (Brutto in 2.6 war wirklich schön ). Aber Artikelposten muss schon sein, wie will ich sonst herausfinden wo wann meine Ware geblieben ist. Ob man jetzt noch Rechnungen macht, ist dann Geschmackssache (machen wir z.B.). Deshalb schocken mich deine Artikelposten auch nicht, ich hatte schon mit mehr als 10Mio zu tun. Der Spaß kam erst nach dem Update.

Ich hoffe dein Kunde setzt nicht die Impuls- Lagerregulierung in 2.6 ein. Damit funktioniert das normale Upgrade Toolkit nicht, bzw. es zerlegt die Posten komplett (ist dass evtl. die Quelle der vielen Felder?).
Soviel ich weiß, gibt es dafür auch kein UGT.
Wir haben allerdings einen Weg gefunden es trotzdem upzudaten, aber halt mit Nachwehen. Bei denen bin ich mir allerdings nicht sicher, ob das durch unsere Anpassung verursacht wurde, weil das Lagerwertproblem auch bei Upgrades ohne Impuls auftritt.

Wenn ihr die in 2.6 enthaltene Postenkomprimierung verwendet habt, könnte das euren Ärger noch vergrößern, weil die so ihre liebe Not damit hatte Werte korrekt zu saldieren. Wenn man dann auch noch eine Option vergessen hat (z.B. Nach Lagerort, wenn man mehrere Lagerorte hat), dann sind die Posten nur noch Schrott wert.

Gruß, Fiddi

Wie habt ihr denn da die Abgrenzung bei den Artikelposten gemacht?

Man kann es in etwa so zusammenfassen: Die Artikelposten der Artikel, die nach dem Stichtag keine Bewegung mehr hatten wurden einfach gelöscht, aber nur dann, wenn der Artikel keinen Bestand mehr hat und wenn er nicht mehr in EK- oder VK-Zeilen vorkommt. Die dazu gehörigen Artikel wurden gleich mitgelöscht, es sei denn, es sind neue Artikel die NOCH keinen Bestand haben. Das funktioniert in diesem Fall deswegen so gut, weil Artikel, die abverkauft sind in der Regel nicht wieder neu beschafft werden.

Gru0 Rainer

Das funktioniert in diesem Fall deswegen so gut, weil Artikel, die abverkauft sind in der Regel nicht wieder neu beschafft werden.

Dann hoffen wir mal, das keiner bei der Inventur noch welche findet

Gruß, Fiddi

Was ich bislang nicht erwähnt habe ist, dass die Artikelverkäufe über die Kassen hereinkommen und dann verbucht werden. Die vielen Felder kommen aufgrund der verschiedenen "Ausprägungen" der Artikel zustande, d.h. Größe, Farbe usw. Meine Idee war ja, diese in Dimensionen zu packen, aber leider wurde ich da nicht erhört.

Da ich soeben erfahren habe, dass noch viele neue Auswertungen dazukommen sollen, denken wir nun alternativ auch über ein BI-Tool nach. Leider bin ich da noch relativ unbedarft, was es da aktuell - und künftig - bei, für oder mit NAV geben wird. Da sind sämtliche Informationen höchst willkommen.

Zum BI schau mal hier

Ein Artikel kann aber doch nur eine Farbe haben, oder haben die das ganze als Varianten missbraucht?

Dimensionen sind zwar machbar, aber bei der Datenmenge nicht wirklich handlebar. Du hast dann bei 6 Mio. Artikelposten mit je 3 Ausprägungen 18 Mio. Dimensionswertposten, das macht das ganze nicht einfacher

Gruß, Fiddi

Nur damit ich nicht ganz blöd sterb. Dimensionen wären jetzt also Größe, Farbe, Saison und Varianten wäre die Kombination daraus?

Was mir auch nicht so ganz klar ist, die Kasse hat doch eigentlich nur eine Artikel-Nr oder Barcode. Warum versucht man dann von der Kasse die Daten aufgedröselt zu übergeben statt nur der einen Nummer? Um das aufdröseln der Nummer kann sich doch dann NAV kümmern. Oder haben die einen NAV-Client als Kasse? Ich kann ja auch Warenauszeichnungen, da setzt sich der Barcode aus Saison, Artikel, Farbe, Größe, Warengruppe zusammen, aber das kann man auch als eine Nummer und somit einen Artikel sehen, aber man braucht auf jeden Fall keine 18 Spalten.

Volker

Zum BI schau mal hier

Hat MS da nicht direkt etwas auf der Pfanne (evtl. auch mit SQL-Server)?

oder haben die das ganze als Varianten missbraucht?

Leider ja

Dimensionen sind zwar machbar, aber bei der Datenmenge nicht wirklich handlebar. Du hast dann bei 6 Mio. Artikelposten mit je 3 Ausprägungen 18 Mio. Dimensionswertposten, das macht das ganze nicht einfacher

Wird das mit 2013 besser?

Nur damit ich nicht ganz blöd sterb.

Die Gefahr besteht nicht

Dimensionen wären jetzt also Größe, Farbe, Saison und Varianten wäre die Kombination daraus?

Weißt du, welches Produkt ich meine, wo du die Saison ansprichst? Ja!

Bei der Kasse handelt es sich um eine Navision-Kasse, und wie gesagt, ich hab's nicht programmiert.

Gruß

Rainer

Zum BI schau mal hier
Dimensionen sind zwar machbar, aber bei der Datenmenge nicht wirklich handlebar. Du hast dann bei 6 Mio. Artikelposten mit je 3 Ausprägungen 18 Mio. Dimensionswertposten, das macht das ganze nicht einfacher

Gruß, Fiddi

Wenn du Glück hast sind es "nur" 18 Mio. Wenn die gleichen Dimensionen auch noch in den Verkaufszeilen und dann in Geb. Rechnungen, Lieferscheinen etc pp. mitgeschleift werden wird es sehr schnell sehr viel mehr.