WARNUNG vor Funktion in Webtrees!

php-gedview-l
1

Hallo zusammen,

gestern habe ich in der Verwaltung den Programmpunkt "Stammb�ume
zusammenf�hren" getestet. Anstatt, wie von mir erwartet, wurde der
Zielstammbaum nicht mit den gew�nschten Daten eines anderen Stammbaums
erweitert.

Was folgte, w�re beinahe die ultimative Katastrophe geworden, wenn ich
kein Backup gehabt h�tte.

Der Ablauf war wie folgt:

- Quelle und Ziel ausgew�hlt
- gestartet

Jetzt folgte ein Hinweis, dass in den beiden Stammb�umen Datens�tze
enthalten sind, die den selben XREF verwenden. Es wurde angeboten, in
einem der Stammb�ume die Datens�tze neu zu numerieren, um kein Chaos
zu erzeugen.

Das habe ich getan und dann den Kopiervorgang gestartet. Das Ergebnis
war, dass im Zielstammbaum nicht die Datens�tze angeh�ngt wurden,
sondern alle Datens�tze im Ziel wurden gel�st und die Daten aus dem
Quellstammbaum dort hin kopiert, so dass nun zwei identische
Stammb�ume existierten.

Alle anderen Daten waren weg! Meine Arbeit von 15 Jahren w�re fast
verloren gegangen bei dem Versuch, 50 Personen hinzuzuf�gen.

Harald TOBIAS

2

Hi,

guter Hinweis. Ich hab's mir angewöhnt sowas immer einzutippen. Neulich habe ich mir mal kurz überlegt die Funktion zu testen, was aber dann wohl richtig war, es nicht zu tun.

Thema Datensicherung: ich habe mir angewöhnt jeden 1. im Monat alles zu sichern. Und ich rate allen, sich auch um das Thema Sicherung zu kümmern, egal welche Software man nutzt.

Schönen Gruß
Thomas (Weiland)

3

Hallo Harald (u.a.),

ich habe auch gerade mit der "Stammbäume zusammenführen"-Funktion
experimentiert (sicherheitshalber in einer Parallel-Installation in einer
virtuellen Maschine :-), aber ich kann die negativen Erfahrungen nicht
bestätigen: Sie tut m.E. genau das, was sie verspricht.

Im Grunde ist die Hauptaufgabe des Scripts ja, zu verhindern, dass mehrere
Datensätze mit identischen IDs im selben "Stammbaum" landen. Sobald man
"Kopiere alle Datensätze von <import.ged> nach <basic.ged>" startet, werden
wohl die IDs aller Individuen, Familien, Quellen, Notizen etc.pp. aus
<import.ged> darauf geprüft, ob sie in <basic.ged> schon vorhanden sind (ich
hatte bisher nur die 4 genannten Datentypen, nehme aber an, dass auch Medien,
Archive usw. gecheckt werden).

Falls solche schon vorhandenen Identifier gefunden werden, wird der
Kopiervorgang nicht ausgeführt, sondern die beschriebene Fehlermeldung
ausgegeben und angeboten, die Import-Datei umzunummerieren. Das tut die
Funktion dann auch - und zwar gründlich (selbst wenn die 'Inhalte' der gleich
nummerierten Datensätze tatsächlich völlig identisch sind: Man kann sich die
Hoffnung also abschminken, dass sie Doubletten aussortiert...).

Falls die Import-Datei zu groß ist + das Script wegen Zeitüberschreitung
abbricht, muss man den Vorgang so oft neu starten, bis eine Erfolgsmeldung des
Inhalts kommt, dass es keine ID-Konflikte mehr gibt (den genauen Wortlaut weiß
ich gerade nicht mehr).

Aber ACHTUNG: Man muss diesen Vorgang unter "Stammbäume zusammenführen"
starten! - NICHT ETWA zu "Stammbäume" gehen + dort einen "Import" anstoßen,
denn DIESE "Import"-Funktion bedeutet in der Tat: "Überschreibe die Daten, die
<basic.ged> entsprechen, mit denen aus <import.ged>".

// Meine Tests mit: WT 1.6.2 / verwende GEDCOM ID (nicht RIN#) / erstelle
global einmalige ID-Nummern: ja. //

Beste Grüße
Claus-Volker (Klenke)

4

Hallo Claus-Volker,

das ist allerdings merkw�rdig. Ich sehe gerade, dass Du mit 1.6.2
gearbeitet hast, meine Installation ist noch 1.6.1

Bevor ich das n�chste mal auf ein Backup zur�ckgreifen muss, teste ich
das auch zuerst in einer VM. Das wird mir sicherlich weniger Adrenalin
bescheren! :wink:

Harald TOBIAS

5

Hallo Harald,

ich mag's nicht recht glauben, dass es an der Version liegt - aber man weiß ja
nie...

Allerdings fällt mir gerade noch ein, dass ich die <import.ged> zuerst in einen
neuen "Stammbaum" importiert habe - eigentlich, um zu checken, ob das
Desktop-Programm eine gültige GEDCOM erzeugt hat. Hatte es, und so habe ich
letztlich zwei auf dem Server vorhandene "Stammbäume" (eben nicht bloß
"GEDCOMs") zusammen geführt; das habe ich inzwischen mehrmals gemacht - immer
erfolgreich, aber auch immer in dieser Reihenfolge. Könnte es daran liegen?

Wenn es so wäre, dass der Versuch, eine auf dem Server liegende GEDCOM mit
einem im WT-System erfassten Stammbaum "zusammen zu führen", das 'andere'
Import-Script aufruft (das "Überschreib-mich"-Script), wäre das übrigens eine
böse Falle für die Anwender...

(Wenn ich Zeit habe, probier' ich's mal.)

Gruß, Claus-Volker

6

Hallo Harald,

vielen Dank f�r den Hinweis, da� es niemand wagen sollte, neue, unbekannte Funktionen eines Programms gleich mit eigenen, wertvollen Daten auszuf�hren.
Jeder hat schon einmal viel Arbeit auf �hnliche Weise verloren. Das mu� nicht sein.

Es sollte sich jeder zu Herzen nehmen, solche Dienstleistung zun�chst mit Dummy-Daten zu testen, die dem Datenbestand �hnlich sind, das Ergebnis zu testen und dann dar�ber in dieser Runde berichten.

Vergessen wir eines nicht: Wir alle nutzen eine Software, die von Idealisten zur kostenlosen Nutzung bereitgestellt und weiterentwickelt wird.
Etwas Wichtiges, was wir beitragen k�nnen, ist es den Entwicklern R�ckmeldung �ber die Funktionalit�t zu geben.