[gelöst] Benutzereinstellungen (ZUP) und Programmänderungen

Liebe Kolleginnen und Kollegen,

Da ich noch relativ neu mit NAV 5.0 code würde es mich interessieren wie ich generell die Einstellungen der User bei Programmänderungen besser schützen kann.

Ich stelle fest, dass wann immer ich einen neuen Release mache (d.h. kompiliere) die User

a) die Software neu starten müssen
b) Ihr Layout sich wieder ändert (Spalteneinstellungen, sichtbar/versteckt, Breite etc...)

Irgendwie ist mir der Gesamtzusammenhang noch nicht klar. Ich kann jedoch nachvollziehen, dass z.B. Aenderungen an der Businesslogik (z.b. Codeanpassungen bei Tabellen etc..) einen Neustart erfordern. Jedoch scheinen dann auch immer die Benutzereinstellungen zurückgesetzt zu werden.

Kann ich diese Problematik reduzieren? Verhindern?

Danke Euch!

ps: der Vorschlag meiner Mannschaft bisher: Arbeite in der Nacht! ein NO GO! :)
pps: Nein, ich möchte auch nicht auf einer gespiegelten Version arbeiten.

Zuletzt geändert von Izzy am 11. Juni 2013 16:38, insgesamt 1-mal geändert.

pps: Nein, ich möchte auch nicht auf einer gespiegelten Version arbeiten.

Du meinst doch hoffentlich nicht, dass du im Echtsystem entwickelst? Das wäre nach meiner Meinung unverantwortlich, verrückt, wahnsinnig.

Kann ich diese Problematik reduzieren? Verhindern?

Du kannst Forms mit demselben Datum/mit der selben Uhrzeit wie davor speichern. Dann bleiben die persönlichen Anpassungen der Spalten erhalten. Kann aber zu Problemen führen, wenn Spalten entfernt oder hinzugekommen sind. Besser ist es mE nach, die Spalten gleich so anzuordnen, dass möglichst viele Anwender damit arbeiten bzw. nur noch sehr wenig anpassen müssen, wenn sie neu gespeichert worden sind.

Bei Änderungen an den Tabellen ist nichts zu machen; der Anwender muss mindestens seinen Vorgang abbrechen. Ein Neustart ist jedoch idR das Beste.

Die Einstellungen der Benutzer werden in einer zup Datei gespeichert.
Wenn ein Objekt geändert wird, werden die Benutzereinstellungen hierfür in der ZUP-Datei zurückgesetzt bzw. nicht verwendet. Das ist im Standard so erwünscht.

Geprüft wird das anhand des Timestamp des Objektes.
Wenn du also vorher das Feld "Time" des zu änderten Objekts kopierst (inkl. Kommastellen) und danach wieder einfügst könntest du dieses Verhalten umgehen. Allerdings könnte das in einigen Fällen zu unerwünschten Seiteneffekten führen.

P.S.: McClane war mal wieder schneller.


mfg,
winfy

ps: der Vorschlag meiner Mannschaft bisher: Arbeite in der Nacht! ein NO GO! :)

Warum denn eigentlich nicht

pps: Nein, ich möchte auch nicht auf einer gespiegelten Version arbeiten.

Du sollst ja auch nicht mit einer Spiegel-DB arbeiten (die ist ja für den Fall der Fälle) sondern mit einer Entwicklungs-DB, die Daten/Objekttechnisch weitgehend dem Produktiv-System entspricht.

Vielen Dank für Eure Antworten!

Ich entnehme dem, dass das Verhalten welches ich beobachte also so Standard ist. Und danke für den Tip mit der Timestamp, ich werde das mal ausprobieren.

Es ist eben so, dass wir ne kleinere KMU sind. Meine Anpassungen sind zu fast 90 % reine visuellen Sachen. D.h. z.b. Felder oder Design eines Reports anpassen. Oder mal n neues Feld bei ner Tabelle hinzufügen etc.. Von Eingriffen in die Logik habe ich mich bisher immer ferngehalten. Im schlimmsten Falle hätte ich jederzeit eine Kopie der DB zur Hand.

Dennoch finde ich den Punkt mit ner Developer-Kopie schon angebracht. Ich werde das wohl so umsetzen und nach dem Testing per Dataport die geänderten Objekte austauschen.

ps: Ich habe schon versucht "standard"-Ansichten für die jeweiligen Forms und Tabellen zu definieren. Problem ist: wir haben hier intern zwei Divisionen und beide kreischen laut drauflos wenn ich für die eine oder andere etwas optimieren möchte. Dabei ist es reine Gewohnheit der Anwender. Aber doof ist schon, dass jeweils, z.B., wieder ausgeblendete Spalten erscheinen nur weil ich irgend ne kleine Layoutänderung eines Forms gemacht habe.

Danke euch!