Hallo zusammen,

ich bin neu hier im Forum und suche nach ein paar Antworten auf drängende Fragen. Würde mich freuen, wenn mir hier jemand helfen kann.

Im Rahmen eines Projektes erörtern wir in meiner Firma momentan, wie man BaaN modernisieren kann. Dabei geht's von der Migration auf Infor ERP LN bis hin zu Möglichkeiten, die bestehende Installation und deren umfangreichen Individualteil zu erweitern.

Was mich im Besonderen beschäftigt, ist die Frage ob es machbar bzw. sinnvoll ist, eine Baan IV Installation mit einer T-Base Datenbank z.B. auf eine aktuelle Oracle Datenbank umzustellen. Als Vorteil würde ich die leichtere Zugänglichkeit der Daten sehen. Fraglich ist für mich, in wiefern man die BaaN Installation, Tabellen, Sessions etc. anpacken und bearbeiten müsste, damit das funktioniert. Steht der spätere Nutzen zum Aufwand in einem vernünftigen Verhältnis oder würde sich so etwas gar nicht lohnen?

Hat jemand in dieser Richtung Erfahrungen oder Fachwissen, mit dem mir geholfen werden könnte? Für Infos, die mir bei der Entscheidungsfindung helfen, wäre ich sehr dankbar.

Gruß,
Elladan

Hallo,

grundsätzlich ist die Umstellung auf Oracle ohne weitere Anpassungen an Tabellen und Sessions möglich.
Es gibt allerdings einige Sessions, die auf einer relativen Datenbank spürbar langsamer ablaufen, da es im BaanIV 4GL Code einige Sourcen gibt, die auf T-Base zwar gut funktionieren, aber aus SQL Sicht nicht optimal sind. Diese Stellen sollten, wenn sie einen Engpass darstellen dann umprogrammiert werden.

Wenn man die Einrichtung der Oracle Datenbank gut durchplant, kann man auch durchaus ein spürbar schnelleres System erhalten. Für genauee Aussagen sollte man aber Datenvolumen und Verteilung der Daten auf die Tabellen analysieren.

MfG
Jörg Schlingmann

Hallo,

wenn die Performanz des Systems sowie der Platz in den Tabellen (es gibt eine Begrenzung auf 2GB mit tbase) nicht die eigentlichen Problem darstellen, sondern es wirklich "nur" darum geht, auch ausserhalb des Baansystems auf dessen Daten zuzugreifen, so gibt es noch eine weitere Moeglichkeit, dies kostenguenstig zu realisieren.
Wenn der Zugriff auf die Daten nicht tagesaktuell sein muss, so ist es sehr einfach, diese nachts aus Baan heraus- und z.B. in eine mysql Datenbank hineinzuladen.
Wir betreiben dieses Spiel seit Jahren und haben im Intranet nette Gimmicks gebastelt, die mit diesen "fast aktuellen" Baandaten funktionieren.

mfg

Norbert

Hallo zusammen,

ich bin neu hier im Forum und suche nach ein paar Antworten auf drängende Fragen. Würde mich freuen, wenn mir hier jemand helfen kann.

Im Rahmen eines Projektes erörtern wir in meiner Firma momentan, wie man BaaN modernisieren kann. Dabei geht's von der Migration auf Infor ERP LN bis hin zu Möglichkeiten, die bestehende Installation und deren umfangreichen Individualteil zu erweitern.

Was mich im Besonderen beschäftigt, ist die Frage ob es machbar bzw. sinnvoll ist, eine Baan IV Installation mit einer T-Base Datenbank z.B. auf eine aktuelle Oracle Datenbank umzustellen. Als Vorteil würde ich die leichtere Zugänglichkeit der Daten sehen. Fraglich ist für mich, in wiefern man die BaaN Installation, Tabellen, Sessions etc. anpacken und bearbeiten müsste, damit das funktioniert. Steht der spätere Nutzen zum Aufwand in einem vernünftigen Verhältnis oder würde sich so etwas gar nicht lohnen?

Hat jemand in dieser Richtung Erfahrungen oder Fachwissen, mit dem mir geholfen werden könnte? Für Infos, die mir bei der Entscheidungsfindung helfen, wäre ich sehr dankbar.

Gruß,
Elladan

Hallo,

der Umstieg von Tbase zu Oracle sollte auch aus der Sicht "Zukunftssicher mit BaaN" gesehen werden.

Spaetestens bei LN ist RDBMS ein muss !

Wenn der dedizierte ORACLE Server performant ausgelegt ist, sollte keine Session ein Problem sein.

Eine Migration von Tbase zu Oracle 10g ist an einem Wochende zu realisieren.

mfg

Wie oben ja schon festgestellt wurde, die Migration nach Oracle (oder Informix etc.) sollte sich eigentlich problemlos gestalten, Umprogrammierungen sollten normalerweise nicht nötig sein. Der einzige Vorteil, den man dadurch gewinnt, liegt dann aber eben in der besseren Zugänglichkeit der Daten bspw. durch ODBC. Wenn man sich dadurch verbessern will, dass man in Zukunft mit Reporting-Tools arbeitet (Crystal, Cognos oder ähnliches), wäre eine solche Migration zwingende Voraussetzung.

Mittelfristig solltet ihr auf jeden Fall eine Migration nach LN ins Auge fassen, wenn Ihr Euch von den Abläufen her verbessern wollt: Baan IV ist mittlerweile so 10 bis 15 Jahre alt (von der Technologie über die Konzepte bis hin zum konkreten Programmcode), das merkt man teilweise schon. Auch sind, wenn ein System mal über längere Zeit läuft, nur noch minimale Verbesserungen in den Abläufen möglich. Vieles ist dann so festgefahren, dass man kaum etwas in einem "kleinen" Projekt realisieren kann. Meiner Erfahrung nach braucht es ab und zu die "große Aktion", um besser werden zu können. Die Migration nach LN wäre sicher so ein Schritt (vor allem, wenn Ihr viele Anpassungen habt) - im Grunde sollte man so ein Projekt wie eine Neueinführung behandeln: Mit allen Nachteilen, was Kosten und Zeitaufwand angeht (das geht nicht nur mit internen Resourcen, und das geht nicht in ein oder zwei Monaten), aber auch mit dem Vorteil, mal wieder einen Quantensprung machen zu können.

Hey, Danke für eure Antworten!

Also wenn ich euch richtig verstehe, sollte es relativ problemlos möglich sein, eine bestehende Standard-Installation mit T-Base DB auf eine modernere Datenbank umzustellen.

Die große Preisfrage, die sich mir natürlich in dem Zusammenhang stellt, ist: Was ist, wenn man wie wir einen umfangreichen Individualteil einsetzt, der nicht auf die Standardtabellen von Baan IV zurückgreift?
Die Sessions und Programme sind zwar alle konsequent in der Baan-Logik gehalten, doch befürchte ich da schon Probleme bei einer Umstellung oder?

Was würde ggf. mit selbst geschriebenen Queries geschehen, die z.B. für Sonderauswertungen genutzt werden, für die es keinen passenden Report gibt? Diese müssten wahrscheinlich neu gemacht werden, oder?

Ich muss dabei zugeben, dass ich vergleichsweise wenig Ahnung von Datenbanken habe ...

Noch einmal Danke für Eure Hilfe!

Gruß,

Karsten (Elladan)

Hey, Danke für eure Antworten!

Also wenn ich euch richtig verstehe, sollte es relativ problemlos möglich sein, eine bestehende Standard-Installation mit T-Base DB auf eine modernere Datenbank umzustellen.

Die große Preisfrage, die sich mir natürlich in dem Zusammenhang stellt, ist: Was ist, wenn man wie wir einen umfangreichen Individualteil einsetzt, der nicht auf die Standardtabellen von Baan IV zurückgreift?
Die Sessions und Programme sind zwar alle konsequent in der Baan-Logik gehalten, doch befürchte ich da schon Probleme bei einer Umstellung oder?

Was würde ggf. mit selbst geschriebenen Queries geschehen, die z.B. für Sonderauswertungen genutzt werden, für die es keinen passenden Report gibt? Diese müssten wahrscheinlich neu gemacht werden, oder?

Ich muss dabei zugeben, dass ich vergleichsweise wenig Ahnung von Datenbanken habe ...

Noch einmal Danke für Eure Hilfe!

Gruß,

Karsten (Elladan)

Hallo,

die Daten werden von Tbase nach Oracle verschoben.
Export Table Dump von Tbase, Change Portingset, Import Dump nach Oracle.

Also greifen nach der Umstellung alle Sessions/Queries auf die gleichen Daten zu wie vorher, nur eben in einer anderen Datenbank.


mfg

BD

Ich kann dem oberen nur zustimmen: Die Migration ist straight forward und man muss nur auf folgendes achten:

a) Bei grosser Datenmenge kann der import in Baan entsprechend lange laufen
b) Diverse Sessions werden danach langsamer sein (oben bereits erwaehnt)
c) syntaktisch wird sowohl standard Baan als auch customizing problemlos laufen.

Vorteiule sehe ich ua. folgende:

- drastisch verbessertes Locking Verhalten speziell bei >100 usern
- keine korrupten Tabellen und kein Stundenlanges reparieren von Tabellen mehr
- keine 2GB Grfenze pro Tabelle (existiert die noch?)

Lohnt sich also fuer groessere Kunden tatsaechlich immer.

Gruss

Nochmal zum Verständnis: Die Programmiersprache, in der Baan geschrieben ist - und in der auch alle Anpassungen geschrieben sind, ist unabhängig von der konkreten Datenbank. Das gilt für alles: Tabellennamen, Tabellenfeldnamen, SQL-Syntax, Queries, Reports etc. Zwischen der Programmiersprache und der Datenbank sitzt ein Baan-interner Datenbanktreiber. Was innerhalb von Baan IV geschrieben ist, egal ob Standard oder Anpassung, funktioniert ohne Änderung mit jeder Datenbank, die von Baan IV unterstützt wird. Seltene Ausnahmen bestätigen die Regel, es gibt ein paar Query-Konstrukte, die Oracle nicht so gern mag, aber die sind so komplex und spezialfällig, dass sie in den üblicherweise gemachten Anpassungen und Zusatzprogrammierungen nicht auftreten werden.

Hallo,

wie bereits erwähnt spielen sowohl Datenvolumen als auch die Anpassungen beim Umstieg DB Wechsel als auch beim Umstieg von IV auf LN V6.3 eine Rolle.

DB Umstieg:
Bitte beachten: BaaN ERP als auch ERP LN unterstützen nicht T-Base!

Wechsel IV -> LN:
Bitte ServicePack -Stand beachten, damit die Migrationstools greifen! Andernfalls müssen vor dem Umstieg noch SP hochgezogen werden.

Zusatztool:
Wir haben ein Tool geschrieben, mit dessen Hilfe wir analysieren, welche
Session/Anpassungen überhaupt genutzt werden. Sehr hilfreiches Tool
um zu erkennen, was in der Historie mal angepaßt worden ist und seitdem
nie mehr verwendet wurde.

(...)
- keine 2GB Grfenze pro Tabelle (existiert die noch?)
(...)


Ja tut sie (Solaris/T-Base). Sie ist auch der Grund fuer unsere aktuelle Umstellung.

Kann es sein, dass Oracle einige ORDER BY statements im Code verlangt, die man frueher weglassen konnte, da es nicht automatisch den benutzten Index zur Sortierung nimmt?

Ja, ohne Order by kommen die Daten in einer scheinbar zufaelligen Reihenfolge, meisstens in der Reihenfolge wie die Daten eingefuegt wurden.

Oracle hat kein Default Index, wenn also der baan treiber kein order by hinzufuegt durfte dem so sein. Allerdings ist mit nicht ganz klar, was mit "den benutzten index" gemeint ist. Meinst du den in der Where Clausel?

Ja.
Das werde ich dann wohl "eventuell" testen muessen.