Alternative zum Window Watcher

hallo zusammen,

ich suche eine alternative zum Window Watcher die unter NAV 2009 funktioniert.
der windows watcher V4 funktionert nicht mit pages und xml ports bzw der window watcher funktioniert generell nicht so gut^^

kann mir da jemand etwas empfehlen?
danke im voraus

ps: hab kein richtiges forum gefunden bitte verschieben ;)

Hallo elroberto,

ich kenne den Window Watcher nicht, von daher frage ich einfach mal nach, was ihr damit zu bezwecken versucht.
Vielleicht gibt es für den gewünschten Zweck eine brauchbare Alternative.

@timo,

ich glaube er meint den hier.

Gruß, Fiddi

@timo,

ich glaube er meint den hier.

Gruß, Fiddi

genau den meine ich

Man hat ein kleines Fenster was man sich auf dem Bildschirm positionieren kann.
Dort wird angezeigt wer gerade in welchem Objekt in einer DB entwickelt.
So ist die Chance sehr gering das man sich gegenseitig etwas überschreibt.
Man kann mit dem WW auch Objekte sperren dann bekommt man eine Meldung: Benutzer XY hat am tt.mm.jjjj um xx.xx Uhr das Objekt Typ Nummer gesperrt.
Dann hat man Auswahlmöglichkeiten wie Objekt wieder schließen um nichts zu überschreiben, Objekt übernehmen

Der WW zeigt auch an an welchen Objekten man gerade selber entwickelt und wenn man ein Objekt 2 mal öffnet im Design Modus ändert sich die Farbe(Anhang screen.jpg hab da die CU 80 mal mal geöffnet, die zweite liegt hinter dem Onjekt designer daher für mich auf den ersten Blick nicht sichtbar, das WW Fenster befindet sich oben rechts).

das Problem bei der im Link genannten Version welche ich auch benutze ist das die oben erklärten Funktionen nicht für Pages und XMLports funktionieren.

Wie macht ihr das wenn ihr mit mehrern Leuten an einer DB entwickelt damit ihr euch nichts überschreibt?

Ich hab mal als vorschlag gehört mann könnte bei dem Objekt an dem man gerade entwickelt die zeit zB auf 15:15 Uhr setzen so kann jeder sehen das dieses Objekt quasi "gesperrt" ist. Finde ich jedoch etwas unständlich.

Danke im Voraus.

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

Da wir bei uns sowieso Visual SourceSafe bzw. Celenia VersionControl für die Quellcode-Verwaltung einsetzen, haben wir bisher dieses Problem nicht, da jeder (per Arbeitsanweisung) vorher das zu ändernde Objekt in der Quellcode-Verwaltung auschecken muss.
Somit ist dort schon ersichtlich, dass das Objekt von Benutzer xyz im Zugriff ist.

In der Zeit bevor wir eine Quellcode-Verwaltung eingesetzt haben, wurde auf der Serverdatenbank (auf welcher alle gemeinsam programmierten) vor der Bearbeitung eine Raute mit anschließendem Benutzerkürzel vor die Versionsliste gesetzt. (z. B. #TL,NAVW15.00,NAVDE5.00)

schonmal danke das mit der # wäre keine schlechte idee

vielleicht hat noch jemand anders eine idee

unsere "navision abteilung" in der firma ist recht überschaubar, so dass wir sowas gar nicht nutzen.

visual source safe habe ich schonmal bei nem asp.net projekt verwendet, bei dem ich integriert war (hatte null mit nav zu tun), aber wie verwendet man das mit navision? bei kleineren kunden liegen auch teilweise einfach die nativen datenbankdateien auf dem fileserver, so dass eh nur einer arbeiten kann. wie ist da die struktur "wenn man es richtig macht"? würde mich sehr interessieren... ;)

daniel

Bezüglich der Verwendung von Microsoft Visual SourceSafe kann ich mal meine bisherigen Erfahrungen niederschreiben:

• Es besteht keine direkte Verbindung zwischen Navision und VSS, somit bedarf es einer organisatorischen Lösung
• Jeder entwickelt in einer lokalen Datenbank (CRONUS, um Platz zu sparen)
  Auf einem zentralen Server wird eine Testdatenbank (nach Möglichkeit mit Echtdaten) bereitgestellt.
  (Diese Datenbank wird in regelmäßigen Abständen - z. B. täglich - mit neuen VSS-Ständen versorgt.)
• Die Objekte werden im Textformat in VSS verwaltet.
  Für jedes Objekt existiert eine eigene Textdatei.
• Bevor ein Objekt geändert werden darf, müssen alle neuen/geänderten Objekte aus VSS abgerufen und in NAV importiert werden
  Hier empfiehlt es sich, festzuhalten, wann man das letzte mal Objekte abgerufen hat, um nicht immer alle Objekte abrufen zu müssen.
• Objekte, welche nun geändert werden sollen, müssen vorher in VSS ausgecheckt werden.
  Die Objekte bleiben solange ausgecheckt, bis sie in einem lauffähigen Zustand wieder eingecheckt werden können.
  Wichtig ist beim Einchecken nicht die Fehlerfreiheit, sondern, dass sie kompilierbar sind und die Geschäftsprozesse nicht unterbrechen, da sonst alle anderen beteiligten Entwickler ihre Entwicklung nicht mehr testen können.
• Um nicht unzählige Objekte einzeln im- bzw. exportieren zu müssen, empfiehlt es sich, das gute alte Compare Toolkit von Navision Software a/s zu verwenden, um eine große NAV-Objekt-Textdatei in viele kleine zu zerlegen bzw. aus den vielen abgerufenen Dateien eine große NAV-Objekt-Textdatei zu machen.
• Darüber hinaus handhaben wir es immer so, dass die Objekte ausschließlich ohne "Geändert"-Häkchen eingecheckt werden müssen.
  So kann jeder Entwickler anhand dieses Kennzeichens erkennen, welche Objekte er jetzt exportieren muss.

Da es sich hierbei also hauptsächlich um eine organisatorische Integration handelt, könnte so ziemlich jede Versionsverwaltung (VSS, CVS, SVN, ...) verwendet werden.

danke für die beschreibung. denke der "aufwand" lohnt halt auch erst ab einer gewissen größe richtig. klingt aber nach ner sauberen sache, sofern man es so wirklich durchzieht.

Kann mir jemand sagen wie der Window Watcher v4.0 technisch im Hintergrund abläuft?