Hallo,
bei mir geht die Kapazität der DB dem Ende zu. Ich scanne eine ganze Kategorie. Jetzt würde ich gerne eine neue DB anlegen. Hat jemand eine Idee, wie ich das anstelle, wenn BW jetzt "zum ersten" mal die Kategorie einliest, daß nicht auch die Artikel genommen werden, welche auch in der ersten vorhanden sind.
Datenbank voll - V3
Ich gehe davon aus, dass Du es so meinst:
es sind z.B. 5000 Artikel in der Kategorie, wobei alle entweder in der alten oder in der neuen Datenbank enthalten sein sollen, aber nicht in beiden.
In diesem Fall würde ich folgendermaßen vorgehen:
es sind z.B. 5000 Artikel in der Kategorie, wobei alle entweder in der alten oder in der neuen Datenbank enthalten sein sollen, aber nicht in beiden.
In diesem Fall würde ich folgendermaßen vorgehen:
- einen Stichtag mit Uhrzeit festlegen, z.B. 01.07.2005 00:00 Uhr (Ende oder Beginn ist ja egal)
- in der alten Datenbank alle Artikel nach diesem Stichtag löschen
- neue Datenbank aktivieren
- Onlinesuche durchführen
- alle Artikel vor dem Stichtag in den Ordner "Ignorieren" verfrachten
- die Option "Allgemein"-"Beendete ignorierte Artikel bei Programmende löschen" aktivieren
"ABAP is neither cool nor sexy." - Horst Keller
Hallo Mash,
ganz so einfach ist es nicht wenn die Daten halbwegs vollständig sein & wirklich korrekt getrennt werden sollen. Wenn der Stichtag nämlich in der Zukunft liegt und Du die Trennung jetzt (!) durchführst (siehe Beitragsdatum), dann fehlen in der alten Datenbank Artikel von jetzt bis Stichtag und in der neuen sind sie auch nicht da (wegen Löschen/Ignorieren). Es müßte also mit beiden Datenbanken für eine gewisse Zeit parallel der Favoritenabgleich (neue Artikel hinzufügen) durchgeführt werden und wenn der Stichtag vorbei ist führt man die Löschaktionen aus. Aber das kann man sich sparen:
Hat man Access legt man sich einen Stichtag vor dem letzten Abgleich (also neue Artikel hinzufügen) fest und teilt die Datenbank entsprechend auf (also Kopie der *.db4 anlegen, in der einen vor Stichsekunde (neue Datenbank) und in der anderen nach oder gleich Stichsekunde (alte Datenbank) löschen) - fertig. Ohne Access geht es natürlich auch, aber mit ist es aus meiner Sicht sicherer & eindeutiger (als das irgendwelche Datensätze, die mit der Suche nicht erfasst werden, durch die Lappen gehen und dann doppelt vorhanden sind).
Wichtig: Ich bin zum einfacherern Verständnis vom Startdatum der Auktionen ausgegangen, beim Enddatum wird's komplizierter.
Sven
ganz so einfach ist es nicht wenn die Daten halbwegs vollständig sein & wirklich korrekt getrennt werden sollen. Wenn der Stichtag nämlich in der Zukunft liegt und Du die Trennung jetzt (!) durchführst (siehe Beitragsdatum), dann fehlen in der alten Datenbank Artikel von jetzt bis Stichtag und in der neuen sind sie auch nicht da (wegen Löschen/Ignorieren). Es müßte also mit beiden Datenbanken für eine gewisse Zeit parallel der Favoritenabgleich (neue Artikel hinzufügen) durchgeführt werden und wenn der Stichtag vorbei ist führt man die Löschaktionen aus. Aber das kann man sich sparen:
Hat man Access legt man sich einen Stichtag vor dem letzten Abgleich (also neue Artikel hinzufügen) fest und teilt die Datenbank entsprechend auf (also Kopie der *.db4 anlegen, in der einen vor Stichsekunde (neue Datenbank) und in der anderen nach oder gleich Stichsekunde (alte Datenbank) löschen) - fertig. Ohne Access geht es natürlich auch, aber mit ist es aus meiner Sicht sicherer & eindeutiger (als das irgendwelche Datensätze, die mit der Suche nicht erfasst werden, durch die Lappen gehen und dann doppelt vorhanden sind).
Wichtig: Ich bin zum einfacherern Verständnis vom Startdatum der Auktionen ausgegangen, beim Enddatum wird's komplizierter.
Sven
Ja, ja, das hat man von den Schnellschüssen aus der Hüfte 
.
Also, ich habe in Kurzform meine bisherige Vorgehensweise beschrieben, ist wohl etwas zu rudimentär ausgefallen.
Daher revidiere ich meinen Vorschlag und ersetze ihn durch diesen:
Der Schnitt wird in die Vergangenheit gelegt, wobei der Stichtag mehr als 31 Tage in die Vergangenheit gelegt wird - dann kann mit der neuen Datenbank auch eine "Verkäufersuche der vergangenen 31 Tage" durchgeführt werden, ohne dass man dannach mit der Redundanz rumplagen muss.
Wenn also heute (27.06.2005) der Schnitt erfolgen soll, so wäre der Stichtag der 26.05.2005. Alles was vorher zu ende ging, kann aus der neuen DB gelöscht werden, und in der alten DB kann alles was danach zu ende ging gelöscht werden.
svru, einverstanden?
.Also, ich habe in Kurzform meine bisherige Vorgehensweise beschrieben, ist wohl etwas zu rudimentär ausgefallen.
Daher revidiere ich meinen Vorschlag und ersetze ihn durch diesen:
Der Schnitt wird in die Vergangenheit gelegt, wobei der Stichtag mehr als 31 Tage in die Vergangenheit gelegt wird - dann kann mit der neuen Datenbank auch eine "Verkäufersuche der vergangenen 31 Tage" durchgeführt werden, ohne dass man dannach mit der Redundanz rumplagen muss.
Wenn also heute (27.06.2005) der Schnitt erfolgen soll, so wäre der Stichtag der 26.05.2005. Alles was vorher zu ende ging, kann aus der neuen DB gelöscht werden, und in der alten DB kann alles was danach zu ende ging gelöscht werden.
svru, einverstanden?
"ABAP is neither cool nor sexy." - Horst Keller
Hi Mash,
31 Tage aber nur wenn man diese Suche braucht, sonst reicht vollkommen vor dem letzten Abgleich. Ich brauche nämlich diese Suche nicht...
Und ganz wichtig, wenn auch kleinkrämerisch, aber so bin ich halt: Das "<" und das ">=" statt nur ">" beachten, denn sonst verbleiben Artikel genau auf der Stichsekunde doppelt und dank der Startzeitplanung und der Affinität des Ménschen auf runde Zahlen zur Festlegung des Stichtages könnte es schon einige treffen...
Sven
31 Tage aber nur wenn man diese Suche braucht, sonst reicht vollkommen vor dem letzten Abgleich. Ich brauche nämlich diese Suche nicht...
Und ganz wichtig, wenn auch kleinkrämerisch, aber so bin ich halt: Das "<" und das ">=" statt nur ">" beachten, denn sonst verbleiben Artikel genau auf der Stichsekunde doppelt und dank der Startzeitplanung und der Affinität des Ménschen auf runde Zahlen zur Festlegung des Stichtages könnte es schon einige treffen...
Sven
Re: Datenbank voll - V3
falls du einzelne artikelbeschreibungen nicht benötigst, dann kannst du die auch löschen bzw weglassen beim einscannen. die nehmen den meisten platz weg.gerwell hat geschrieben:Hallo,
bei mir geht die Kapazität der DB dem Ende zu. Ich scanne eine ganze Kategorie. Jetzt würde ich gerne eine neue DB anlegen. Hat jemand eine Idee, wie ich das anstelle, wenn BW jetzt "zum ersten" mal die Kategorie einliest, daß nicht auch die Artikel genommen werden, welche auch in der ersten vorhanden sind.
Och, kleinkrämerisch finde ich das nicht, letztlich gehören in SQL "<" und ">=" (und die anderen Kombinationsmöglichkeiten) sinngemäß immer zusammen. Aber wenn man lediglich BW zur Verfügung hat, spielt es keine Rolle, da der Ausdruck "Bis 27.06.2005" alle Artikel bis "27.06.2005 23:59:59" enthält. Eine Sekunde später trägt ein Artikel bereits das Datum "28.06.2005".svru hat geschrieben:Hi Mash,
31 Tage aber nur wenn man diese Suche braucht, sonst reicht vollkommen vor dem letzten Abgleich. Ich brauche nämlich diese Suche nicht...
Und ganz wichtig, wenn auch kleinkrämerisch, aber so bin ich halt: Das "<" und das ">=" statt nur ">" beachten, denn sonst verbleiben Artikel genau auf der Stichsekunde doppelt und dank der Startzeitplanung und der Affinität des Ménschen auf runde Zahlen zur Festlegung des Stichtages könnte es schon einige treffen...
Sven
Mit den "31 Tagen"-Grenze hast Du natürlich recht, ich habe die Funktion lange Zeit nicht verwendet. Es ist halt nur eine Sicherheitsmaßnahme, da ich nicht weiß, ob gerwell (...dessen Thread wir hier "offtopicen") sie nutzt.
"ABAP is neither cool nor sexy." - Horst Keller