Hallo Zusammen,
habe folgendes Problem:
Wenn ich eine von mehreren db3-Dateien mit ca. 4,5 Mio Datensätzen in baywotch einbinde und vor dem finalen Abgleich noch das Kategorienupdate durchführe, dann erscheint nach dem Runterladen der Kategorien von eBay die Meldung "Überprüfe bestehende Artikeldaten". Dieser Vorgang dauert ca. 2 Stunden.
Woran liegt das? Wie kann man den Vorgang beschleunigen?
Vielen Dank im voraus!
Beste Grüße aus Hamburg,
Thorsten
Überprüfen der bestehenden Artikeldaten dauert ca. 2 Stunden
Hallo Thorsten!
BayWotch überprüft jeden Datensatz bezüglich der "neuen" Kategoriestruktur. Bei 4.5 MIO Datensätzen kann das dauern.
Etwas Abhilfe könnte schaffen direkt unter Access einmal eine Reparieren/Komprimieren durchführen. Außerdem könnte helfen, in den Feldern cat_1 und cat_2 einen Index zu setzen (falls nicht vorhanden).
Das war's, was mir zu Access dazu einfällt.
Dann wäre natürlich denkbar, die Hardware aufzurüsten, die mir aber bei Dir schon (fast) optimal erscheint.
Aber, wenn Du das Kategorieupdate in Zeiten durchführst, wo Du eh wenig oder garnicht am Rechner bist, würde es doch garnicht auffallen (also geschickte Arbeitszeitplanung). Wenn Du allerdings am Rechner arbeiten möchtest und dann das Kategorieupdate durchführst und wartest, bis es fetig ist, das kann nerven.
BayWotch überprüft jeden Datensatz bezüglich der "neuen" Kategoriestruktur. Bei 4.5 MIO Datensätzen kann das dauern.
Etwas Abhilfe könnte schaffen direkt unter Access einmal eine Reparieren/Komprimieren durchführen. Außerdem könnte helfen, in den Feldern cat_1 und cat_2 einen Index zu setzen (falls nicht vorhanden).
Das war's, was mir zu Access dazu einfällt.
Dann wäre natürlich denkbar, die Hardware aufzurüsten, die mir aber bei Dir schon (fast) optimal erscheint.
Aber, wenn Du das Kategorieupdate in Zeiten durchführst, wo Du eh wenig oder garnicht am Rechner bist, würde es doch garnicht auffallen (also geschickte Arbeitszeitplanung). Wenn Du allerdings am Rechner arbeiten möchtest und dann das Kategorieupdate durchführst und wartest, bis es fetig ist, das kann nerven.
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Hallo Tim,
danke für Deine Antwort. In den Feldern cat_1 und cat_2 existiert standardmäßig ein Index.
Leider ist das Problem sogar noch schwerwiegender - baywotch hat aus jedem Datensatz die cat_1_id gelöscht. Ich wollte nach dem Kategorienupdate sowie dem Komprimieren und Reparieren der Datenbank die per favscan eingelesenen Datensätze abgleichen und da geht dann gar nichts mehr. Sehr komisch!
Sollte man auf das Kategorienupdate für bereits eingelesene Datensätze ganz verzichten? Was hat das für Folgen? Fallen mir dann Artikel raus?
Frustrierte Grüße,
Thorsten
danke für Deine Antwort. In den Feldern cat_1 und cat_2 existiert standardmäßig ein Index.
Leider ist das Problem sogar noch schwerwiegender - baywotch hat aus jedem Datensatz die cat_1_id gelöscht. Ich wollte nach dem Kategorienupdate sowie dem Komprimieren und Reparieren der Datenbank die per favscan eingelesenen Datensätze abgleichen und da geht dann gar nichts mehr. Sehr komisch!
Sollte man auf das Kategorienupdate für bereits eingelesene Datensätze ganz verzichten? Was hat das für Folgen? Fallen mir dann Artikel raus?
Frustrierte Grüße,
Thorsten
Hallo Thorsten!
Das Kategorienupdate muß wohl sein, da sonst u.U. Favoriten, die mit Kategorien eingestellt sind, und auch Suchfunktionen über die Kategorie nicht richtig arbeiten. Ansonsten ist es ja "nur" eine gespeicherte Zahl, auf die intern verwiesen wird (Verknüpfung), um sie in den Artikeldetails anzuzeigen. Deine Frage (Vorschlag) ist wohl eher, die bereits in der DB befindlichen Datensätze nach einem Kategorienupdate nicht neu abzugleichen. Dafür müßte dann in den Optionen ein neues Auswahlfeld her. Wer weiß, was er macht, könnte dann die entsprechende Option einstellen. Das würde in Deinem Fall sehr zeitsparend sein!
Das Kategorienupdate muß wohl sein, da sonst u.U. Favoriten, die mit Kategorien eingestellt sind, und auch Suchfunktionen über die Kategorie nicht richtig arbeiten. Ansonsten ist es ja "nur" eine gespeicherte Zahl, auf die intern verwiesen wird (Verknüpfung), um sie in den Artikeldetails anzuzeigen. Deine Frage (Vorschlag) ist wohl eher, die bereits in der DB befindlichen Datensätze nach einem Kategorienupdate nicht neu abzugleichen. Dafür müßte dann in den Optionen ein neues Auswahlfeld her. Wer weiß, was er macht, könnte dann die entsprechende Option einstellen. Das würde in Deinem Fall sehr zeitsparend sein!
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Hallo Tim,
noch mal Danke für Deine Antwort.
Ja, ich meinte, mit den bereits in der DB befindlichen Datensätzen kein Kategorienupdate durchzuführen.
Doch dann tritt das nächste Problem auf, an dem ich nun schon seit Tagen erfolglos bastle.
Anbei die Problembeschreibung die ich gerade an Elmar gemailt habe - vielleicht ist sie ja auch für andere User interessant.
Hauptproblem
Seit drei Tagen habe ich jetzt mehrere Varianten ausprobiert, um alle Datensätze in einer 1,9 GB großen Datenbank mit 4,4 Mio Artikeln abzugleichen - leider ohne Ergebnis, d.h. mit Fehlermeldung.
Vorgehensweise A
Wenn ich die Datensätze über Kommandozeilen-Schalter "/scanincomplete /noquit" abgleichen will, passiert folgendes:
Es erscheint in der Statuszeile "Ermittle abzugleichende Artikel".
Danach erscheint in der Statuszeile "Lege Sendeaufträge an" dabei zieht sich der Prozeß "baywotch.exe" um die 800 MB Arbeitsspeicher und die Auslagerungsdatei wächst kontinuierlich auf rund 1,9 GB an (bei 1GB RAM). Wenn dieser Arbeitsschritt abgeschlossen ist (meine Vermutung, weil dann die Auslagerungsdatei konstant bleibt) bricht bayWotch mit folgender Fehlermeldung ab:
"bayWotch.exe - Fehler in Anwendung
Die Anweisung in "0x202b7062" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.
Klicken Sie auf "OK", um das Programm zu beenden.
ADO Treiberversion: 2.8
DAO Treiberversion: 3.6"
Dieser Abbruch ist reproduzierbar. Auch die Neuinstallation von bayWotch, Verschiebung und Defragmentierung der Datenbank und Auslagerungsdatei ändern daran nichts. Nur wenn ich bayWotch ganz nackt ausführe hängt es sich manchmal an der gleichen Stelle ohne Fehlermeldung auf. In beiden Fällen werden noch keine Daten von eBay übertragen.
Vorgehensweise B
Wenn ich die Datensätze direkt im Programm abgleichen will und auf Datenbanksuche klicke und dabei alle Auktionen, deren "Abgleich offen" ist auswähle, erscheint in der Statuszeile zuerst "Suche in Datenbank". Wenn danach "Erstelle Liste" erscheint, bricht das Programm ab. Anbei Text der "runtime.txt".
"Unerwarteter Laufzeitfehler:
Modul: s_SearchDatabase
Zeile: 0
Code: 7
Description: Nicht genügend Speicher
Source: bwsGrid
Zeit: 08.01.2005 12:01:41
App Version: 2.5.110 Final.2
DAO Version: 3.6
ADO Version: 2.8
Winsock Version: 6.1.97.82"
Dabei fällt mir auf dass die Speicherauslastung des Prozesses nur bei konstant 34 MB bleibt und auch die Auslagerungsdatei nur bei konstant 230 MB bleibt. Auch dieser Abbruch ist reproduzierbar.
Beide Arten des Abbruchs erfolgen sowohl mit der Version 2.5.110, als auch mit der Version 2.5.109.
Meine Konfiguration: P4 (HT) mit 3 GHZ, 1GB RAM und 200GB IDE-Platte, Windows XP SP2 sowie Hansenet DSL mit 1.024KB down.
1. Anmerkung: Ich speichere weder die Bilder noch die Artikelbeschreibung.
2. Anmerkung: Wenn ich mühsam in der Datenbank unter Access von den 2,5 Mio Datensätzen 2 Mio lösche und dann den Abgleich mit beiden Vorgehensweisen durchführe, funktioniert alles reibungslos (bei Vorgehensweise B steigt dann auch die Speicherauslastung des Prozesses sowie die Größe der Auslagerungsdatei kontinuierlich).
Vielleicht ist dies auch für andere User hilfreich - ich hoffe sehr, dass Elmar dafür eine Lösung weiß.
Liebe Grüße aus Hamburg,
Thorsten
noch mal Danke für Deine Antwort.
Ja, ich meinte, mit den bereits in der DB befindlichen Datensätzen kein Kategorienupdate durchzuführen.
Doch dann tritt das nächste Problem auf, an dem ich nun schon seit Tagen erfolglos bastle.
Anbei die Problembeschreibung die ich gerade an Elmar gemailt habe - vielleicht ist sie ja auch für andere User interessant.
Hauptproblem
Seit drei Tagen habe ich jetzt mehrere Varianten ausprobiert, um alle Datensätze in einer 1,9 GB großen Datenbank mit 4,4 Mio Artikeln abzugleichen - leider ohne Ergebnis, d.h. mit Fehlermeldung.
Vorgehensweise A
Wenn ich die Datensätze über Kommandozeilen-Schalter "/scanincomplete /noquit" abgleichen will, passiert folgendes:
Es erscheint in der Statuszeile "Ermittle abzugleichende Artikel".
Danach erscheint in der Statuszeile "Lege Sendeaufträge an" dabei zieht sich der Prozeß "baywotch.exe" um die 800 MB Arbeitsspeicher und die Auslagerungsdatei wächst kontinuierlich auf rund 1,9 GB an (bei 1GB RAM). Wenn dieser Arbeitsschritt abgeschlossen ist (meine Vermutung, weil dann die Auslagerungsdatei konstant bleibt) bricht bayWotch mit folgender Fehlermeldung ab:
"bayWotch.exe - Fehler in Anwendung
Die Anweisung in "0x202b7062" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.
Klicken Sie auf "OK", um das Programm zu beenden.
ADO Treiberversion: 2.8
DAO Treiberversion: 3.6"
Dieser Abbruch ist reproduzierbar. Auch die Neuinstallation von bayWotch, Verschiebung und Defragmentierung der Datenbank und Auslagerungsdatei ändern daran nichts. Nur wenn ich bayWotch ganz nackt ausführe hängt es sich manchmal an der gleichen Stelle ohne Fehlermeldung auf. In beiden Fällen werden noch keine Daten von eBay übertragen.
Vorgehensweise B
Wenn ich die Datensätze direkt im Programm abgleichen will und auf Datenbanksuche klicke und dabei alle Auktionen, deren "Abgleich offen" ist auswähle, erscheint in der Statuszeile zuerst "Suche in Datenbank". Wenn danach "Erstelle Liste" erscheint, bricht das Programm ab. Anbei Text der "runtime.txt".
"Unerwarteter Laufzeitfehler:
Modul: s_SearchDatabase
Zeile: 0
Code: 7
Description: Nicht genügend Speicher
Source: bwsGrid
Zeit: 08.01.2005 12:01:41
App Version: 2.5.110 Final.2
DAO Version: 3.6
ADO Version: 2.8
Winsock Version: 6.1.97.82"
Dabei fällt mir auf dass die Speicherauslastung des Prozesses nur bei konstant 34 MB bleibt und auch die Auslagerungsdatei nur bei konstant 230 MB bleibt. Auch dieser Abbruch ist reproduzierbar.
Beide Arten des Abbruchs erfolgen sowohl mit der Version 2.5.110, als auch mit der Version 2.5.109.
Meine Konfiguration: P4 (HT) mit 3 GHZ, 1GB RAM und 200GB IDE-Platte, Windows XP SP2 sowie Hansenet DSL mit 1.024KB down.
1. Anmerkung: Ich speichere weder die Bilder noch die Artikelbeschreibung.
2. Anmerkung: Wenn ich mühsam in der Datenbank unter Access von den 2,5 Mio Datensätzen 2 Mio lösche und dann den Abgleich mit beiden Vorgehensweisen durchführe, funktioniert alles reibungslos (bei Vorgehensweise B steigt dann auch die Speicherauslastung des Prozesses sowie die Größe der Auslagerungsdatei kontinuierlich).
Vielleicht ist dies auch für andere User hilfreich - ich hoffe sehr, dass Elmar dafür eine Lösung weiß.
Liebe Grüße aus Hamburg,
Thorsten
Hallo Thorsten!
Sieht aus, als ob das Limit für Tabellen von 1GB bei der "tblauction" erreicht ist. Das Limit für die DB ist 2 GB, für einzelne Tabellen leider nur 1GB.
Sobald das Limit erreicht ist, werden Datenbankoperationen nicht mehr zugelassen, es sind nur noch Lesezugriffe möglich. Die einzige Möglichkeit wieder eine handlungsfähige DB zu bekommen, ist, Daten zu löschen/auslagern. Das ist ja auch bei Dir der Fall gewesen. Je voller eine DB wird und je näher sie am Limit ist, umso schwerfälliger wird sie. Das Limit von 1GB ist auch nur ein Anhalt. Die tatsächliche Größe, die unter Access noch lauffähig war, war wesentlich größer als 1GB. Das dürfte auch bei Dir jetzt der Fall sein.
Noch etwas: mit einem Zusatzprogramm wie BayWotch, das direkt auf die DB Zugriff hat, ist es möglich, die DB zu "überfüllen". Das habe ich in div. Tests machen können. Ist die DB einmal "überfüllt", ist sie nicht mehr zu reparieren. Unter Access wird eine "Überfullung" nicht zugelassen. Ich hatte damals angeregt, eine entsprechende Bremse in BW einzubauen. Was aber daraus geworden ist, habe ich nicht mehr im Blick. Ich glaube, Elmar hatte für die V3 eine Änderung eingeplant??!! Mal sehen, was er dazu sagt!
Sieht aus, als ob das Limit für Tabellen von 1GB bei der "tblauction" erreicht ist. Das Limit für die DB ist 2 GB, für einzelne Tabellen leider nur 1GB.
Sobald das Limit erreicht ist, werden Datenbankoperationen nicht mehr zugelassen, es sind nur noch Lesezugriffe möglich. Die einzige Möglichkeit wieder eine handlungsfähige DB zu bekommen, ist, Daten zu löschen/auslagern. Das ist ja auch bei Dir der Fall gewesen. Je voller eine DB wird und je näher sie am Limit ist, umso schwerfälliger wird sie. Das Limit von 1GB ist auch nur ein Anhalt. Die tatsächliche Größe, die unter Access noch lauffähig war, war wesentlich größer als 1GB. Das dürfte auch bei Dir jetzt der Fall sein.
Noch etwas: mit einem Zusatzprogramm wie BayWotch, das direkt auf die DB Zugriff hat, ist es möglich, die DB zu "überfüllen". Das habe ich in div. Tests machen können. Ist die DB einmal "überfüllt", ist sie nicht mehr zu reparieren. Unter Access wird eine "Überfullung" nicht zugelassen. Ich hatte damals angeregt, eine entsprechende Bremse in BW einzubauen. Was aber daraus geworden ist, habe ich nicht mehr im Blick. Ich glaube, Elmar hatte für die V3 eine Änderung eingeplant??!! Mal sehen, was er dazu sagt!
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Hallo Tim,
damit hast Du ja meinen Tag gerettet.
Diese Information fehlte mir. Bisher kannte ich nur das 2 GB für die Datenbank. Dann liegt es wahrscheinlich auch daran, dass das Kategorienupdate so lange dauert - die Tabelle ist einfach zu groß, so dass die cat-Id-Felder nicht aktualisiert, sondern gelöscht werden.
Dann werde ich jetzt mit kleineren DBs arbeiten, die sind dann eh besser zu handeln.
Ich werde das Montag mal testen, denn ich habe noch eine mit insgesamt 1,1 GB.
Aber übrigens, man kann die Datenbanken in Access reparieren - ich habe aus meiner 1,9 GB DB mit Access Datensätze rauslöschen können. Nur dauert das extrem lange, wahrscheinlich auch wegen der "Übergröße".
Auf jeden Fall vielen, vielen Dank für Deine Info.
Dann wäre es auf jeden Fall gut, wenn in V3 eine "Bremse" integriert wäre.
Lieben Gruß,
Thorsten
damit hast Du ja meinen Tag gerettet.
Diese Information fehlte mir. Bisher kannte ich nur das 2 GB für die Datenbank. Dann liegt es wahrscheinlich auch daran, dass das Kategorienupdate so lange dauert - die Tabelle ist einfach zu groß, so dass die cat-Id-Felder nicht aktualisiert, sondern gelöscht werden.
Dann werde ich jetzt mit kleineren DBs arbeiten, die sind dann eh besser zu handeln.
Ich werde das Montag mal testen, denn ich habe noch eine mit insgesamt 1,1 GB.
Aber übrigens, man kann die Datenbanken in Access reparieren - ich habe aus meiner 1,9 GB DB mit Access Datensätze rauslöschen können. Nur dauert das extrem lange, wahrscheinlich auch wegen der "Übergröße".
Auf jeden Fall vielen, vielen Dank für Deine Info.
Dann wäre es auf jeden Fall gut, wenn in V3 eine "Bremse" integriert wäre.
Lieben Gruß,
Thorsten
Hallo Thorsten!
Das wäre die "Datenbankerklärung".
Aber vielleicht gibt es ja eine eBay-Lösung. Evt. gab es für die Artikel vorher eine eigene Kategorie, nach dem Update mit den neuen Kategorien aber nicht mehr, so dass BW konsequenterweise die cat-Felder geleert hat??!!
Wenn die Tabelle/DB zu groß ist, werden keine Datenbankoperationen, außer Lesezugriffen, mehr zugelassen. Gelöscht wird aber, soweit ich das sagen kann, nichts. Das die cat-Felder leer sind, müsste eine andere Ursache haben. Normalerweise werden die Zellen überschrieben; werden sie aber erst gelöscht und dann in einem zweitem Zugriff erst "neu" gefüllt, so könnte der Löschvorgang funktionieren, der Schreibzugriff aber nicht mehr.Dann liegt es wahrscheinlich auch daran, dass das Kategorienupdate so lange dauert - die Tabelle ist einfach zu groß, so dass die cat-Id-Felder nicht aktualisiert, sondern gelöscht werden.
Das wäre die "Datenbankerklärung".
Aber vielleicht gibt es ja eine eBay-Lösung. Evt. gab es für die Artikel vorher eine eigene Kategorie, nach dem Update mit den neuen Kategorien aber nicht mehr, so dass BW konsequenterweise die cat-Felder geleert hat??!!
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
-
denkmann
- Administrator
- Beiträge: 5369
- Registriert: 31.12.2003, 00:14
- Wohnort: Stolberg (Rhld.) bei Aachen
- Kontaktdaten:
Hallo zusammen,
ich führe das Thema mal hier im Forum weiter.
Erst einmal möchte ich mit einem Gerücht aufräumen, welches hier im Forum schon längere Zeit kursiert: Das Maximum von 1GB für eine Access Tabelle!
Mir wäre nicht von einem solchen Limit bekannt. Endlich fand ich heute morgen etwas Zeit, um meine Zweifel in einem praktischen Test zu bestätigen. Dazu habe ich eine jungfräuliche BayWotch DB genommen, alle Tabellen (inkl. Kategorien) geleert und dann mit einem kleinen Programm Artikel für Artikel gefüllt.
Insgesamt konnte ich ca. 1,4 Mio. Datensätze in der tblAuction anlegen, bevor eine Fehlermeldung die Schleife beendete. Für Interessierte: Alle Textfelder wurden - bis auf die Artikelbeschreibung - komplett gefüllt.
Die Datei baywotch.db3 hatte anschließend eine Größe von runden 2GB.
Da keine andere Tabelle irgendwelche Daten enthielt, läßt sich also die magische 1GB Grenze für eine Tabelle kippen.
Sicherheitshalber habe ich 2 Datensätze gelöscht und anschließend über BayWotch 2 neue Artikel hinzugefügt - ohne Probleme.
@Thorsten:
Du gehst hier teilweise mit dem Vorschlaghammer auf BayWotch los. 4,5 Mio. Datensätze sind kein Pappenstiel für ein Programm, welches per ADO auf eine dateibasierende Datenbank zugreift. ;-)
Wir erinnern uns: In BayWotch v1 wurde noch das Standard-Grid von Microsoft benutzt; da stieß man schon nach ein paar Tausend angezeigten Artikeln auf merkwürdige Veränderungen des Fonts und der Farbe -> Speicherprobleme. Das jetzt in BayWotch integrierte Grid ist da sehr viel leistungsfähiger, hat aber natürlich auch seine physikalischen Grenzen.
Ich kann mir aber auch keinen praktischen Fall vorstellen, bei dem es Sinn machen würde, 4,5 Mio. Artikel in der Liste anzeigen. Man kann auch sofort die nicht abgeglichenen Artikel über den Menüpunkt "Nicht abgeglichene Artikel abgleichen" aktualisieren, dies entspricht dann dem Kommanozeilenparameter /scanincomplete.
ich führe das Thema mal hier im Forum weiter.
Erst einmal möchte ich mit einem Gerücht aufräumen, welches hier im Forum schon längere Zeit kursiert: Das Maximum von 1GB für eine Access Tabelle!
Mir wäre nicht von einem solchen Limit bekannt. Endlich fand ich heute morgen etwas Zeit, um meine Zweifel in einem praktischen Test zu bestätigen. Dazu habe ich eine jungfräuliche BayWotch DB genommen, alle Tabellen (inkl. Kategorien) geleert und dann mit einem kleinen Programm Artikel für Artikel gefüllt.
Insgesamt konnte ich ca. 1,4 Mio. Datensätze in der tblAuction anlegen, bevor eine Fehlermeldung die Schleife beendete. Für Interessierte: Alle Textfelder wurden - bis auf die Artikelbeschreibung - komplett gefüllt.
Die Datei baywotch.db3 hatte anschließend eine Größe von runden 2GB.
Da keine andere Tabelle irgendwelche Daten enthielt, läßt sich also die magische 1GB Grenze für eine Tabelle kippen.
Sicherheitshalber habe ich 2 Datensätze gelöscht und anschließend über BayWotch 2 neue Artikel hinzugefügt - ohne Probleme.
@Thorsten:
Du gehst hier teilweise mit dem Vorschlaghammer auf BayWotch los. 4,5 Mio. Datensätze sind kein Pappenstiel für ein Programm, welches per ADO auf eine dateibasierende Datenbank zugreift. ;-)
BayWotch führt an dieser Stelle einige SQL-Updates aus, um die Datenintegrität bzgl. der Kategorienzugehörigkeit aufrecht zu erhalten. Beschleunigen kann man da leider nichts mehr, da hier die komplette Abfrage über ein direktes "Execute" stattfindet, d.h. die Anweisung geht direkt an die Datenbanktreiber und die Datenbank. Was dann Zeit kostet, wurde von Microsoft so geplant. ;-)Wenn ich eine von mehreren db3-Dateien mit ca. 4,5 Mio Datensätzen in baywotch einbinde und vor dem finalen Abgleich noch das Kategorienupdate durchführe, dann erscheint nach dem Runterladen der Kategorien von eBay die Meldung "Überprüfe bestehende Artikeldaten". Dieser Vorgang dauert ca. 2 Stunden.
In diesem Fall existierte die bei den Artikeln gespeicherte Kategorie nicht mehr bei eBay. BayWotch erkennt dies beim o.g. Kategorien-Check und löscht die Kategorien-ID bei den betroffenen Artikeln, um zu vermeiden, daß die Artikel später in einer anderen Kategorie auftauchen; nur für den Fall, daß eBay tatsächlich einmal eine herausgefallene Kategorien-ID erneut für andere Bereiche verwendet sollte.Leider ist das Problem sogar noch schwerwiegender - baywotch hat aus jedem Datensatz die cat_1_id gelöscht. Ich wollte nach dem Kategorienupdate sowie dem Komprimieren und Reparieren der Datenbank die per favscan eingelesenen Datensätze abgleichen und da geht dann gar nichts mehr. Sehr komisch!
In Deinem Falle ein dickes JA. Die einmal gespeicherten Artikel lassen sich über die dazu passende (veraltete) Kategorienstruktur der selben Datenbank jederzeit auffinden. Neue Artikel möchtest Du nicht mehr hinzufügen. Eine Aktualisierung der Kategorien ist hier sogar kontraproduktiv.Sollte man auf das Kategorienupdate für bereits eingelesene Datensätze ganz verzichten? Was hat das für Folgen? Fallen mir dann Artikel raus?
Ich habe gerade einmal einen Test mit meinen 1,4 Mio. Datensätzen durchgeführt. Da kam zumindest kein Fehler. Ich kann allerdings nicht ausschließen, daß bei der 3-fachen Menge hier irgendwann Speicherprobleme auftauchen. In jedem Fall würde ich Dir raten, kleinere "Häppchen" zu verarbeiten. Teile die Datenbanken z.B. in Kategorien auf.Vorgehensweise A
Wenn ich die Datensätze über Kommandozeilen-Schalter "/scanincomplete /noquit" abgleichen will, passiert folgendes:
Es erscheint in der Statuszeile "Ermittle abzugleichende Artikel".
Danach erscheint in der Statuszeile "Lege Sendeaufträge an" dabei zieht sich der Prozeß "baywotch.exe" um die 800 MB Arbeitsspeicher und die Auslagerungsdatei wächst kontinuierlich auf rund 1,9 GB an (bei 1GB RAM). Wenn dieser Arbeitsschritt abgeschlossen ist (meine Vermutung, weil dann die Auslagerungsdatei konstant bleibt) bricht bayWotch mit folgender Fehlermeldung ab:
"bayWotch.exe - Fehler in Anwendung
Die Anweisung in "0x202b7062" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.
Ja, das kann ich bei meinem Versuch mit 1,4 Mio. Artikeln bestätigen. Hier läuft BayWotch auf die Speichergrenze für das Datagrid, also der Komponente zur Anzeige der Artikelliste.Vorgehensweise B
Wenn ich die Datensätze direkt im Programm abgleichen will und auf Datenbanksuche klicke und dabei alle Auktionen, deren "Abgleich offen" ist auswähle, erscheint in der Statuszeile zuerst "Suche in Datenbank". Wenn danach "Erstelle Liste" erscheint, bricht das Programm ab. Anbei Text der "runtime.txt".
"Unerwarteter Laufzeitfehler:
Wir erinnern uns: In BayWotch v1 wurde noch das Standard-Grid von Microsoft benutzt; da stieß man schon nach ein paar Tausend angezeigten Artikeln auf merkwürdige Veränderungen des Fonts und der Farbe -> Speicherprobleme. Das jetzt in BayWotch integrierte Grid ist da sehr viel leistungsfähiger, hat aber natürlich auch seine physikalischen Grenzen.
Ich kann mir aber auch keinen praktischen Fall vorstellen, bei dem es Sinn machen würde, 4,5 Mio. Artikel in der Liste anzeigen. Man kann auch sofort die nicht abgeglichenen Artikel über den Menüpunkt "Nicht abgeglichene Artikel abgleichen" aktualisieren, dies entspricht dann dem Kommanozeilenparameter /scanincomplete.
Gruß,
Elmar Denkmann
(Entwickler)
Elmar Denkmann
(Entwickler)
Hallo Elmar,
vielen Dank für Deine hilfreiche und umfangreiche Antwort.
Auf jeden Fall werde ich jetzt trotz 2GB-Limit (auch für Tabellen) mit kleineren 1 GB-Häppchen arbeiten, um die Arbeit zu beschleunigen und zu vereinfachen.
Dass man auch sofort die nicht abgeglichenen Artikel über den Menüpunkt "Nicht abgeglichene Artikel abgleichen" aktualisieren kann - hatte ich übersehen - das spart ebenfalls Zeit.
Es ist mir klar, dass ich manchmal mit dem "Vorschlaghammer" auf bayWotch losgehe - doch zum Glück gibt es wenigstens ein so ausgereiftes und leistungsstarkes Programm, das solche umfangreicheren eBay-Analysen überhaupt ermöglicht.
Also noch mal vielen Dank sowie liebe Grüße aus Hamburg,
Thorsten
vielen Dank für Deine hilfreiche und umfangreiche Antwort.
Auf jeden Fall werde ich jetzt trotz 2GB-Limit (auch für Tabellen) mit kleineren 1 GB-Häppchen arbeiten, um die Arbeit zu beschleunigen und zu vereinfachen.
Dass man auch sofort die nicht abgeglichenen Artikel über den Menüpunkt "Nicht abgeglichene Artikel abgleichen" aktualisieren kann - hatte ich übersehen - das spart ebenfalls Zeit.
Es ist mir klar, dass ich manchmal mit dem "Vorschlaghammer" auf bayWotch losgehe - doch zum Glück gibt es wenigstens ein so ausgereiftes und leistungsstarkes Programm, das solche umfangreicheren eBay-Analysen überhaupt ermöglicht.
Also noch mal vielen Dank sowie liebe Grüße aus Hamburg,
Thorsten
Hallo Elmar!
Auch ist es möglich innerhalb von Access die Tabellengröße über 1GB zu bringen! Unter BW ist es allemal möglich, da BW einen anderen (direkteren ?*) Weg zur DB benutzt, so dass, wie auch bei Deinem Test, die DB mit nur einer Tabelle 2GB groß werden kann. Auch dass wurde beschrieben:
* wir hatten mal einen Laufzeitfehler, der verursacht wurde durch mehrere leere Felder in der Artikelnr. obwohl in den Eigenschaften eingestellt war, dass das Feld nicht leer sein darf (Das "Mysterium" der DB3). Hier wurde, sozusagen an Access vorbei, auf die Tabelle zugegriffen.
Als Gerücht würde ich das nicht bezeichnen. Die Quelle war eine Spezifikation von M$ bezüglich der Access 2000 DB. Die Quelle wurde im alten Forum mit Link darauf gepostet. Leider ist das alte Forum abgestellt und ich kann so auf die schnelle auf der M$-Page die Stelle nicht wiederfinden, vielleicht ist sie auch garnicht mehr da. ( Und vielleicht war dieser Wert nur die garantierte Max-Größe, der in der Praxis ohne Probleme überschritten werden kann, ähnlich der Hochgeschwindigkeitsangabe in einem Autoprospekt).Erst einmal möchte ich mit einem Gerücht aufräumen, welches hier im Forum schon längere Zeit kursiert: Das Maximum von 1GB für eine Access Tabelle!
Auch ist es möglich innerhalb von Access die Tabellengröße über 1GB zu bringen! Unter BW ist es allemal möglich, da BW einen anderen (direkteren ?*) Weg zur DB benutzt, so dass, wie auch bei Deinem Test, die DB mit nur einer Tabelle 2GB groß werden kann. Auch dass wurde beschrieben:
Bei einer frischen DB/Tabelle kann man damit auch arbeiten. Aber es könnte im Laufe der Zeit passieren, dass nach reichlichem Gebrauch der DB, Access sich daran erinnert, dass es ja noch ein Limit gibt. Das war der Vater des Gedanken!...Die tatsächliche Größe, die unter Access noch lauffähig war, war wesentlich größer als 1GB....
* wir hatten mal einen Laufzeitfehler, der verursacht wurde durch mehrere leere Felder in der Artikelnr. obwohl in den Eigenschaften eingestellt war, dass das Feld nicht leer sein darf (Das "Mysterium" der DB3). Hier wurde, sozusagen an Access vorbei, auf die Tabelle zugegriffen.
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
-
denkmann
- Administrator
- Beiträge: 5369
- Registriert: 31.12.2003, 00:14
- Wohnort: Stolberg (Rhld.) bei Aachen
- Kontaktdaten:
Hi Tim,
Mir war dieses Limit auch "irgendwoher" bekannt, allerdings war ich mir stets sicher, die 1GB Grenze öfters geknackt zu haben. Als ich dann vor längerer Zeit im Internet nach genauen Infos suchte, wurde ich nur so mit kontroversen Aussagen überschüttet.
Nun habe ich mir nochmals die Zeit genommen und nach den Spezifikationen gesucht. Fast freute ich mich schon, anfangs eine "2GB" Grenze gefunden zu haben, aber die Doku stammte von Access 2003.
Schließlich wurde ich in Access 2000 selbst fündig: Mit dem Stichwort "Spezifikation" kommt man zum Ziel:
Leider habe ich zu dem Thema nichts im WWW gefunden, was genauere Auskunft darüber gibt, wie die beiden Fakten (Doku vs. Test) nun genau in Zusammenhang stehen. 
Aber ich werde weiter meine Augen und Ohren offen halten!
ja, da hast Du Recht! Ich wollte mit meinem Statement auch niemandem auf die Füße treten, sorry, wenn das irgendwie rechthaberisch oder arrogant rübergekommen sein sollte.Borkumer hat geschrieben:Als Gerücht würde ich das nicht bezeichnen. Die Quelle war eine Spezifikation von M$ bezüglich der Access 2000 DB.
Mir war dieses Limit auch "irgendwoher" bekannt, allerdings war ich mir stets sicher, die 1GB Grenze öfters geknackt zu haben. Als ich dann vor längerer Zeit im Internet nach genauen Infos suchte, wurde ich nur so mit kontroversen Aussagen überschüttet.
Nun habe ich mir nochmals die Zeit genommen und nach den Spezifikationen gesucht. Fast freute ich mich schon, anfangs eine "2GB" Grenze gefunden zu haben, aber die Doku stammte von Access 2003.
Schließlich wurde ich in Access 2000 selbst fündig: Mit dem Stichwort "Spezifikation" kommt man zum Ziel:
Code: Alles auswählen
Tabellengröße 1 Gigabyte Aber ich werde weiter meine Augen und Ohren offen halten!
Gruß,
Elmar Denkmann
(Entwickler)
Elmar Denkmann
(Entwickler)
