Datenverlust bei Team-Projekten

[J. Lüthje]

Systeminformationen: [ Citavi Version 3.1.15, Windows XP, Deutsch, -, -, - ]

Sehr geehrter Citavi-Support,

nachdem wir Citavi schon vorher benutzt hatten, haben wir kürzlich die Team-Version von Citavi 3 gekauft. Unsere Datenbanken liegen auf einem Server im LAN, und wir möchten diese eben in einem Team von Kollegen bearbeiten. Nun haben wir uns natürlich zunächst gefragt, wie die Team-Version mit Änderungskonflikten umgeht. Bei der Arbeit mit Einzelprojekten kann ja immer nur ein Benutzer zur Zeit Änderungen an einer Datenbank vornehmen. In diesem Punkt hatten wir uns den entscheidenen Vorteil der Team-Version erhofft.

Ihre Ausführungen zum "Konfliktmanagement in der Team-Version" unter
http://manual.citavi.com/de/?team_konfl ... gement.htm
sind allerdings enttäuschend. Offensichtlich ist es ja so, dass in dem geschilderten Beispiel die Änderungen von Benutzer A verloren gehen (und wahrscheinlich noch dazu ohne dass er dies überhaupt bemerkt). Das kann ja nicht Sinn der Sache sein!!
Wir würden z.B. erwarten, dass wenn ein Benutzer einen Datensatz geöffnet hat, dieser dann für alle anderen Benutzer nur lesbar ist -- also im Prinzip so, wie es auch bei Einzelprojekten der Fall ist, nur dass die Sperrung in der Team-Version nicht auf Dateiebene, sondern auf Datensatzebene stattfände. Auf jeden Fall möchte man doch vorher über einen möglichen Konflikt informiert werden ... nicht etwa hinterher, nachdem man schon Arbeit und Zeit investiert hat. Und gar wie hier das stillschweigende Verwerfen von Änderungen ist völlig inakzeptabel! Damit wird doch der Zweck einer Team-Version ad absurdum geführt!

Bitte teilen Sie uns mit, ob sich dieses Verhalten von Citavi irgendwie ändern lässt. Wenn nicht, werden wir auch im Team weiterhin nur Citavi-Einzelprojekte bearbeiten, da dann wenigsten zuverlässig gewährleistet ist, dass beim Ändern keine Daten verloren gehen. In dem Fall hätten wir auf die Anschaffung der Citavi-Team-Version allerdings verzichten können ...

MfG, J. Lüthje

[Hans Siem Schweiger]

Sehr geehrte Frau / sehr geehrter Herr Lüthje,

vielen Dank für Ihre Anfrage. Es ist in der Tat so, dass unter bestimmten Umständen die Änderungen des Nutzers A mit den Änderungen des anderen Nutzers B überschrieben werden, ohne dass dies von den Nutzern bemerkt werden kann. Dies tritt immer in den Fällen auf, in denen beide Nutzer zur gleichen Zeit an der gleichen sog. Entität arbeiten. Citavi kennt dabei die folgenden Entitäten:

• reference
• person
• publisher
• periodical
• series title
• location
• library
• keyword
• category
• knowledge item
• task item
• entity link

Mit einem Beispiel verdeutlicht bedeutet das: Wenn zwei Nutzer auf der Registerkarte "Titel" eines Titels (=reference) Einträge ändern, "gewinnt" derjenige, der später die Speicherung auslöst. Wenn Nutzer A Änderungen auf der Registerkarte "Titel" eines Titels (=reference) macht, der andere aber an einem Zitat desselben Titels arbeitet (=knowledge item), dann beeinflussen sie einander nicht.

Selbstverständlich ist es möglich, dass zwei Nutzer an derselben Entität arbeiten und dadurch die Änderungen des einen Nutzers verloren gehen. Nach unseren Erfahrung mit Datenbankprojekten ist das aber tatsächlich ein seltener Ausnahmefall, den wir vorerst in Kauf genommen haben bzw. den Sie ggf. in Kauf nehmen müssten, denn eine Änderung dieses Verhaltens ist durch den Nutzer nicht möglich.

Mit freundlichen Grüßen
Hans Siem Schweiger

[Thomas Schempp]

Eine Ergänzung aus technischer Perspektive von meiner Seite:

In der Datenbank-Terminologie spricht man bei Mehrbenutzerszenarien von "Pessimistic locking" und "Optimistic locking".

"Pessimistic locking" war zu Beginn (d.h. in den 70er und 80er Jahren) das übliche Verfahren: Ein Datensatz wird in dem Moment gesperrt, in dem er bei einem Anwender angezeigt wird bzw. in Bearbeitung ist, unter der pessimistischen Annahme, dass ein anderer Benutzer ihn gleichzeitig bearbeiten möchte.
Mit zunehmenden Benutzerzahlen pro Datenbank und vor allem seit dem Take-Off des Webs hat sich Pessimistic locking aber als zu schwerfällig erwiesen. Einerseits werden Bearbeitungen manchmal abgebrochen, so dass der Datensatz vergeblich gesperrt wurde. Andererseits gibt es im Web gar keine vernünftige Möglichkeit zu erfahren, ob ein Datensatz in Bearbeitung ist.

Aus diesen Gründen wird heute in aller Regel Optimistic locking eingesetzt. Ein Datensatz steht immer zur Bearbeitung frei, unter der optimistischen Annahme, dass kein anderer Benutzer ihn gleichzeitig bearbeiten wird.
Beim Zurückschreiben in die Datenbank muss in diesem Szenario aber geprüft werden, ob der Optimismus berechtigt war. Falls der Datensatz verändert oder gelöscht wurde, muss ein Konflikthandling greifen. Das macht Citavi Team bereits heute. Eine zweite Frage ist, ob das Konflikthandling auch im User Interface präsentiert wird. Das macht Citavi Team noch nicht.

Nun gestehe ich gerne zu, dass das Citavi-Konflikthandling "Der letzte gewinnt" etwas primitiv ist. Ich kann Ihnen andererseits versichern: Es ist in realen Arbeitssituationen extrem selten, dass zwei Anwender gleichzeitig den gleichen Datensatz verändern.
Es gibt vier grundlegende Datenbank-Operationen:
CREATE (einen Datensatz erstellen)
READ (einen Datensatz lesen)
UPDATE (einen Datensatz ändern)
DELETE (einen Datensatz löschen)
Wenn Sie sich Statistiken von produktiven Datenbanken anschauen, sind die beiden letzten Operationen ziemlich selten. In erster Linie wird gelesen und ergänzt, hin und wieder wird geändert, fast nie gelöscht. Nur UPDATE und DELETE sind jedoch für das Konflikthandling relevant; READ und CREATE sind unproblematisch.
Dass zwei Anwender gleichzeitig den gleichen Datensatz ändern, ist nicht ausgeschlossen, aber äusserst unwahrscheinlich. Hinzu kommt, dass Citavi wie von Herrn Schweiger beschrieben einen "Titel" in mehreren Entitäten verwaltet und diese beim Konflikthandling separat behandelt werden; dies macht Datenkonflkte noch unwahrscheinlicher.

Deshalb haben wir uns in der ersten Version von Citavi zum genannten "primitiven" Konflikthandling entschieden. Bisher ist mir kein Fall bekannt, bei dem es deswegen im produktivem Einsatz zu Datenverlusten gekommen ist.

Dennoch bleibt die theoretische Mögichkeit bestehen und ein besseres Handling ist wünschenswert. Wir werden mit Citavi Team nicht zum "Pessimistic Locking" wechseln; zur Sicherheit werden wir aber in einer späteren Version das Konflikthandling auch im User Interface anbieten.

Mit freundlichem Gruss,
Thomas Schempp

[Tilman]

Ich war ebenfalls anfangs enttäuscht über das primitive Konfliktmanagement. Da das was ein durchschnittlicher Citavi-Nutzer aber als "Titel" oder "Eintrag" bezeichnet (Alle Karteireiter/Tabs + Zitate + Schagwörter + Kategorien) in Wirklichkeit (also Citavi-intern) in mehreren unabhängigen Einzelteilen verwaltet wird, reduziert sich die Wahrscheinlichkeit von Konflikten enorm.

Die Kernaussagen dieses Topics sollten im Handbuch beim Stichwort Konfliktmanagement genannt werden. Nicht alle Nutzer/Verwalter von Citavi-Installationen sind so sehr firm in Datenbanktheorie...

Tilman

[J. Lüthje]

Zunächst einmal vielen Dank für die Antworten. Besonders danke ich Herrn Schempp für die ausführliche Darstellung von Citavi-Details, die ich sonst nirgendwo gefunden habe, die u.a. auch eine präzisere Diskussion ermöglichen.

Bei einem Programm wie Citavi, dessen Zweck es ist, Daten zu sammeln und zu "verwalten", sollte unseres Erachtens die Datensicherheit sehr im Vordergrund stehen. Deshalb ist uns nach wie vor unverständlich, warum Citavi das Optimistic Locking verwendet, und noch dazu einen auftretenden Konflikt den Benutzern nicht meldet.
Bei Datensicherheit ist ebenso wie bei anderen Sicherheitsfragen unseres Erachtens eine optimistische Herangehensweise wenig angebracht. So machen Ärzte z.B. vor einer Operation eine auf Sicherheit ausgelegte
gründliche chirurgische Händedesinfektion, und nicht etwa eine schnelle "optimistische Händedesinfektion", auch wenn diese eine Menge Zeit sparen würde.

Selbstverständlich ist es möglich, dass zwei Nutzer an derselben Entität arbeiten und dadurch die Änderungen des einen Nutzers verloren gehen. Nach unseren Erfahrung mit Datenbankprojekten ist das aber tatsächlich ein seltener Ausnahmefall, den wir vorerst in Kauf genommen haben bzw. den Sie ggf. in Kauf nehmen müssten, [...]

Das möchten wir ganz sicher nicht in Kauf nehmen. Und wenn wir überhaupt auf die Idee gekommen wären, dass ein Datenbankprogramm in einer sog. "Team"-Version den stillschweigenden Verlust von Nutzerdaten billigend in Kauf nimmt, so hätten wir ehrlich gesagt diese "Team"-Version niemals gekauft.

In den vorangehenden Antworten wurde verschiedentlich geschrieben, dass es nur selten zu Änderungskonflikten komme, zumal diese nicht auf der Ebene von Datensätzen, sondern auf der Ebene von "Entitäten" auftreten:

Deshalb haben wir uns in der ersten Version von Citavi zum genannten "primitiven" Konflikthandling entschieden. Bisher ist uns kein Fall bekannt, bei dem es deswegen im produktivem Einsatz zu Datenverlusten gekommen ist.

Das sagt nicht unbedingt viel aus, denn Citavi-Team gibt es noch nicht lange. Und außerdem: Wie soll Ihnen ein Anwender überhaupt von einem Problem berichten, wenn er selbst davon nichts erfährt -- weil Citavi
ihm diesen Konflikt ja gar nicht meldet? Wie groß die Wahrscheinlichkeit dafür ist, dass ein Kunde einen Datenverlust bis jetzt von selbst bemerkt und Ihnen dann mitgeteilt hat, lässt sich wohl kaum abschätzen.

Auch ist uns noch nicht klar, was bei Citavi eigentlich gegen Pessimistic Locking spricht. Da Citavi keine Web-Anwendung ist, greift das von Herrn Schempp genannte Argument in Bezug auf das Web hier nicht.
Es bleibt das Argument

[...] hat sich Pessimistic locking aber als zu schwerfällig erwiesen.

Aber wenn doch ein Änderungskonflikt -- wie behauptet -- sowieso nur so selten auftritt, wie kann dann ein Pessimistic locking "schwerfällig" sein? Man würde es doch praktisch nie bemerken, wenn es ohnehin fast nie
zu einem Konflikt kommt. Auch hier lässt sich eine Parallele zu anderen Bereichen ziehen, in denen es um Sicherheit geht: Man hofft immer (optimistisch) dass die betr. Probleme selten auftreten, aber wenn es doch einmal zu einem Problem kommt, sollte eine möglichst sichere Problemlösungsstrategie vorhanden sein.
So sollten z.B. in Gebäuden Feuerlöscher von ausreichender Größe vorhanden sein, selbst wenn etwa deren Transport als schwerfällig empfunden wird. Das stört im Alltag niemanden bzw. niemand bemerkt es, weil sie sowieso nicht zum Einsatz kommen. Falls sie allerdings ausnahmsweise doch einmal benötigt werden, so wird man froh sein, eine Problemlösungsmöglichkeit zur Verfügung zu haben, die eine angemessene Sicherheit bietet.

[...] zur Sicherheit werden wir aber in einer späteren Version das Konflikthandling auch im User Interface anbieten.

Das ist aus unserer Sicht die Mindestanforderung für die Benutzung der Team-Version, die wir vor einiger Zeit gekauft, und bis heute auf Grund verschiedener Probleme noch keinen Tag produktiv eingesetzt haben.

Können Sie jetzt schon sagen, wann eine Citavi-Team-Version mit einer "Änderungskonflikt"-Warnung im User Interface verfügbar sein wird?

Die Kernaussagen dieses Topics sollten im Handbuch beim Stichwort Konfliktmanagement genannt werden. Nicht alle Nutzer/Verwalter von Citavi-Installationen sind so sehr firm in Datenbanktheorie...

Ja, ich meine wenn man zur Team-Version wechselt, drängt sich doch die Frage auf, was im Falle eines Konfliktes passiert. Ich habe im Handbuch in Kapitel 14 "Im Team arbeiten" keine Angaben dazu gefunden, und auch nicht in den FAQ. Erst im Kapitel 17 "Technische Informationen" fand ich die Angaben, die ich im ersten Beitrag dieses Threads erwähnt habe. Mindestens die grundsätzliche Verfahrensweise, die im Konfliktfall angewendet wird, nämlich "Der letzte gewinnt, und niemand wird informiert." sollte aber m.E. im Kapitel 14 "Im Team arbeiten" genannt werden.

Mit freundlichen Grüßen, J. Lüthje

[TobiasH]

Guten Abend!

Dass Citavi so rigoros mit überschriebenen Änderungen vorgeht, überrascht auch mich. Hier mein Vorschlag, so wie ich mir die Team-Funktion im Ideal-Fall vorstelle: Eigentlich kann man das ganz gut mit der Änderungsfunktion von Microsoft Word vergleichen. Ein Benutzer verändert etwas an der Datei und ein anderer überprüft, ob er die Änderungen annehmen will oder nicht. Dabei könnte man auch die verschiedenen Rollen der Mitglieder, die ja bereits existieren, aufnehmen. Nur der Projektmanager darf die Änderungen akzeptieren, die Authoren dürfen nur vorschlagen.

Grüße, TobiasH

[Thomas Schempp]

Liebe Mitdiskutanten

Bevor ich zum inhaltlichen Teil komme, möchte ich nochmals einige technische Details zum Thema Pessimistic Locking erläutern, die zum Verständnis beitragen können.

Pessimistic Locking hat nichts mit Sicherheit zu tun. Pessimistic und Optimistic Locking sind beide gleich sicher, solange Datenkonflikte erkannt werden (darum dreht sich ja die Diskussion ursprünglich).

Abgesehen davon, dass ich Pessimistic Locking ganz einfach für eine überholte Technik halte, gibt es bei Citavi auch handfeste technische Gründe. Pessimistic Locking setzt voraus, dass:

• Das Datenbankschema nur wenige Entitäten hat (denn je mehr Entitäten, desto höher ist aufgrund der wechselseitigen Abhängigkeiten die Wahrscheinlichkeit, dass auch dann gesperrt wird, wenn es gar nicht nötig wäre).
  Das ist bei Citavi nicht erfüllt, es gibt viele Entitäten und Wechselwirkungen.
• Wenige Anwender gleichzeitig mit dem System arbeiten.
  Das ist bei Citavi unter Umständen nicht gegeben.
• Datensätze sehr schnell gesperrt werden können.
  Das ist bei Citavi ebenfalls nicht gegeben. Da Citavi nicht mit einem dedizierten Server arbeitet, sondern mit einer einfachen Datenbank-Datei auf einem Netzlaufwerk, kann die Sperrung bei einer langsamen Datenverbindung (z.B. VPN) durchaus eine Sekunde dauern.
  (Randbemerkung: Weshalb arbeitet Citavi nicht mit einem dedizierten Server? Es braucht dafür einen Host-Computer, auf dem der Server ständig läuft; man muss die Ports konfigurieren, auf denen der Server kommunizieren darf; man muss dazu in der Regel die Firewall des Host-Computers anpassen; dazu wiederum muss man sich häufig mit den IT-Sicherheitsverantwortlichen abstimmen – und so weiter, und so fort. Solche Konfigurationsorgien würden die grosse Mehrheit unserer Anwender überfordern.)

Es gibt also viele Gründe, weshalb nur Optimistic locking in Frage kommt.

Nun ist das Konfliktmanagement beim Optimistic locking nicht gerade trivial. Ich illustriere das an einigen Beispielen:

• Es herrscht sicher Konsens, dass gleichzeitig veränderte bibliographische Angaben einen Konflikt erzeugen müssen.
• Das gleiche gilt natürlich für einen Zitat-Text, der gleichzeitig verändert wird.
• Wie verhält es sich, wenn ein User die bibliographischen Angaben ändert, der andere den Abstract? Wenn wir nicht von Powerusern, sondern von Alltags-Anwendern sprechen, würden die eine diesbezügliche Konfliktmeldung verstehen?
• Wie verhält es sich, wenn zwei User gleichzeitig die Schlagwörter ändern? Soll Citavi die Schlagwörter hier ganz einfach kombinieren, um den User weniger mit komplizierten Dialogen zu belästigen? Oder wäre das inhaltlich problematisch?
• Wie verhält es sich, wenn ein User die Reihenfolge der Zitate innerhalb einer Kategorie ändert, während der andere ein Zitat zu dieser Kategorie hinzufügt? Aus Sicht der Datenbank ergibt das einen Konflikt - wäre das aus Sicht des Alltagsbenutzers verständlich?

Das sagt nicht unbedingt viel aus, denn Citavi-Team gibt es noch nicht lange.

Es ist richtig, dass Citavi Team noch nicht lange auf dem Markt ist. Aber ich habe die gleiche Erfahrung seit 1993 mit verschiedenen Datenbank-Systemen in verschiedenen Grössen gemacht. Ich habe bei gleichzeitigem Betrieb in 18 Jahren nicht einen realen Fall von Datenkonflikten erlebt bzw. mitgeteilt bekommen, weder bei Standardsystemen wie Exchange Server noch bei Datenbank-Systemen, die ich früher für Kunden entwickelt habe.
(Die Sache sieht völlig anders aus, wenn offline gearbeitet wird, eine Änderung also erst nach Stunden oder Tagen zurückgespielt wird. Hier kommt es häufig zu Konflikten. Aus diesem Grund unterstützt Citavi zwar Offline-Arbeit, aber nur im schreibgeschützten Modus.)

Die Kombination von hoher Komplexität einerseits sowie erfahrungsgemäss sehr kleiner Wahrscheinlichkeit andererseits hat uns dazu bewogen, das automatische Konflikthandling zu implementieren, das Citavi heute hat.

Dies bedeutet aber - wie bereits gesagt - nicht, dass wir hier keine Verbesserungen planen.

Mit freundlichem Gruss,
Thomas Schempp

[J. Lüthje]

Sehr geehrter Herr Schempp,

ich danke für Ihre erneuten ausführlichen Informationen, und bitte um Entschuldigung für die späte Antwort -- meine Zeit ist im Moment leider knapp.

• Wie verhält es sich, wenn ein User die bibliographischen Angaben ändert, der andere den Abstract? Wenn wir nicht von Powerusern, sondern von Alltags-Anwendern sprechen, würden die eine diesbezügliche Konfliktmeldung verstehen?
• Wie verhält es sich, wenn zwei User gleichzeitig die Schlagwörter ändern? Soll Citavi die Schlagwörter hier ganz einfach kombinieren, um den User weniger mit komplizierten Dialogen zu belästigen? Oder wäre das inhaltlich problematisch?
• Wie verhält es sich, wenn ein User die Reihenfolge der Zitate innerhalb einer Kategorie ändert, während der andere ein Zitat zu dieser Kategorie hinzufügt? Aus Sicht der Datenbank ergibt das einen Konflikt - wäre das aus Sicht des Alltagsbenutzers verständlich?

Ob soetwas für Alltagsbenutzer verständlich ist, hängt m.E. im Wesentlichen davon ab, wie die Probleme dargeboten werden -- ob Citavi also aussagekräftige, gut verständliche Meldungen zeigt, und die betr. Dialogfenster jeweils angemessene Aktionsmöglichkeiten anbieten.
Von Programmen einer großen, sehr bekannten Softwarefirma bekommt man ja Hinweise zu lesen wie: "Um Hilfe zu erhalten, klicken Sie auf 'Hilfe'." oder "Die Tastatur wurde nicht gefunden. Bitte drücken Sie F1 um fortzufahren.".
Was die Benutzerunterstützung betrifft, befindet sich Citavi im Vergleich zu obigen Beispielen ziemlich genau am anderen Ende des Qualitätsspektrums. Von daher bin ich zuversichtlich, dass die Usability-Fachleute bei Ihnen einen guten Weg finden werden, diese Dinge auch den Alltagsbenutzern zu vermitteln. Und fast jede andere Lösung wird besser sein als die jetzige, in der die Daten aller am Änderungskonflikt beteiligten Benutzer (bis auf diejenigen des letzten) stillschweigend verloren gehen.

Es ist richtig, dass Citavi Team noch nicht lange auf dem Markt ist. Aber ich habe die gleiche Erfahrung seit 1993 mit verschiedenen Datenbank-Systemen in verschiedenen Grössen gemacht. Ich habe bei gleichzeitigem Betrieb in 18 Jahren nicht einen realen Fall von Datenkonflikten erlebt bzw. mitgeteilt bekommen, weder bei Standardsystemen wie Exchange Server noch bei Datenbank-Systemen, die ich früher für Kunden entwickelt habe.

Die Wahrscheinlichkeit eines Konfliktes hängt natürlich sehr von der Art der Datenbank und den Bedingungen ab, unter denen sie benutzt wird. Voraussetzung dafür, dass man von einem Konflikt überhaupt erfährt, ist zunächst einmal, dass das betreffende Datenbankprogramm einen solchen meldet. Und wenn man z.B. an eine Adressdatenbank einer großen Firma mit z.B. 20000 Mitarbeitern denkt, auf die nur wenige Personalsachbearbeiter Zugriff haben, so ist diese kaum mit einer Citavi-Literaturdatenbank mit z.B. 2000 Titeln vergleichbar, auf die mehrere Mitarbeiter gleichzeitig zugreifen.

Diverse Tests, in denen ich mit einem Simulationsprogramm den gleichzeitigen Zugriff mehrerer Benutzer auf eine Datenbank durchspielt habe, haben ergeben, dass die Wahrscheinlichkeit eines Änderungskonflikts in einer Citavi-Datenbank (mit 12 Entitäten pro Titel, wie von Herrn Schweiger dargestellt) für unsere Arbeitssituation zwar "relativ klein", aber keinesfalls vernachlässigbar ist. Sie ist z.B. deutlich größer als die Wahrscheinlichkeit, dass es sich bei einer Schwangerschaft (in Deutschland) um Drillinge handelt -- um nur mal eine andere Wahrscheinlichkeitsgrößenordnung zum groben Vergleich zu nennen.

Dabei muss man auch bedenken, dass die Zugriffe auf die Titel in einer Citavi-Datenbank oft nicht gleichwahrscheinlich sind, sondern "projektorientiert" erfolgen. Selbst wenn also in der Datenbank tausende von Titeln erfasst sind, so kann es oft vorkommen, dass sich die Zugriffe innerhalb eines bestimmten Zeitraumes auf diejenigen z.B. 50-100 Titel konzentrieren, die für das aktuelle Projekt relevant sind. Dadurch erhöht sich das Risiko eines Konflikts beträchtlich.

Ich möchte deshalb noch einmal fragen, wann eine Citavi-Team-Version mit einer "Änderungskonflikt"- Benachrichtigung im User Interface verfügbar sein wird.

Einen schönen 3. Advent wünscht
Jürgen Lüthje

[Thomas Schempp]

Guten Abend, Herr Lüthje

Vielen Dank für Ihre Ausführungen und auch für freundlichen Worte.

Ich möchte deshalb noch einmal fragen, wann eine Citavi-Team-Version mit einer "Änderungskonflikt"- Benachrichtigung im User Interface verfügbar sein wird.

Ich kann auf Ihre Frage leider keine einfache und klare Antwort geben, weil wir schon einige Mal Termine in Aussicht gestellt haben, die zu optimistisch kalkuliert waren. Wir haben deshalb entschieden, prinzipiell keine Termine mehr bekannt zu geben. Für den Moment nur so viel: Wir arbeiten an diesem Thema und wir werden eine Lösung finden.

Mit freundlichem Gruss,
Thomas Schempp

[maxds]

Hallo Herr Schempp,

gibt es mittlerweile Neuigkeiten zu diesem Thema?
Ich sehe nämlich ähnliche Probleme wie Herr Lütje und im Grunde kaum Vorteile der Teamversion gegenüber der normalen Version. Diese hat immerhin den Vorteil, dass die Datenbankdatei gesperrt ist, wenn ein anderer daran arbeitet. Gerade in Teamprojekten mit wenigen Mitarbeitern ist das meiner Meinung nach momentan die bessere Lösung als einen Datenverlust zu riskieren (der bei wenigen Titeln aber intensiver Arbeit an den Titel deutlich erhöht ist).

Ich würde mich freuen, wenn demnächst das Konfliktmanagement geändert wird und Konflikte direkt angezeigt werden.

Ein schönes Wochenende wünsche ich!