- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Labels:
-
Developers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
รber Projekt-Ex/Import geht keine Historie verloren.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Walter,
danke, ich bin dabei es zu testen.
Gruss
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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