MBS developement is for every major version merging existing DIS layers - however you will find that for example the Russian DIS layer is a tricky layer to merge, since that layer i huge.
All other layers will try to keep their pieces of country specific functionality to a bare minimum thereby enabling us to easier merge these pieces into a new version.
Having written this - we have a team at MBS who is concentrating on merging these DIS layers into the next major release - in this case 4.0. However in the meantime, partners would have to merge the DIS layers themselves, if they require and choose to run with more than one DIS layer on the same installation.
Best regards
Mai-Britt
________________________________
Fra: origaet [mailto:[EMAIL PROTECTED]
Sendt: l� 28-02-2004 13:35
Til: [EMAIL PROTECTED]
Emne: [development-axapta] Mutli-Country Implementation - Single Database
Dear all,
I am investigating how a world-wide roll-out of Axapta can be
established using one central database.
The biggest problem I see at current is related to the Country
Specific layers, whereas these are developed by each MBS Country
Team.
Possibly, whithout having it investigated, these country layers can
have contradictionary approaches. Most likely, there are country
layers that have upgraded the database with new fields and even
tables.
In previous topics I read suggestions that the different country
layers (DIS, DIP) should be merged.
If however the database schemes are different between country layers
merging the layers will results in greater inconsistencies.
Having to investigate all the different layers to find out what is
matching and what not, and thereafter perhaps applying all the
differences to one base country layer becomes unfeasible.
I recognize two possible situations.
Situation 1
If database schemes are identical, one could consider installing
an application for each layer.
Situation 2
If database schemes are different, one will have to patch all the
country layers into one big layer. Apply the database changes made
by every country to the central database, validate all the country
application layers, and hope all of it works.
I have a few questions about the subject:
1. Is there some kind of standardized development rule to avoid two
or more countries apply similar - but not precise the same -
database changes. Maybe by giving each country seperate ranges for
naming tables, fields, etc...
2. What experiences do we have with inconsistencies between
different country layers - especially database schemes.
3. In case of situation 1 is there a way to use one central
application. I am thinking about determing the country layer to use
based on logon parameters.
4. Are there more issues besides the country layers that should be
investigated thoroughly for this kind of roll-out.
5. Is MBS planning to do some about this problem, for at least the
aim is to also cover global companies.
All information is welcome!
Kind Regards
Danny Gaethofs
Yahoo! Groups Sponsor
ADVERTISEMENT
Click HereClick Here <http://rd.yahoo.com/SIG=12c63lig6/M=274551.4550177.5761904.1261774/D=egroupweb/S=1705006764:HM/EXP=1078058127/A=2019528/R=2/SIG=141cnn6h7/*http://ad.doubleclick.net/jump/N3349.yahoo1/B1282054.27;abr=!ie4;abr=!ie5;sz=300x250;code=18634;dcopt=rcl;ord=1077971727683696?>
________________________________
Yahoo! Groups Links
* To visit your group on the web, go to:
http://groups.yahoo.com/group/development-axapta/
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
Yahoo! Groups Links
- To visit your group on the web, go to:
http://groups.yahoo.com/group/development-axapta/
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
<<winmail.dat>>
