[gelöst]Globale Tabellen

Hallo,

ich habe mal eine Generelle Frage.

Wir arbeiten mit verschiedenen Mandanten in einer DB.
Nun habe ich ja die Möglichkeit Tabellen "Global" zu machen.

Kann ich dies ohne weiteres tun oder gibt es noch besonderheiten zu bedenken ?
Folgendetabellen habe ich hierfür im Auge

Sales/Purchase ( 13 )
Reason Code ( 231 )
Item ( 27 )
Item Translation ( 30 )
Gen. Business Posting Group ( 250 )
Gen. Product Posting Group ( 251 )


Hat jemand damit Erfahrung ?


gruss
Jörg

Zuletzt geändert von Jörg Nissen am 24. November 2010 10:33, insgesamt 1-mal geändert.

Nun, so ganz einfach ist es nicht. Zu beachten ist insbesondere das man das Property nur ändern kann wenn die Tabellen leer sind. Auch sollten man dies wirklich nur erwägen tuen wenn die Daten in allen Mandanten identisch sind. Würde ich in jedem Fall erstmal in einem Testsystem vorexerzieren.

Wenn du die Items Global machen willst, muss bedacht werden, dass die Preise evtl. auch Global gesetzt werden müssen. Oder die Textkonstanten.
Hier würde ich mir wieder den Artikel kopieren Report anschauen und herraussuchen welche Informationen Mandantenübergreifend relevant sind.

Bedenke außerdem: Was ist mit z.B. den Artikel-Dimensionen?
Da die Dimensionstabelle für alle möglichen Tabellen verwendet wird, darf diese z.B. nicht "globalisiert" werden.
Wie wird am Artikel die Wiederbeschaffung, Artikelverfolgung, Planung geregelt?
Was ist mit dem Lagerbestand? Ein Artikel, gleich ein gemeinsamer Artikelpostenpool?

Kurzum: Hände weg von der Artikeltabelle ... Da hängt einfach zu viel dran.

Hallo,

ich habe mal eine Generelle Frage.

Wir arbeiten mit verschiedenen Mandanten in einer DB.
Nun habe ich ja die Möglichkeit Tabellen "Global" zu machen.

Kann ich dies ohne weiteres tun oder gibt es noch besonderheiten zu bedenken ?
Folgendetabellen habe ich hierfür im Auge

Sales/Purchase ( 13 )
Reason Code ( 231 )
Item ( 27 )
Item Translation ( 30 )
Gen. Business Posting Group ( 250 )
Gen. Product Posting Group ( 251 )


Hat jemand damit Erfahrung ?


gruss
Jörg

Nun, es entstehen oftmals gewisse Probleme, wenn DataPerCompany von Yes auf No geswitched wird.

Kurzum: Hände weg von der Artikeltabelle ... Da hängt einfach zu viel dran.

Ja, würde ich auch nicht machen. Stattdessen könnte man über einen Abgleich der Mandanten nachdenken. D.h. bei INSERT, MODIFY, DELETE ein Kennzeichen setzen, einen Änderungsdatensatz in einer eigenen Tabelle schreiben oder sowas und dann beim nächsten Anmelden in den anderen Mandanten einen Abgleich laufen lassen. Die Nummernserie mußt du natürlich schon vorher setzen.

Hallo Natalie,

Wiederbeschaffung über Lagerhaltungsdaten

Die Postentabellen hätte ich natürlich Lokal gelassen.

Aber mit der Item gebe ich dir recht, hatte schon befürchtet das dort zuviel dran hängt.

Wie sieht es aus mit den anderen Tabellen (Sales Price, Item Translation... ).

Diese sollte doch eigentlich problemlos global funktionieren ?



gruss aus dem verschneiten ( naja bald ) Norden
Jörg

Die Lagerregulierung schreibt z.B. auch den neuen aktuellen Einstandpreis und "Einstandspreis ist reguliert" in die Artikeltabelle. Das geht sofort schief, wenn die mandatenübergreifend ist, die Postentabellen aber nicht.

Wie sieht es aus mit den anderen Tabellen (Sales Price, Item Translation... ).

Diese sollte doch eigentlich problemlos global funktionieren ?

Nee, Matthias hatte es ja schon anfangs erwähnt: Das sind genau jene Tabellen, die am Artikel hängen (sie enthalten eine Artikelnr.). Also können die genauso schlecht globalisiert werden.

Hallo zusammen,

anstatt sich auf dieses dünne Eis zu begeben und solch sensible Tabellen mandantenübergreifen ("global") zu machen, solltet ihr eher über eine mandantenübergreifende Datensynchronisation nachdenken.
Hier haben sicher schon zahlreiche Microsoft Partner eine entsprechende Lösung erstellt.

Prinzipiell wären zwei Synchronisationsmethoden denkbar:

1. Bidirektionale Synchronisation: Daten dürfen in allen Mandanten geändert werden und werden in die anderen Mandanten synchronisiert
   Problem: Wie soll umgegangen werden, wenn derselbe Datensatz in zwei Mandanten geändert wurde?
   Lösungsansatz: Synchronisation bis auf Feldebene herunterbrechen, das reduziert die Wahrscheinlichkeit eines Konfliktes.
2. Eindirektionale Synchronisation: Ein Mandant wird als führender Mandant für die Datenpflege definiert.
   Vorteil: Es gibt keine Konflikte, da immer die Daten aus dem führenden Mandanten Vorrang haben.

Dann ist da noch die Frage nach dem Zeitpunkt der Synchronisation:

• Echtzeit-Synchronisation: Die Daten werden direkt beim OnInsert/OnModify synchronisiert.
  Vorteil: Aktuellster Datenstand in allen Mandanten
  Nachteile:
  - Drückt auf die Performance!
  - Programmcode in den Triggern der anderen Mandaten kann nicht ausgeführt werden!
• Synchronisation über eine Warteschlange, die z. B. durch einen NAS abgearbeitet wird
  Vorteile:
  - Sämtliche OnInsert-/OnModify-/OnDelete-Trigger können mit ausgeführt werden
  - Keine nennenswerten Performance-Einbußen, da die Synchronisation abgesetzt ausgeführt wird.
  Nachteil: Die Daten in den anderen Mandanten werden erst zu einer bestimmten Uhrzeit synchronisiert.

Unter Umständen ist es sinnvoll, sowohl die Art, als auch den Zeitpunkt je nach Tabelle ander zu definieren, und eine Kombination aus allem - je nach Tabelle - zu verwenden.

Was man dabei auch im Hinterkopf behalten sollte:
Sperren werden stets auf Objekt-Ebene - z.B. Tabelle - etabliert, insbesondere beim SQL Server (gilt aber m.E. auch für "native"). Oft werden Sperren etabliert (UPDLOCK), obwohl nur soz. "committed" gelesen werden soll (z.B. bei der Verwendung von LOCKTABLE) , somit kann es zu Konflikten kommen.
Bei Mandanten-übergreifenden Stammdaten ist das Problem wohl eher gering, bei Tabellen mit höherem Transaktionsvolumen kann das aber zu erheblichen Blockaden kommen. D.h. mit "DataPerCompany" = FALSE kann man sich ganz schnell einen "Single Point of Failure" bauen ... ich hab' z.B. schon mal die "No. Series" & Co. so vorgefunden, und das war ziemlich hässlich ... Schwierig ist es dann auch, sowas wieder zurück zu bauen ...

Hallo,

vielen Dank für die hilfreichen antworten.

Ich habe es über die Trigger gelöst.


Gruss
Jörg