deutsch/polnische Mandanten in einer SQL-Datenbank

Hallo Zusammen,

ich hab ein bisschen gegoogelt und auch hier im Forum gestöbert, jedoch keine praktiable Lösung zu folgendem Problem gefunden, vielleicht könnt ihr mir ja helfen.

Software:
MS SQL-Server 2005 und Dynamics NAV 5.00

Problem:
In einer SQL-Datenbank (aus Lizenzgründen) sollen zwei Mandanten errichtet werden. Im ersten Mandanten sollen nur deutsche Anwender über einen Terminalserver arbeiten, im zweiten nur polnische. Für die deutschen Anwender werden deutsche Sprach- und Regionseinstellungen verwendet, für die polnischen Anwender die polnischen Sprach- und Regionseinstellungen.
In beiden Mandaten sollen nun auch die landesüblichen Sonderzeichen verwendet werden, sowohl in den Tabellendaten als auch in den Captions.
Wird die Datenbank mit der deutschen Codepage erstellt, so kann der polnische Client nicht drauf zugreifen, andersrum der deutsche auch logischer Weise nicht.

Fragen:
Gibt es eine Möglichkeit eine Codepage zu verwenden, die beiden Sprachen handhaben und der Nav-Client auch öffnen kann?
Gibt es irgendeine Codepage/Tool/Script/Parameter oder so, den man im SQL-Server einbinden kann um beide Sprachen in einer DB zu betreiben?
Was passiert wenn ich bei der Erstellung der Datenbank den Haken bei "Zeichensatz validieren" entferne? (Ich weiß das Microsoft das nicht empfiehlt aber die empfehlen ja bekanntlich so einiges nicht )
Gibt es irgendeine Möglichkeit oder läuft es zwangsläufig auf zwei getrennte Datenbank hinaus?

Ich wäre sehr froh, wenn ihr mir helfen würdet. Danke schonmal im Voraus.

Gruß Steffen

Hallo NoGravity,
leider hab ich das selbe Problem. Wir wollen auch mehrsprachige Mandaten (deutsch/französisch und polnisch) auf einer SQL DB laufen lassen.
Hast du schon eine Lösung gefunden ?
Danke,
Martin

Hallo Martin, Hallo NoGravity,

auch wir befinden uns in der selben Situation. Nach Microsoft ist die einzige Lösung eine eigene DB pro Codepage. Eigentlich sollen bei uns zwei Mandanten und nicht zwei DB's entstehen. Ich habe gelesen, dass es einen Mitteleuropäischen Characterset gibt (Latin-2) der beide Sprachen kann (frz. ist allerdings nicht enthalten).

Was ist euere Lösung?

Gruesse
Bernd

Aktueller Stand :
Momentan haben wir folgende Codepages:
DB1 : Deutsch + Französisch : Codepage : "Western-European dictionary sort order, code page 1252, case-sensitive, accent-sensitive (51)" . „Zeichen validieren“: JA
DB2 : Polnisch : Polish dictionary sort order, code page 1250, case-insensitive, accent-sensitive (88)
„Zeichen validieren“: NEIN

„Zeichen validieren“ muss auf false sein wenn man mit einem polnischen und einen deutschen client auf eine db zugreifen will.

Grüße,
Martin

Die Frage die ich mir stelle ist nur, ob man etwas kaputt macht oder ob etwas kaputt gehen kann, wenn man die Option "Zeichensatz Validieren" entfernt. Ich möchte ungern vom Kunden angerufen werden wenn die Datenbank im Eimer ist
Wir haben für den Fall jetzt 2 Datenbanken erstellt. Eine für den deutschen und einen für den polnischen Mandanten. Damit haben wir eine saubere Trennung.

Hi Gravity,

wir sind ebenfalls so vorgegangen und haben dann ein Tool zur Synchronisation von Stamm- und Bewegungsdaten entwickelt. Die Zeichenvalidierung herauszunehmen ist schon nicht ohne Risiko, sodass wir uns dagegen entschieden haben.

Gruesse
Bernd

Die Zeichenvalidierung herauszunehmen ist schon nicht ohne Risiko, sodass wir uns dagegen entschieden haben.

Hallo zusammen,

welche Risiken treten denn auf, wenn man das Häkchen herausnimmt?

Klar, die deutschen Clients (Latin-1) würden dann in den Belegen "falsche" Zeichen dargestellt bekommen, ruft man den Beleg jedoch von einem osteuropäischen Client (Latin-2) auf, dann müsste die Anzeige (für den Beleg) wieder stimmen.

Wenn man Schlüsseloptimierung betreiben möchte, bliebe wohl nur die Collation auf Tabellenebene zu ändern.
Aber wenn man mehrere Mandanten in eine DB packt, sieht es eher danach aus, als wäre Kosten/Nutzen in keiner Weise gegeben.

Wir arbeiten mit eine DB pro Land, um alle Legals abzubilden von NAV und die Legal Thematik auf die Partner zu verlagern. Bei einem Legal-"Mischmasch" fühlt sich wieder keiner zuständig...

Hallo Jan,

danke für die Antwort.
In meinem konkreten Fall geht es nicht darum, osteuropäische Mandanten in einer westeuropäisch eingerichteten Datenbank abzubilden, sondern darum, in dem deutschen Mandanten osteuropäische Kunden mit deren Sonderzeichen im Namen und/oder der Adresse abzubilden.

Ich habe mir schon eine Demoversion des "Unicode Tool for NAV" von OctoCon zuschicken lassen, kam jedoch noch nicht dazu es zu testen.

Wer also noch weitere Tipps, Tricks und sonstige nützlichen Informationen zu diesem Thema beisteuern kann: Immer her damit!

Hallo,

wir haben es einfach ausprobiert: Haken "Sortierung überprüfen" herausgenommen, von einem auf polnisch gestellten Client drauf zugegriffen, es gab eine Warnmeldung beim ersten öffnen der Datenbank. Danach normales arbeiten, die polnischen Zeichen werden angenommen und gedruckt. Auf deutschen/englischen Cients wurden die polnischen Sonderzeichen nicht/falsch dargestellt. Wenn man über Text sortiert ist es evtl. ein Problem, sonst nicht.

LG Jens

Hallo Jens,

vielen Dank für deine Erfahrungswerte.
Unser Kunde hat auch einige Tests (auf einer extra dafür bereitgestellten DB) durchgeführt.
Polnische Zeichen aus deutscher Umgebung eingegeben, polnische Zeichen aus polnischer Umgebung eingegeben, ...
Anzeige aus deutscher Umgebung: keine Fehler (nur halt falsche Zeichendarstellung)
Datenbanktest aus dt. Umgebung -> keine Probleme
DaSi erstellen aus dt. Umgebung -> keine Probleme
DaSi zurückspielen in dt. Umgebung -> keine Probleme

Vorsichtshalber haben wir in der Codeunit 1 die Funktion MakeCode (ID: 109) angelegt, welche in Codefeldern nur noch ASCII-7bit-Zeichen (0..127) erlaubt.
Dies sollte das Risiko auf ein akzeptables Minimum reduzieren.