Questions & Answers

kraemer
I'm new here

Datenquelle leeren

Hallo,

wir haben in einem Projekt eine Datenquelle, in der sehr viele Datensรคtze (>100k) importiert wurden. Die wรผrde ich jetzt gerne los, zumal sie auch das System nicht unbedingt schneller machen. Gibt es eine Mรถglichkeit die Daten wirklich zu lรถschen, im im Work- und Release-State?

Ich weiss schon wie ich sie per Skript รผber Content2 lรถschen kann, aber am liebsten wรคre mir wirklich auch die History loszuwerden. Dafรผr suche ich einen Weg und wรคre รผber Hinweise dankbar.

Grรผsse

Michael

0 Kudos
12 Replies
broszeit
I'm new here

Hallo,

haben diese Datensรคtze Fremdschlรผsselbeziehungen? Wenn nein, dann kรถnnen sie am einfachsten direkt aus der Datenbank gelรถscht werden. Dies geschieht natรผrlich auf eigene Gefahr und sollte mit grรถรŸter Vorsicht gemacht werden.

Alternativ kann man im Projekt die Datensรคtze zuerst per Skript รผber Content2 lรถschen und das Projekt dann exportieren. Beim Export kann man auswรคhlen, dass man nur neuere Revisionen als das Lรถschdatum exportieren mรถchte. Nach dem erneuten Importieren des Projekts sind die gelรถschten Datensรคtze nicht mehr vorhanden. Es werden hierbei aber auch alle anderen alten Revisionen entfernt, deshalb sollte รผberlegt werden ob das in Kauf genommen werden kann.

Als dritter Ansatz kรถnnte noch รผberlegt werden, ob die Projektarchivierung (evtl. auch EnterpriseBackup Funktionalitรคt) hierfรผr genutzt werden kann, ohne das wirklich wichtige Informationen verloren gehen.

Viele GrรผรŸe

Rouven

0 Kudos

Hallo Rouven,

vielen Dank fรผr die Info. Die Datensรคtze haben Fremdschlรผsselbeziehungen, allerdings ist die Tabelle die ich lรถschen mรถchte (price) die N-Seite der 1:N Beziehung (zur Tabelle product). In einer normalen relationalen DB wรคren die FKs also sowieso in der Tabelle die ich lรถschen mรถchte. Ich weiss allerdings nicht, wie FirstSpirit die Daten in der SQL ablegt.

Gibt es eine Doku darรผber, wie die Datenquellen in SQL persistiert werden, so dass ich sehe was ich ggf. beachten muss? Mich wรผrde vor allem interessieren was mit ForeignKeys und der History passiert.

Den Projektexport / -import mรถchte ich gern vermeiden, ich mรถchte nicht die History von allem verlieren.

Gibt es dazu noch ein paar Informationen?

Grรผsse

Michael

0 Kudos

รœber Projekt-Ex/Import geht keine Historie verloren.

Peter
0 Kudos

Peter Jodeleit schrieb:

รœber Projekt-Ex/Import geht keine Historie verloren.

So wie in diesem Kontext hier besprochen geht sie verloren. Wie auch immer, ich hoffe es gibt noch ein paar Infos zu dem SQL-Thema wie oben geschrieben.

0 Kudos

Ich bezog mich auf diese Aussage von dir:

Den Projektexport / -import mรถchte ich gern vermeiden, ich mรถchte nicht die History von allem verlieren.
Peter
0 Kudos
klein
Crownpeak employee

Hi Michael,

>allerdings ist die Tabelle die ich lรถschen mรถchte (price) die N-Seite der 1:N Beziehung (zur Tabelle product).

d.h. ein Produkt hat mehrere Preise?

>In einer normalen relationalen DB wรคren die FKs also sowieso in der Tabelle die ich lรถschen mรถchte

richtig, auch in FS existiert in diesem Fall eine FK-Spalte in der Tabelle "price", die auf die PK der Tabelle "product" verweist und die in Deinem Fall so heiรŸen mรผsste "<FKTAB>_fs_id".

D.h. wenn Du nun alle Werte in der Tabelle "price" lรถschst, werden in der entsprechenden Komponetente in der Tabelle "product" leere Werte angezeigt Smiley Sad

Also sollst Du nicht alles lรถschen, sondern nur die historischen Datensรคtze. Das kann man รผber ein Delete-Statement direkt in der DB tun. Dies ist jedoch kein offizieller Weg und die Durchfรผhrung eines manuellen DB-Eingriffs erfolgt daher auf eigene Gefahr!

Ein solches DB-Statement sieht wie folgt aus:

DELETE FROM <DB_NAME>.<TABLE_NAME> t0 where t0.fs_release_to<9223372036854775807 and t0.fs_valid_to<9223372036854775807

Desweiteren kannst auch die Datensรคtze lรถschen, die zwar aktuell sind (also keine histotische Datensรคtze), aber die in der Tabelle "product" nicht referenziert werden.

DELETE FROM <DB_NAME>.<TABLE_NAME> t0 where t0.<FKTAB>_fs_id=null

EntschlieรŸt man sich, diesen Weg zu wรคhlen, dann sollte man vorher sicherheitshalber ein DB-Backup durchfรผhren.

GruรŸ,

Walter.

0 Kudos

Hallo Walter,

danke, ich bin dabei es zu testen.

Gruss

Michael

0 Kudos

Ich habe das Lรถschen getestet, aber gestern hat mir der Client im Anschluss OR-Fehler angezeigt, daher gehe ich nochmal im Detail auf deine Antworten ein.

klein schrieb:

d.h. ein Produkt hat mehrere Preise?

ja

klein schrieb:

richtig, auch in FS existiert in diesem Fall eine FK-Spalte in der Tabelle "price", die auf die PK der Tabelle "product" verweist und die in Deinem Fall so heiรŸen mรผsste "<FKTAB>_fs_id".

D.h. wenn Du nun alle Werte in der Tabelle "price" lรถschst, werden in der entsprechenden Komponetente in der Tabelle "product" leere Werte angezeigt Smiley Sad

Was meinst du denn mit leeren Werten? Da die Spalte mit dem FK in der Tabelle price steht, mรผssten doch einfach die Produkte noch da sein, aber dรผrften keine Preise mehr haben. Oder?

klein schrieb:

Ein solches DB-Statement sieht wie folgt aus:

DELETE FROM <DB_NAME>.<TABLE_NAME> t0 where t0.fs_release_to<9223372036854775807 and t0.fs_valid_to<9223372036854775807

Die 9223372036854775807 ist eine Konstante? Oder welches Time-Format ist das?

Da ich die Daten alle nicht mehr brauche und komplett neu importieren werde, kรถnnte ich auch initial per Script via FS die Datensรคtze im Arbeits- und Freigabestand einmal komplett lรถschen, damit wรคre die Datenquelle aus Sicht des Clients leer. Wรคre das ein einfacher (und tendenziell zuverlรคssiger) Weg, um danach per SQL die Tabelle zu putzen?

Und noch eine generelle Frage: Sollte ich nach einer DB-ร„nderung den Server (und die Clients?) neu starten, oder den Server sowieso runterfahren vorher?

Grรผsse

Michael

0 Kudos

Hallo Michael,

hast du fรผr dein Problem schon ein Lรถsung gefunden?

Ja bei 9223372036854775807 handelt es sich um einen interne Konstante.

Viele GrรผรŸe

Thorsten

0 Kudos

Type a product name