Sprachmix in Datumstabelle mit Deutsch und Englisch

Bei der Datumstabelle wurde bislang ja immer für einen bestimmten Tag Periodentyp-Optionswert "Tag, Woche,… angezeigt, d.h. deutsche Bezeichnungen
Bei einigen Datenbanken (gleicher Server, identisches Build) wird aber dort auch bei deutscher Sprachlayer und weiterhin deutschen Wochentagsnamen auf einmal "Date, Week,…" angezeigt,
also eine Mischung aus Deutsch und Englisch.
Dadurch lassen sich Objekte, die diese Tabelle nutzen, je nach Datenbank mal kompilieren und mal nicht.

Kennt jemand den Auslöser für dieses Verhalten?

Der MSDN -Artikel beleuchtet die Tabelle natürlich nur aus komplett englischer Sicht .
http://msdn.microsoft.com/en-us/library/dd355175.aspx

Dieser Mix war schon in unserer NAV5 so und ist auch jetzt in der 2009R2 so. Mir ist auch nie aufgefallen, dass jemals alles in derselbsen Sprache gewesen ist. Aber besonders viel mache ich mit der Tabelle allerdings auch nicht.

Mir ist auch nie aufgefallen, dass jemals alles in derselbsen Sprache gewesen ist.

Das war bislang jahrelang unverändert alles in Deutsch .

Das ist das übliche Verhalten:

Datumstabelle2.jpg

Das nicht:

Datumstabelle.jpg

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Ich würde bei mir die Screenshots austauschen, dann passen die zu ihren Überschriften

Hat die Spalte für den Periodentyp bei dir eine Optioncaption?

Hat die Spalte für den Periodentyp bei dir eine Optioncaption?

Die Form ist nicht das Problem, die zeigt den Optionstring an, und hat gar keine Captions, die habe ich nur temporär erstellt um das zu demonstrieren.
Das Problem sind die unterschiedlichen Optionswerte im Optionstring,je nach DB muss im Code mal

Code:

Periodentyp::Tag

und mal

Code:

Periodentyp::Date

stehen, damit der Compiler das Objekt akzeptiert.

Das Problem sind die unterschiedlichen Optionswerte im Optionstring,je nach DB muss im Code mal

Code:

Periodentyp::Tag

und mal

Code:

Periodentyp::Date

stehen, damit der Compiler das Objekt akzeptiert.

Das Problem hatte ich öfters, wenn ich Objekte importiert habe (von DE zu DE). Ich konnte bisher auch noch keine Regel dahinter herausfinden ...

Könnte es eventuell etwas damit zu tun haben, welche fin.stx im Client-Root liegt?
Das würde erklären, warum es bei derselben Buildversion unterschiedlich ist.

Könnte es eventuell etwas damit zu tun haben, welche fin.stx im Client-Root liegt?
Das würde erklären, warum es bei derselben Buildversion unterschiedlich ist.

Es ist immer der selbe SQL-Client und -Servername, es sind lediglich unterschiedliche Datenbanken aus der gemeinsamen Auswahlliste unter "Datenbankname".

Also ich kriege nun reproduzierbar (auf verschiedenen Datenbanken, SQL und Native, NAV5 und 2009R2) folgendes hin:
1. Start NAV
2. Object Designer -> leere Form -> eine Variable d deklarieren vom Typ REC, Subtype "date"
3. im OnOpen diese Zeile: d.setrange("Period Type",d."Period Type"::date);
-> das ergibt den Fehler, der mir sagt, dass es deutsch sein muss.
4. im Object Designer->Form Wizard->Tabular Form auf Date->alle Felder->Finish->Run: dann ist der Periodentyp "Tag".

Wenn ich dann NAV neu starte und in der Reihenfolge Punkt 3 und 4 vertausche, ist in der Form der Periodentyp "Date", und das "SetRange ... " geht ohne den Fehler durch.

Wenn mal jemand Lust hätte, zu veruschen, das nachzuvollziehen?

(Das SetRange mit F11 kann man sich auch schenken, dient nur der Verdeutlichung)

Das Problem gibt es in 2013 aktueller Build auch noch.

Passiert, wenn man mit deutscher Sprache eine neue DB anlegt, dann sind die Option- Values in Deutsch. Schaltet man vor dem Anlegen der DB auf Englisch um, legt die DB an, und danach wieder zurück auf Deutsch, kann man auch die englischen Option- Values benutzen


Gruß, Fiddi

super idee fiddi,

ich habe das gleiche problem bei verschiedenen datenbanken und jedesmal den code umzustricken nervt auf lange sicht!
also sollte man die dbs in englisch anlegen und später auf deutsch umstellen!?

Ich konnte jetzt leider gerade nicht probieren, was beim Aufruf der Tabelle/Page mit den Option- Values passiert, ob die dann auch für den Bediener auf Englisch sind

Gruß, Fiddi

Hallo,

Hatte ein ähnliches Problem gerade mit der Page 9170 bzw. 9174 (Profile bzw. Rollencenter auswählen)

In meiner DB funktioniert zwar die Datumstabelle (DB ist erstellt aus NAV2013- SQL-BAK von der DVD). Leider zeigt mir Page 9174 keine Rollencenter an, weil der gesetzte Filter die deutsche Caption "Rollencenter" verwendet, in der Page aber, wenn man Sie direkt aufruft, die englischen Captions für den "Object- Subtype" verwendet werden.

Ich meine mich an dieses Phänomen auch schon in 2009 RTC erinnern zu können.

Verwendet wird der aktuellste NAV 2013- Build 7.00.34845 (Ursache könnte allerdings auch schon die fehlerhafte DB sein)

Evtl. wäre das mal ein Hinweis für Carsten und seine Kollegen, den DEV- Client mal so schlau zu machen, dass er beim öffnen einer DB die Captions bzw. die Werte der Optionswerte der Systemtabellen prüft, und das Chaos mal beseitigt.

Gruß, Fiddi

Passiert, wenn man mit deutscher Sprache eine neue DB anlegt, dann sind die Option- Values in Deutsch.

Ich habe testweise mit 2009R2, 5 SP1 und 4.03 Clients unter deutscher Sprache neue Datenbanken angelegt (nur mit Systemtabellen), direkt nach der Erstellung sofort eine Form für die Date-Tabelle erstellt. Alle Clients zeigen bei mir in neuen Datenbanken mittlerweile immer "Date" an. Sehr unschöne Situation. Da bleibt wohl nur noch die Flucht in den Integerwert der Option, wenn die Objekte überall kompilierbar sein müssen.

Code:

Date.SETRANGE("Period Type",0); // je nach DB entweder "Date" oder "Tag" , deswegen nicht Styleguide-konform ;-)

Kowa, kannst du mal nachsehen, ob bei einer von deinen Datenbanken, die die Date-Tabelle mit "Tag" anzeigen, in der CU1 oder einem anderen Objekt, das beim NAV-Start läuft, eine Date-Record-Variable aufgerufen wird?

Kowa, kannst du mal nachsehen, ob bei einer von deinen Datenbanken, die die Date-Tabelle mit "Tag" anzeigen, in der CU1 oder einem anderen Objekt, das beim NAV-Start läuft, eine Date-Record-Variable aufgerufen wird?

Nein, da ist nichts in der Richtung.

Zu dumm. So hätte man es nachvollziehen können.