Neu Kategorienamen zwischen 2 Wawis synchronisieren ??

[ple]

Hallo zusammen,
ich bräuchte mal ein wenig Schwarmwissen, da ich aktuell irgendwie in ner Sackgasse stecke.
Ich habe 2 Wawis, die jeweils die gleichen Kategorien haben sollen.
Ein Export Wawi A > Import in Wawi B klappt soweit.
Jetzt haben wir 7000 Kategorien in Wawi A, die auch in Wawi B sind. Kommt eine Kategorie hinzu bei Wawi A, muss diese auch in Wawi B landen. Das klappt soweit auch, wenn Wawi B einen Dummyartikel importiert mit der neuen Kategorie.

So, jetzt kommt es aber mal vor, dass sich eine Kategorie sich vom Namen ändert in Wawi A. Die gibt es logischerweise auch schon in Wawi B und da muss diese auch geändert werden.
Händisch soweit kein Problem, aber wie automatisch?
Meine Überlegungen waren bisher:
- SQL Update / Über den kKategorie kann ich leider nicht gehen, weil es nicht die selben sind.
- SQL Update / Über cName der Kategorie den alten Namen suchen und ein update geht auch nicht, weil die vom Namen her öfters vorkommen können aber unterschiedliche Oberkats haben. Dann müsste ich den kompletten Pfad matchen und dann ein Update durchführen für cName.
- Für Artikel gibt es "Eigene ID", die wären wünschenswert für Kategorien, aber gibt es nicht. Damit könnte ich einen PK pflegen.
- eigenes Feld mit einem Int und selber einen internen Schlüssel pflegen, denke das würde gehen, darüber könnte ich den cName matchen und ein Update machen.

Hat vielleicht noch einer eine Idee, wie man sowas realisieren könnte?

Gruß und Besten Dank.

 

[frankell]

Dann müsste ich den kompletten Pfad matchen und dann ein Update durchführen für cName.
...
eigenes Feld mit einem Int und selber einen internen Schlüssel pflegen, denke das würde gehen, darüber könnte ich den cName matchen und ein Update machen.

Hallo @ple,

das sind auch die Möglichkeiten, die mir dazu einfallen würden, ggf. auch eine Kombination von Eigenem Feld und Komplettem Pfad, ergänzend zu dem "eigenen Schlüssel" als Eigenes Feld. Den kompletten Pfad zu haben, erleichtert das Aufspüren von Fehlern, wenn bei den Abgleichen mal iwas nicht funktioniert. Denn der komplette Pfad bezieht sich immer nur auf den jeweiligen Mandaten, bleibt also bei Abgleichen unangetastet, während der eigene Schlüssel über beide Mandanten synchron gehalten werden muss.

 

[John]

Ich würde mit einem extra Tool in beiden Wawi den Kategoriebaum komplett durchlaufen und vergleichen. Das ist das Einzige, was wirklich sicher ist.

 

[ple]

Schon mal besten Dank für die Unterstützung.
also einen eigenen Primärschlüssel über eigene Felder wäre eine Idee, aber auch gefährlich, da Wawi B den ja einfach ändern kann und dann wäre alles für die Katz.
Also doch den kompletten Pfad nehmen, dazu bräuchte man halt den alten Pfad vor der Änderung und das Update.
Den Namen dann per SQL ändern.

Was mir gerade so einfällt, ich könnte mehrere Ausgabewege des Kategorienamens nutzen und jeweils einen int mit Trennzeichen vor der Kategorie schreiben. Wawi B darf halt keine neuen Kats anlegen, die müssen von Wawi A kommen.
Mh, wäre aber das gleiche wie mit eigenen Feldern. ich weiß gar nicht ob es Rechte für die Kategorien gibt, dass man den normalen User verbieten kann an den Kategorien rumzuschrauben.

@John
Ein Extra Tool, sicherlich möglich, aber aktuell leider nicht machbar. Das Tool müsste noch um ein paar Dinge mehr aufgebohrt werden, aber das wird noch dauern bis ich mal ein Lastenheft zusammengeschrieben habe.
aktuell läuft halt alles noch per Powershell.

Gruß und Danke

 

[frankell]

Schon mal besten Dank für die Unterstützung.
also einen eigenen Primärschlüssel über eigene Felder wäre eine Idee, aber auch gefährlich, da Wawi B den ja einfach ändern kann und dann wäre alles für die Katz.
Also doch den kompletten Pfad nehmen, dazu bräuchte man halt den alten Pfad vor der Änderung und das Update.
Den Namen dann per SQL ändern.

Was mir gerade so einfällt, ich könnte mehrere Ausgabewege des Kategorienamens nutzen und jeweils einen int mit Trennzeichen vor der Kategorie schreiben. Wawi B darf halt keine neuen Kats anlegen, die müssen von Wawi A kommen.
Mh, wäre aber das gleiche wie mit eigenen Feldern. ich weiß gar nicht ob es Rechte für die Kategorien gibt, dass man den normalen User verbieten kann an den Kategorien rumzuschrauben.

@John
Ein Extra Tool, sicherlich möglich, aber aktuell leider nicht machbar. Das Tool müsste noch um ein paar Dinge mehr aufgebohrt werden, aber das wird noch dauern bis ich mal ein Lastenheft zusammengeschrieben habe.
aktuell läuft halt alles noch per Powershell.

Gruß und Danke

Du kannst "Kategorien und Artikel verwalten" für die User als Recht deaktivieren.

Alternativ kannst Du auch einen Datenbank-Trigger für die Änderung eines Eigenen Feldes setzen, der Änderungen nicht oder nur unter bestimmten Bedingungen zulässt, bspw. nur durch bestimmte Stored Procedures, die den Abgleich der Kategoriestruktur vornehmen.

Dann könntest Du sowohl ein Eigenes Feld für den eigenen Schlüssel als auch für den Pfad haben und ggf. eine Hilfstabelle führen, in der alt und neu aufgeführt sind und dann nach der Spalte neu aktualisiert.

 

[ple]

Bleiben denn eigene Triggers in den originalen Tabellen von JTL nach einem Update bestehen? oder werden die gelöscht.
Wenn die bestehen bleiben und nicht gelöscht werden, könnte man ja einiges machen. Ich könnte mir dann eine eigene SQL Datenbank machen und dort die Änderungen pflegen. Wäre sicherlich auch für andere Sachen interessant.

Gruß und Danke.

 

[mh1]

Bleiben denn eigene Triggers in den originalen Tabellen von JTL nach einem Update bestehen? oder werden die gelöscht.

Das kommt ja drauf an, was das Update mit der bestehenden Datenbankstruktur macht
Im Normalfall werden ja eher neue Relationen hinzugefügt, oder bestehende geändert (also z.b. CREATE TABLE oder ALTER TABLE...)
Falls mal ein Update Skript die Tabelle bzw. die Felder mit deinem Trigger anpackt und in einen Fehler läuft, erkennst du das ja dann an der Fehlermeldung und kannst entsprechend reagieren.

 

[frankell]

Bleiben denn eigene Triggers in den originalen Tabellen von JTL nach einem Update bestehen? oder werden die gelöscht.
Wenn die bestehen bleiben und nicht gelöscht werden, könnte man ja einiges machen. Ich könnte mir dann eine eigene SQL Datenbank machen und dort die Änderungen pflegen. Wäre sicherlich auch für andere Sachen interessant.

Gruß und Danke.

Ich habe es noch nie erlebt und halte es für ausgeschlossen, dass eigene Trigger und SPs bei einem Update gelöscht werden. Denn das muss entweder gezielt passieren oder aber komplett pauschal, indem der gesamte Datenbankinhalt bspw. in eine neue Struktur überführt wird und dabei alles, was nicht von JTL kommt, nicht überführt wird.

Etwas anderes ist natürlich eine Änderung der DB-Struktur, wie @ple schrieb, in den Teilen, die Dein Trigger anfasst (hier alles rund um Kategorieattribute), insoweit dabei ein UPDATE geschieht, bspw. die Ergänzung einer neuen Spalte mit Befüllen dieser Spalte. INSERT und DELETE sollten dagegen nach meinem Verständnis kein Problem darstellen, da Dein Trigger nur das händische UPDATE aus der Wawi heraus unterbinden soll. Ob so etwas bei einem Update der Wawi passieren wird, kannst Du bspw. über https://wawi-db.jtl-software.de/ vorher checken.