Hallo Forum,
ich hätte für die Professional-Version einen neuen Vorschlag zur Auslagerung von Artikelbeschreibungen per ODBC auf eine beliebige externe Datenbank, die keine Größenbeschränkungen kennt! Grund für die Entwicklung ist ja das bekannte Problem mit der maximalen Datenbankgröße von 2GB in Access, das damit zwar nicht endgülitg ausgehebelt aber auf eine längere Zeit erledigt ist, solange bis die BayWotch-Datenbank trotz Auslagerung der Artikelbeschreibungen an ihre Grenzen stößt - und das kann zumindestens bei mir noch eine ganze lange Weile dauern. :-)
Diese Lösung verwende ich nun schon einige Zeit und bin heilfroh das ständige Datengeschiebe und die Datenbankwechsel hinter mir zu haben, denn das war einfach nur noch nervig! Das Entwickeln hat einiges an Zeit gekostet und das Ergebnis stellt sich als durchaus performant heraus, im Gegensatz zu anderen Lösungen, die mir als erstes eingefallen sind.
Dazu verwende ich konkret den MS-SQL-Server und erkläre Euch jetzt mal kurz die Einrichtung, die auf anderen Datenbanklösungen entsprechend angewandt werden muß:
- In der externen Datenbank auf dem SQL Server muß eine Tabelle "tblAuslagerung" mit den Feldern "Artikelnummer" (indiziert, float), "Artikelbeschreibung" (ntext) und einem "Flag" (bit, Standard = 0) angelegt werden.
- Diese Tabelle wird in der baywotch.db4 über ODBC verknüpft angelegt und heißt bei mir "tblAuction+".
- Desweiteren wird eine neue Tabelle "tblOption+" in der baywotch.db4 angelegt. Sie enthält nur 1 Feld mit Datumswert, was erstmal leer bleiben kann.
Nun folgt die Auslagerung der Artikelbeschreibungen:
- Mit der Abfrage UPDATE [tblOption+] SET [tblOption+].Datum = DMin("ends","tblAuction","(((tblAuction.finished)=False) AND ((tblAuction.folder_id)<>1 And (tblAuction.folder_id)<>2)) OR (((tblAuction.saved)=False) AND ((tblAuction.folder_id)<>1 And (tblAuction.folder_id)<>2)) OR (((tblAuction.completed_data)=False) AND ((tblAuction.folder_id)<>1 And (tblAuction.folder_id)<>2))"); wird der genaue Zeitpunkt (Ende) der ersten nicht beendeten oder nicht abgeglichenen Auktion bestimmt. D.h. alle zeitlich davor beendeten Auktionen haben eine gespeicherte Artikelbeschreibung und sollten künftig idealerweise nicht mehr abgeglichen werden. Diese Abfrage trägt also genau diesen Zeitpunkt in die "tblOption+" ein und damit ist das Datum bis zu dem alle Artikelbeschreibungen ausgelagert werden können, festgelegt.
- Mit der Abfrage INSERT INTO [tblAuction+] ( Artikelnummer, Artikelbeschreibung ) SELECT tblAuction.article_no, tblAuction.article_desc FROM tblAuction WHERE (((tblAuction.article_desc)<>"" And (tblAuction.article_desc) Is Not Null) AND ((tblAuction.ends)<(SELECT [tblOption+].Datum FROM [tblOption+];)) AND ((tblAuction.folder_id)<>1 And (tblAuction.folder_id)<>2)) ORDER BY tblAuction.article_no; werden nun alle Artikel mit Artikelbeschreibung vor dem gespeicherten Zeitpunkt ausgelagert (Artikelnummer & Artikelbeschreibung).
- Mit der Abfrage UPDATE tblAuction SET tblAuction.article_desc = "" WHERE (((tblAuction.article_desc)<>"" And (tblAuction.article_desc) Is Not Null) AND ((tblAuction.ends)<(SELECT [tblOption+].Datum FROM [tblOption+];)) AND ((tblAuction.folder_id)<>1 And (tblAuction.folder_id)<>2)); werden nun bei allen Artikeln mit Artikelbeschreibung vor dem gespeicherten Zeitpunkt die Artikelbeschreibungen gelöscht und die Datenbank ist frei zum Verkleinern.
Erfolgt danach ein Abgleich von Auktionen, so daß die früheste nicht beendete oder nicht abgeglichene Auktion eine spätere wird, wird sich auch bei erneuter Ausführung der Abfragen das Datum in der Tabelle "tblOption+" ändern und damit können wieder neue Artikelbeschreibungen ausgelagert werden.
Die FolderIDs 1 und 2 entsprechen dabei den Ordnern "Papierkorb" und "Ignorieren" - und die sollten meiner Meinung nach nicht angefaßt werden, aber das kann ja jeder selbst entscheiden inwieweit er überhaupt diese Ordner nutzt.
Nun zur Funktionalität im 'laufenden Betrieb' bei Anzeige von Artikeln nach einer ausgeführten Suche:
- Erfolgt in BayWotch eine Suche werden die Suchergebnisse immer über das Flag "search_result" markiert und genau diese Markierung verwende ich nun bei der Ausführung der Abfrage UPDATE [tblAuction+] INNER JOIN tblAuction ON [tblAuction+].Artikelnummer = tblAuction.article_no SET tblAuction.article_desc = [tblAuction+].Artikelbeschreibung, [tblAuction+].Flag = True WHERE (((tblAuction.search_result)=True) AND ((tblAuction.ends)<(SELECT [tblOption+].Datum FROM [tblOption+];))); zum temporären Zurückholen der Artikelbeschreibungen mit gleichzeitiger Markierung dieser zurückgeholten Beschreibungen in der Tabelle mit den ausgelagerten Daten.
- Irgendwann danach können die geholten Artikelbeschreibungen mit der Abfrage UPDATE tblAuction INNER JOIN [tblAuction+] ON tblAuction.article_no = [tblAuction+].Artikelnummer SET [tblAuction+].Flag = False, tblAuction.article_desc = "" WHERE ((([tblAuction+].Flag)=True)); wieder gelöscht werden, was auch nicht jedesmal sondern durchaus irgendwann ausgeführt werden kann, denn die betroffenen Artikel werden durch das Flag ja nicht vergessen (nur die BayWotch-DB schwillt wieder an). Nur spätestens vor einer erneuten Auslagerung von Beschreibungen muß diese Abfrage ausgeführt werden, denn sonst handelt man sich einen Fehler ein.
Dabei werden anhand des gespeicherten Datums nur die Artikel vor dem Zeitpunkt berücksichtigt und alles danach (und gleich) wird nicht angefaßt!
So, das wär's eigentlich schon zu dem Ganzen. Man kann sich nun in Access (VBA) oder VB eine kleine Anwendung schreiben, die die Abfragen zu einem entsprechendem Zeitpunkt ausführt. Idealerweise wäre natürlich eine Integration in BayWotch und vielleicht - nach Ausreifung dieser Lösung - wird das vielleicht auch einmal möglich sein und von Elmar vorgenommen werden, denn ihm habe ich diese Lösung schon vorgestellt. Aber es gibt noch viele Umstände zu beachten, die, wenn Ihr das mal testet und vielleicht auch benutzt, erst im laufenden Betrieb entdeckt werden können.
So ist es z.B. noch ein 'Problem' wenn Artikel ohne Artikelbeschreibung (weil ausgelagert) erneut abgeglichen werden. Beim nächsten Auslagern würde ein Fehler auftreten. Oder ein ausgelagerter Artikel wird aus der BayWotch-Datenbank endgültig entfernt - dann gäbe es einen verweisten Eintrag in der ausgelagerten Tabelle. Oder ein schon älterer Artikel läßt sich wie bei Artikel 7213766961 nicht abgleichen und damit bleibt das Grenzdatum an dieser Stelle 'hängen'.
Daher würde ich mir wünschen wenn Ihr das mal testet und mir Eure Erfahrungen und Ideen mitteilt. Sicherheitshalber würde ich aber - je nach Wichtigkeit der Daten - ein Backup machen, denn bei den ersten Versuchen damit sind mir leider ein paar Artikelbeschreibungen verlorengegangen... :-(
Und - was dem aufmerksamen Leser nicht entgangen sein sollte - eine Suche ist in den Artikelbeschreibungen aller Artikel vor dem Datum in "tblOption+" nicht mehr direkt möglich. Außer man sucht erstmal ohne, lädt die Beschreibungen nach, und dann sind sie ja für eine Weile drin. Bei einer späteren Implementierung in BayWotch würde das Ganze aber durchaus wieder ganz anders aussehen...
Und, was haltet Ihr davon?
Sven
Neu: Auslagerung der Artikelbeschreibungen wg Datenbankgröße
Hallo Sven!
Was ich noch nicht verstanden habe: möchtest Du die ausgelagerten Beschreibung nur archivieren? (wofür?)
Lese- und/oder Schreibzugriffe auf die ausgelagerten Beschreibungen mit BW sind nicht möglich oder doch?
Ich habe früher mit der V2.x div. Versuche unter Access unternommen, und dabei mehrere DBs aneinandergereiht und diese von BW auswerten lassen. Das hat mit Lesezugriffen sogar prima funktioniert, aber einzelne Abfragen über 1.2 MIO Datensätze mit gespeicherter Beschreibung (aufgeteilt auf 10 Access-DBs mit Union-Abfrage wieder zu einer virtuellen DB zusammen gefügt) haben schon mal 1 Std. und länger gedauert. Das war nicht praxistauglich und Schreibzugriffe waren nicht möglich. Das wird auch mit Deiner Lösung der Schwachpunkt sein? Und wenn man keine Suchen in der Beschreibung durchführen kann ist die Beschreibung auch eher unwichtig. Auch glaube ich, dass die Mischung von Access- und externen Tabellenfeldern (z.B. Nicht-Access SQL-Server-DBs) über Verknüpfungen mit nachgeschalteten Abfragen, wenn überhaupt, nur mit Klimmzügen geht.
Aber ich lasse mich da gerne belehren.
Ein anderer Ansatz wäre, den Ballast aus den Beschreibungen (z.B. unter Access mit einer Änderungsabfrage) löschen zu lassen und nur noch die Schlüsselwörter in der Beschreibung zu speichern, mit dem der Artikel gefunden wurden, wenn die Beschreibung dabei im Spiel war. Das würde die DB4 schlank lassen und es wäre die volle BW-Funktionalität gewährleistet. Das ist nicht für jeden die richtige Lösung und dürfte deshalb nur als Option wählbar sein.
Ferner: da BW V3 jetzt über eine zusätzlich Ordner-Tabelle, die mit der Auktions- (Artikel-)Tabelle verknüpft ist, verfügt, wäre eine Suche in der Beschreibung für einige Nutzer sicher entbehrlich, vorausgesetzt, die Ordnerstruktur wird vom User konsequent durchgesetzt (über Ordner-Subordner etc). Bei dieser Lösung bräuchte man die Beschreibung nicht abspeichern.
Insofern wären mehrere Lösungen für das Problem des DB-Limits vorhanden die alle mit „Hausmitteln“ umsetzbar sind.
Was ich noch nicht verstanden habe: möchtest Du die ausgelagerten Beschreibung nur archivieren? (wofür?)
Lese- und/oder Schreibzugriffe auf die ausgelagerten Beschreibungen mit BW sind nicht möglich oder doch?
Ich habe früher mit der V2.x div. Versuche unter Access unternommen, und dabei mehrere DBs aneinandergereiht und diese von BW auswerten lassen. Das hat mit Lesezugriffen sogar prima funktioniert, aber einzelne Abfragen über 1.2 MIO Datensätze mit gespeicherter Beschreibung (aufgeteilt auf 10 Access-DBs mit Union-Abfrage wieder zu einer virtuellen DB zusammen gefügt) haben schon mal 1 Std. und länger gedauert. Das war nicht praxistauglich und Schreibzugriffe waren nicht möglich. Das wird auch mit Deiner Lösung der Schwachpunkt sein? Und wenn man keine Suchen in der Beschreibung durchführen kann ist die Beschreibung auch eher unwichtig. Auch glaube ich, dass die Mischung von Access- und externen Tabellenfeldern (z.B. Nicht-Access SQL-Server-DBs) über Verknüpfungen mit nachgeschalteten Abfragen, wenn überhaupt, nur mit Klimmzügen geht.
Aber ich lasse mich da gerne belehren.
Ein anderer Ansatz wäre, den Ballast aus den Beschreibungen (z.B. unter Access mit einer Änderungsabfrage) löschen zu lassen und nur noch die Schlüsselwörter in der Beschreibung zu speichern, mit dem der Artikel gefunden wurden, wenn die Beschreibung dabei im Spiel war. Das würde die DB4 schlank lassen und es wäre die volle BW-Funktionalität gewährleistet. Das ist nicht für jeden die richtige Lösung und dürfte deshalb nur als Option wählbar sein.
Ferner: da BW V3 jetzt über eine zusätzlich Ordner-Tabelle, die mit der Auktions- (Artikel-)Tabelle verknüpft ist, verfügt, wäre eine Suche in der Beschreibung für einige Nutzer sicher entbehrlich, vorausgesetzt, die Ordnerstruktur wird vom User konsequent durchgesetzt (über Ordner-Subordner etc). Bei dieser Lösung bräuchte man die Beschreibung nicht abspeichern.
Insofern wären mehrere Lösungen für das Problem des DB-Limits vorhanden die alle mit „Hausmitteln“ umsetzbar sind.
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Hallo Borkumer,
Sven
Also, ich brauche die Artikelbeschreibungen von Auktionen im Jahre 2004 (meine ältesten) um Marktbeobachtung auszuführen. Die Angaben ohne Artikelbeschreibungen reichen dafür nicht aus, denn bei Tickets kommt es auch auf die Kategorieangaben an, die ich per eigener Software eben aus den Beschreibungen auslese und die Preise für unterschiedliche Kategorien können sehr unterschiedlich sein. D.h. eine Marktbeobachtung ist mit der BayWotch-Statistik, auch weil unterschiedliche Mengen pro Kaufaktion angeboten werden, nicht möglich (macht alles meine Software und die unterschiedlichen Formulierungen der Verkäufer automatisch einlesen zu lassen war eine Heidenarbeit).Borkumer hat geschrieben:Was ich noch nicht verstanden habe: möchtest Du die ausgelagerten Beschreibung nur archivieren? (wofür?)
Nein, nicht mit meiner Lösung (da die BayWotch-Anwendung im Gegensatz zur BayWotch-Datenbank ja wie eine BlackBox ist). Aber ich stelle mir eine Integration in BayWotch vor - wenn sich Elmar dazu überreden läßt - und dann könnte man zum einen das Holen der ausgelagerten Artikelbeschreibung jedesmal bei einem Klick auf eine Artikelbeschreibung auslösen (bzw. sogar nur virtuell ausführen, also nicht wirklich in die Zelle "article_desc" kopieren) und auch eine Suche wäre ohne Umweg in den Beschreibungen möglich (den Umweg mit meiner Lösung habe ich im Eingangsposting erklärt).Borkumer hat geschrieben:Lese- und/oder Schreibzugriffe auf die ausgelagerten Beschreibungen mit BW sind nicht möglich oder doch?
Ich habe zu Beginn der Entwicklung dieser Lösung Versuche unternommen der BlackBox BayWotch-Anwendung per Abfrage in der BayWotch-Datenbank die Tabelle tblAuction vorzugaukeln, wobei die Abfrage die ausgelagerten Artikelbeschreibungen eben virtuell wieder einschließt. Das wäre zwar fast schon die Ideallösung aber unglaublich langsam und ich kann mich jetzt gar nicht mehr erinnern, ob da Schreibzugriffe (Artikelabgleich) überhaupt möglich waren.Borkumer hat geschrieben:Ich habe früher mit der V2.x div. Versuche unter Access unternommen, und dabei mehrere DBs aneinandergereiht und diese von BW auswerten lassen. Das hat mit Lesezugriffen sogar prima funktioniert, aber einzelne Abfragen über 1.2 MIO Datensätze mit gespeicherter Beschreibung (aufgeteilt auf 10 Access-DBs mit Union-Abfrage wieder zu einer virtuellen DB zusammen gefügt) haben schon mal 1 Std. und länger gedauert. Das war nicht praxistauglich und Schreibzugriffe waren nicht möglich. Das wird auch mit Deiner Lösung der Schwachpunkt sein? Und wenn man keine Suchen in der Beschreibung durchführen kann ist die Beschreibung auch eher unwichtig.
Nun, für meinen Anwendungsfall ist es ideal und da ich Scheuklappen trage ;-) kenne ich natürlich die Anwendungsfälle von Euch allen anderen nicht. Es kann also durchaus sein, daß meine Lösung nur für mich praktikabel ist, aber dafür habe ich sie ja auch einfach mal veröffentlicht und vielleicht freut sich am Ende noch jemand, so wie ich mich selbst darüber gefreut habe! Denn vorher hatte ich glaube 3 einzelne DBs und wenn ein zu beobachtender Verkauf von Artikeln sich über diese DBs überlappte war das unglaublich umständlich (was ich ganz schnell vergessen möchte).Borkumer hat geschrieben:Auch glaube ich, dass die Mischung von Access- und externen Tabellenfeldern (z.B. Nicht-Access SQL-Server-DBs) über Verknüpfungen mit nachgeschalteten Abfragen, wenn überhaupt, nur mit Klimmzügen geht.
Genau. Das wäre eine Verfahrensweise die nach meinen Ansprüchen überhaupt nicht paßt.Borkumer hat geschrieben:Ein anderer Ansatz wäre, den Ballast aus den Beschreibungen (z.B. unter Access mit einer Änderungsabfrage) löschen zu lassen und nur noch die Schlüsselwörter in der Beschreibung zu speichern, mit dem der Artikel gefunden wurden, wenn die Beschreibung dabei im Spiel war. Das würde die DB4 schlank lassen und es wäre die volle BW-Funktionalität gewährleistet. Das ist nicht für jeden die richtige Lösung und dürfte deshalb nur als Option wählbar sein.
Geht bei mir, siehe oben, eben auch nicht. Die Ordner habe ich nur wegen der einzelnen Suchen in verschiedenen eBay-Kategorien. Danach könnte ich sie eigentlich vergessen.Borkumer hat geschrieben:Ferner: da BW V3 jetzt über eine zusätzlich Ordner-Tabelle, die mit der Auktions- (Artikel-)Tabelle verknüpft ist, verfügt, wäre eine Suche in der Beschreibung für einige Nutzer sicher entbehrlich, vorausgesetzt, die Ordnerstruktur wird vom User konsequent durchgesetzt (über Ordner-Subordner etc). Bei dieser Lösung bräuchte man die Beschreibung nicht abspeichern.
Das ist richtig und hier im Forum wurden ja schon einige veröffentlicht, die aber, soweit ich das überblicke, auch immer auf der Auslagerung der Artikelbeschreibungen beruhen.Borkumer hat geschrieben:Insofern wären mehrere Lösungen für das Problem des DB-Limits vorhanden die alle mit „Hausmitteln“ umsetzbar sind.
Sven
Hallo Sven!
Der Nebel hat sich gelüftet!
Auch glaube ich, dass Deine Wünsche am besten unter Access zu verwirklichen sind. BW ist da doch zu allgemein und deshalb auch zu unflexibel. Auf der anderen Seite ist ab und an sicher Feintuning angebracht, was BW überhaupt nicht leisten kann. Deshalb die ketzerische Frage, wofür brauchst Du, sobald die finalen Daten eingelesen und gespeichert sind noch BW? Ich würde bei diesen speziellen Auswertungen BW eher wie einen Klotz am Bein empfinden (ohne BW damit schlecht machen zu wollen). Der direkte Zugriff auf die DB4 ermöglicht mir alles das was BW auch kann, nur eben genau auf meine Bedürfnisse angepaßt. Alles was nicht mit der DB sondern mit eBay zu tun hat wäre dann wieder ein Fall für BW ( die div. Links auf ebay (Käufer; Verkäufer, Artikel, Kategorie usw.), Übergabe der Daten an "Schnapper" und so was meine ich damit).
Der Nebel hat sich gelüftet!
Genau richtig: dauert ewig und drei Tage und nur Lesezugriffe sind möglich was eigentlich nicht schlimm wäre, wenn man zum Speichern die "normale" DB4 nimmt und zum Lesen über alles die virtuelle DB. Aber Wartezeiten von bis zu 2Std. für eine Abfrage....das wird nicht gehen!Ich habe zu Beginn der Entwicklung dieser Lösung Versuche unternommen der BlackBox BayWotch-Anwendung per Abfrage in der BayWotch-Datenbank die Tabelle tblAuction vorzugaukeln, wobei die Abfrage die ausgelagerten Artikelbeschreibungen eben virtuell wieder einschließt. Das wäre zwar fast schon die Ideallösung aber unglaublich langsam und ich kann mich jetzt gar nicht mehr erinnern, ob da Schreibzugriffe (Artikelabgleich) überhaupt möglich waren.
Auch glaube ich, dass Deine Wünsche am besten unter Access zu verwirklichen sind. BW ist da doch zu allgemein und deshalb auch zu unflexibel. Auf der anderen Seite ist ab und an sicher Feintuning angebracht, was BW überhaupt nicht leisten kann. Deshalb die ketzerische Frage, wofür brauchst Du, sobald die finalen Daten eingelesen und gespeichert sind noch BW? Ich würde bei diesen speziellen Auswertungen BW eher wie einen Klotz am Bein empfinden (ohne BW damit schlecht machen zu wollen). Der direkte Zugriff auf die DB4 ermöglicht mir alles das was BW auch kann, nur eben genau auf meine Bedürfnisse angepaßt. Alles was nicht mit der DB sondern mit eBay zu tun hat wäre dann wieder ein Fall für BW ( die div. Links auf ebay (Käufer; Verkäufer, Artikel, Kategorie usw.), Übergabe der Daten an "Schnapper" und so was meine ich damit).
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Hi Borkumer,
(@Elmar: Keine Angst) ich brauche BW noch außer zum Datenholen für genau die Fälle wo meine Software noch nicht in der Lage ist die 'handgeschriebenen' Artikelbeschreibungen korrekt auszulesen, und das passiert trotz aller Mühen immer noch oft genug. Außerdem dauert dieses Auslesen auch seine Zeit, so daß mir BayWotch für eine schnelle Entscheidung (Kaufen oder nicht Kaufen) immer noch auch einen schnellen Marktüberblick gibt. Und schnelle Entscheidungen sind oft nötig um später ein gutes Geschäft zu machen...
Somit ist das dann auch die Erklärung warum ich uralte Artikelbeschreibungen noch selbst lesen will - ich will ja auch wissen wie die Konkurrenz arbeitet, wie sie designd und welche Angaben sie so in ihren Angeboten macht - und dafür ist die Ansicht in BayWotch einfach am übersichtlichsten. Muß ich dann nicht selber programmieren, genauso wie die Suchfunktionen...
Sven
(@Elmar: Keine Angst) ich brauche BW noch außer zum Datenholen für genau die Fälle wo meine Software noch nicht in der Lage ist die 'handgeschriebenen' Artikelbeschreibungen korrekt auszulesen, und das passiert trotz aller Mühen immer noch oft genug. Außerdem dauert dieses Auslesen auch seine Zeit, so daß mir BayWotch für eine schnelle Entscheidung (Kaufen oder nicht Kaufen) immer noch auch einen schnellen Marktüberblick gibt. Und schnelle Entscheidungen sind oft nötig um später ein gutes Geschäft zu machen...
Somit ist das dann auch die Erklärung warum ich uralte Artikelbeschreibungen noch selbst lesen will - ich will ja auch wissen wie die Konkurrenz arbeitet, wie sie designd und welche Angaben sie so in ihren Angeboten macht - und dafür ist die Ansicht in BayWotch einfach am übersichtlichsten. Muß ich dann nicht selber programmieren, genauso wie die Suchfunktionen...
Sven
falls du nur für die einzelanzeige eine einbindung der externen datenbank benötigts, dann könnte man mit elmar verhandeln, daß die erstellung der einzelanzeige (also export der HTML-Datei mit füllung der Platzhalter aus dem template) über eine abfrage erfolgt.
standartmäßig ist diese abfrage nur mit einem:
Abfrage:
Name: qryTblAuction oder qryAuctionDisplay
SQL: select * from tblAuction
so braucht er dann nur diese anzeige entsprechend aufrufen.
zum einbinden deiner externen Daten kannst du dann selbst diese Abfrage anpassen.
falls du aber nur die Artikeldaten auslagern möchtest und dann auch direkt anzeigen möchtest, so darf ich auch auf meine lösung hinweisen:
BayWotch Support Forum Foren-Übersicht
-> Snippets, Scripte und 3rd Party Tools
-> Snippet: Auslagerung der Artikelbeschreibung auf Festplatte
http://www.baywotch.de/phpbb/viewtopic.php?t=1271
standartmäßig ist diese abfrage nur mit einem:
Abfrage:
Name: qryTblAuction oder qryAuctionDisplay
SQL: select * from tblAuction
so braucht er dann nur diese anzeige entsprechend aufrufen.
zum einbinden deiner externen Daten kannst du dann selbst diese Abfrage anpassen.
falls du aber nur die Artikeldaten auslagern möchtest und dann auch direkt anzeigen möchtest, so darf ich auch auf meine lösung hinweisen:
BayWotch Support Forum Foren-Übersicht
-> Snippets, Scripte und 3rd Party Tools
-> Snippet: Auslagerung der Artikelbeschreibung auf Festplatte
http://www.baywotch.de/phpbb/viewtopic.php?t=1271
Hallo Mischa,
Und daher verstehe ich auch leider nicht was Du sagen willst.
Sven
ich weiß nicht so recht auf was Du Dich beziehst...Mischa hat geschrieben:falls du nur für die einzelanzeige eine einbindung der externen datenbank benötigts, dann könnte man mit elmar verhandeln, daß die erstellung der einzelanzeige (also export der HTML-Datei mit füllung der Platzhalter aus dem template) über eine abfrage erfolgt.
standartmäßig ist diese abfrage nur mit einem:
Abfrage:
Name: qryTblAuction oder qryAuctionDisplay
SQL: select * from tblAuction
so braucht er dann nur diese anzeige entsprechend aufrufen.
zum einbinden deiner externen Daten kannst du dann selbst diese Abfrage anpassen.
Und daher verstehe ich auch leider nicht was Du sagen willst.
Deine Lösung kenne ich und habe mich auch ein wenig damit befasst. Der Nachteil zu meiner ist aber, daß ich die Artikelbeschreibungen für eine Suche in diesen nicht so einfach zurückholen kann (müßte noch programmiert werden) und für die Verarbeitung der Daten in meiner eigenen Software ist es auch eleganter. Desweiteren muß man bei einem Update der veränderten Dateien von BayWotch aufpassen und in meinem Fall sehe ich da bis auf weiteres kein Problem, außer an dem Feld mit der Artikelnummer oder der Beschreibung ändert sich irgendwas.Mischa hat geschrieben:falls du aber nur die Artikeldaten auslagern möchtest und dann auch direkt anzeigen möchtest, so darf ich auch auf meine lösung hinweisen:
BayWotch Support Forum Foren-Übersicht
-> Snippets, Scripte und 3rd Party Tools
-> Snippet: Auslagerung der Artikelbeschreibung auf Festplatte
http://www.baywotch.de/phpbb/viewtopic.php?t=1271
Sven
1) Lösung Auslagerung auf SQL-Server
bei dieser idee geht es nur um die anzeige der detail-daten (incl. auktionsbeschreibung) ohne sie direkt erst in baywotch-datenbank kopieren zu müssen.
hierfür wird dann nur bei der anzeige der detaildaten (also generierung der temprären HTML-Datei, die dann bei Artikeldetails anzeigt wird) auf eine abfrage zugegriffen, bei der dann die Detail-Daten aus dem SQL-Server hinzu-gejoint werden können.
das wäre dann für den normalen betrieb interessant, wenn nicht in der beschreibung gesucht werden muß, aber man sich für die artikeldetails interessiert.
und es ist eine kleine änderung bei baywotch, die ohne viel programmierung durchgeführt werden kann. (abfrage erstellen + diese dann für die generierung der Artikeldetails auswählen)
eine suche in den artikeldetails geht dann auch nicht.
2) Lösung auf Festplatte
ich dachte du brauchst die daten nur, um sie anzuzeigen. für eine suche in den daten ist meine lösung nicht geeignet.
beim sql-server ist auch wichtig, daß man eine vollversion vom sql server hat, ansonsten besteht beim SQL-Server express auch die 2 GB Grenze.
aber so wie ich das verstehe hast du ja einen unbegrenzten SQL-Server zur hand, so daß für dich die Enterprise-Version interessant sein könnte, da damit direkt auf den SQL-Server zugegriffen werden kann.
bei dieser idee geht es nur um die anzeige der detail-daten (incl. auktionsbeschreibung) ohne sie direkt erst in baywotch-datenbank kopieren zu müssen.
hierfür wird dann nur bei der anzeige der detaildaten (also generierung der temprären HTML-Datei, die dann bei Artikeldetails anzeigt wird) auf eine abfrage zugegriffen, bei der dann die Detail-Daten aus dem SQL-Server hinzu-gejoint werden können.
das wäre dann für den normalen betrieb interessant, wenn nicht in der beschreibung gesucht werden muß, aber man sich für die artikeldetails interessiert.
und es ist eine kleine änderung bei baywotch, die ohne viel programmierung durchgeführt werden kann. (abfrage erstellen + diese dann für die generierung der Artikeldetails auswählen)
eine suche in den artikeldetails geht dann auch nicht.
2) Lösung auf Festplatte
ich dachte du brauchst die daten nur, um sie anzuzeigen. für eine suche in den daten ist meine lösung nicht geeignet.
beim sql-server ist auch wichtig, daß man eine vollversion vom sql server hat, ansonsten besteht beim SQL-Server express auch die 2 GB Grenze.
aber so wie ich das verstehe hast du ja einen unbegrenzten SQL-Server zur hand, so daß für dich die Enterprise-Version interessant sein könnte, da damit direkt auf den SQL-Server zugegriffen werden kann.
Hallo Mischa,
ja, jetzt verstehe ich was Du meinst. Ja, diese Lösung schwebt mir auch vor, wäre viel eleganter (als erst nach jeder Suche reinzuholen) und diesen Gedanken habe ich Elmar guasi auch schon mitgeteilt, als ich ihm meine Lösung zuerst offerierte. Sie stand dann hier noch nicht drin weil dieser Weg zu weit vorgegriffen wäre. Aber danke für Deinen Gedanken.
Ansonsten nutze ich derzeit die Evaluation-Version des MS-SQL-Servers 2000. Die hat - irgendwie - weniger Einschränkungen als die anderen 2000er Versionen gegen Löhnung. Und so weit ich weiß gibt es kostenlose SQL-Server-Lösungen weswegen das Ganze Sinn macht wenn man sich die Enterprise-Version von BayWotch nicht leisten kann oder will (sonst hätte ich ja einfach und fertig).
Sven
ja, jetzt verstehe ich was Du meinst. Ja, diese Lösung schwebt mir auch vor, wäre viel eleganter (als erst nach jeder Suche reinzuholen) und diesen Gedanken habe ich Elmar guasi auch schon mitgeteilt, als ich ihm meine Lösung zuerst offerierte. Sie stand dann hier noch nicht drin weil dieser Weg zu weit vorgegriffen wäre. Aber danke für Deinen Gedanken.
Ansonsten nutze ich derzeit die Evaluation-Version des MS-SQL-Servers 2000. Die hat - irgendwie - weniger Einschränkungen als die anderen 2000er Versionen gegen Löhnung. Und so weit ich weiß gibt es kostenlose SQL-Server-Lösungen weswegen das Ganze Sinn macht wenn man sich die Enterprise-Version von BayWotch nicht leisten kann oder will (sonst hätte ich ja einfach und fertig).
Sven
die kostenlose SQL-Server-Variante hat auch wie die SQL Server Express (ich glaub das ist diese) genauso wie Access eine begrenzte kapazität von 2GB. also ist damit nicht viel geholfen :-(
außer man verteilt das dann wieder auf verschiedene datenbanken was das ganze aber genauso schwierig macht, wie mit access-datenbanken. man hat also keinen vorteil davon, ob man nun sql-server oder eine neu erstellte access-datenbank für die auslagerung nimmt.
außer man verteilt das dann wieder auf verschiedene datenbanken was das ganze aber genauso schwierig macht, wie mit access-datenbanken. man hat also keinen vorteil davon, ob man nun sql-server oder eine neu erstellte access-datenbank für die auslagerung nimmt.
richtig MySQL ist kostenfrei ...
auch fix nachgeschaut bei version 5.1 in der doku:
http://dev.mysql.com/doc/refman/5.1/en/table-size.html
FileSize:
Win32 w/ FAT/FAT32: 2GB/4GB
Win32 w/ NTFS: 2TB (possibly larger)
aber:
eine Tabelle kann bei InnoDB auf mehrere Files verteilt werden.
auch fix nachgeschaut bei version 5.1 in der doku:
http://dev.mysql.com/doc/refman/5.1/en/table-size.html
FileSize:
Win32 w/ FAT/FAT32: 2GB/4GB
Win32 w/ NTFS: 2TB (possibly larger)
aber:
eine Tabelle kann bei InnoDB auf mehrere Files verteilt werden.
Hallo Mischa!
Access behandelt Abfragen wie Tabellen deshalb sind auch Abfragen mit Tabellen-Namen nicht möglich. BW arbeitet auch mit einer Abfrage die "tblAuction" heißt. Hab div. Male BW eine virtuelle DB damit vorgegaukelt (Union-Abfrage (nur Lesezugriffe))
Access behandelt Abfragen wie Tabellen deshalb sind auch Abfragen mit Tabellen-Namen nicht möglich. BW arbeitet auch mit einer Abfrage die "tblAuction" heißt. Hab div. Male BW eine virtuelle DB damit vorgegaukelt (Union-Abfrage (nur Lesezugriffe))
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)