Paradox-Fehler: BLOB wurde geändert
Thomas Irmler
bei der Entwicklung unter einer Datenbankanwendung unter Delphi 5 erhalte
ich von Zeit zu Zeit die Fehlermeldung "BLOB wurde geändert". In diesem
Zusammenhang ist nachfolgend ein in einer Paradox-Tabelle befindliches
Memofeld (Feldtype: M 5) zerstört. Bei Zugriffsversuch darauf kommt entweder
die o.g. Fehlermeldung, manchmal stürzt das Programm auch vollständig ab.
Weiß jemand wo ich nähere Informationen zu diesem Fehler finden kann bzw.
wieso es überhaupt dazu kommen kann (die BDE müsste doch eigentlich die
Konsistenz der Daten und einen korrekten Zugriff sicherstellen !?)
Zusatzfrage: Welche Möglichkeiten gibt es, eine derart beschädigte Tabelle
zu reparieren ?
Vielen Dank für Eure Hilfe schon mal vorab....
Thomas
Marian Aldenhövel
> Weiß jemand wo ich nähere Informationen zu diesem Fehler finden kann
Das ist einer der ständigen Begleiter bei der Entwicklung mit Paradox. Frag
Google.
> (die BDE müsste doch eigentlich die Konsistenz der Daten und
> einen korrekten Zugriff sicherstellen !?)
Paradox ist ein Desktop-Datenbanksystem, das nicht wirklich für sicheren
Mehrbenutzerbetrieb konzipiert ist. Manchmal geht es zwar trotzdem gut,
aber empfehlenswert ist es nicht.
> Zusatzfrage: Welche Möglichkeiten gibt es, eine derart beschädigte Tabelle
> zu reparieren?
Stichwort: TUtil32. Damit bewaffnet solltest Du Code, DLLs und fertige
Software finden.
Da dauerndes Reparieren von Tabellen keinen Spaß macht und da außerdem die
Konfigurationstips, die das verhindern sollen, das Problem zwar in manchen
Fällen reduzieren, aber nicht völlig lösen können, lautet die dringende
Empfehlung: Nimm eine andere Datenbank.
Ich würde Dir zu einer "richtigen Datenbank" wie Interbase raten, gute
Erfahrungen haben einige Leute auch mit DBISAM gemacht. Ralf!
Ciao, MM
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn
Mein Flug um die Welt (aktuelle Position: Nellis AFB, NV)
http://www.marian-aldenhoevel.de/ATW
Achim Kalwa
Thomas Irmler wrote:
> bei der Entwicklung unter einer Datenbankanwendung unter Delphi 5 erhalte
> ich von Zeit zu Zeit die Fehlermeldung "BLOB wurde geändert". In diesem
> Zusammenhang ist nachfolgend ein in einer Paradox-Tabelle befindliches
> Memofeld (Feldtype: M 5) zerstört. Bei Zugriffsversuch darauf kommt entweder
> die o.g. Fehlermeldung, manchmal stürzt das Programm auch vollständig ab.
Hast Du die Datentabellen lokal oder auf einem Netzwerk-Laufwerk liegen?
Falls Netzwerk-LW: Novell oder Windows? Bei einem Novell-4.x-LW habe ich
das Problem *nie* gehabt, auf einem Windows NT4/2000-Server aber mind.
2x die Woche.
> Weiß jemand wo ich nähere Informationen zu diesem Fehler finden kann bzw.
> wieso es überhaupt dazu kommen kann (die BDE müsste doch eigentlich die
> Konsistenz der Daten und einen korrekten Zugriff sicherstellen !?)
Ja, "müsste" und "eigentlich". Es hat was mit dem Opportunistic Locking
zu tun: http://community.borland.com/article/0,1410,15209,00.html
> Zusatzfrage: Welche Möglichkeiten gibt es, eine derart beschädigte Tabelle
> zu reparieren ?
http://info.borland.com/devsupport/bde/utilities.html
und dort nach TUtility Ausschau halten. Es gibt auf der gleichen Seite
auch Beispielcode für ein Reparaturprogramm (tutil32d_package.zip). Aber
aus Erfahrung kann ich Dir sagen, dass die "Reparatur" darin besteht,
die defekten Sätze aus der Tabelle zu löschen...
> Vielen Dank für Eure Hilfe schon mal vorab....
Die einzige *wirkliche* Hilfe die ich Dir geben kann:
Verzichte so schnell wie möglich auf die Paradox-BDE-Datenbank. Stelle
auf ein anderes DB-System um, solange es noch nicht so stark schmerzt.
Ich spreche wirklich aus Erfahrung: Wenn Du täglich(!) bei 2 bis 4
Kunden telefonisch eine DB-Reparatur durchführen musst, hast Du keine
Zeit mehr für die Umstellung auf z.B. Interbase/Firebird.
Ich bin wirklich froh, vor 3 Jahren den Paradox-Schrott in die Tonne
getreten und auf Interbase umgestellt zu haben. Mittlerweile ist
Interbase unter dem Namen "Firebird" als OpenSource-Datenbank verfügbar,
welche Du ohne Lizenzkosten beim Kunden einsetzen kannst.
Der Umstieg von Paradox auf Interbase ist nicht trivial, aber durchaus
zu handeln. Das wichtigste vorab: Verzichte so weit es geht auf TTable
und verwende TQuery, sonst wird Deine Anwendung ein Resourcenfresser und
schnarchlangsam. Oder gehe noch einen Schritt weiter und entsorge auch
die BDE und nimm statt dessen IB-Objects (http://www.ibobjects.com).
Achim
Ralf Mimoun
Marian Aldenhövel <mar...@mba-software.de> wrote:
...
> Ich würde Dir zu einer "richtigen Datenbank" wie Interbase raten, gute
> Erfahrungen haben einige Leute auch mit DBISAM gemacht. Ralf!
Ja, hier? Nebenbei bemerkt kann DBISAM auch eine "richtige" Datenbank sein,
da es auch eine C/S-Version gibt. Ein 5-Connection-Server ist sogar bei der
kleinsten Version gratis dabei. Das Umschalten von dateibasiert auf C/S
erfolgt in 3, 4 Zeilen Code, da nur wenige Properties (wer ist Server,
Username, Passwort) gesetzt werden müssen.
Aber auch im "Datei-Modus" ist DBISAM sehr stabil. Ich hab einige
Anwendungen bei Kunden, die in der Woche 40 Stunden ackern, mit
hunderttausenden von Datensätzen und einer Menge Zugriffen. Es gibt absolut
keine Probleme.
Bye, Ralf
Ingo Balzer
Re: Paradox-Fehler: BLOB wurde geändert:
> Moin!
> Marian Aldenhövel <mar...@mba-software.de> wrote:
> ...
>> Ich würde Dir zu einer "richtigen Datenbank" wie Interbase raten, gute
>> Erfahrungen haben einige Leute auch mit DBISAM gemacht. Ralf!
Ich habe vor vielen Jahren, irgendwann Anfang der 90er noch unter
Turbo-Pascal mit 'ner B-Tree-ISAM-DB (ENZ - EDV Beratung GmbH)
gearbeitet. Letzte Version war glaub ich für TP 5.0. Die Fa. ging, soweit
ich weiß, um 95 Pleite. Ist DBISAM damit irgendwie vergleichbar?
Vielleicht kennt ja noch jemand diese ENZ-DB, gab es auch für Modula.
Ich habe eine ziemliche Weile ausgesetzt mit dem Programmieren und erst
im letzten Jahr ernsthaft wieder angefangen. Natürlich auch
DB-Anwendungen, die allerdings keine netzwerkfähige DB benötigen. Paradox
hielt ich bisher für ziemlich universell. Wenn ich aber die Meinungen
hier lese, kommen mir langsam Zweifel, obwohl ich bisher keine negativen
Erlebnisse hatte.
Was ist denn so schlimm an Paradox, wenn man mal die Netzwerkfähigkeit
außer Acht läßt, bei der man mit einer C/S-Variante sicher besser fährt ?
Gruß Ingo
Ingo Balzer
Re: Paradox-Fehler: BLOB wurde geändert:
> Was ist denn so schlimm an Paradox, wenn man mal die Netzwerkfähigkeit
> außer Acht läßt, bei der man mit einer C/S-Variante sicher besser fährt ?
Tschuldigung,
ist vielleicht etwas zu oberflächlich, ich habe ja hier und an anderen
Stellen mitgelesen. Was ich aber las, war meist recht subjektiv und
insbesondere meist abhängig von bestimmten Gegebenheiten.
Ich brauche eine Universal-DB, die keine besonderen Anforderungen
erfüllen muß. An sich würde mir Paradox, was die Eigenschaften betrifft,
genügen. Insbesondere ist eine Netzwerkfähigkeit nicht unbedingt
erforderlich.
Also nochmal, was ist so schlimm an Paradox? Und hier meine ich, welch
reproduzierbare Gemeinheiten erwarten mich genrell, wenn ich Paradox als
Desktop-DB einsetze? Wozu ist Paradox brauchbar, wo wären die Grenzen?
Welche alternativen Desktop-DB's gibt es, die eben die Mängel von Paradox
nicht haben? Ist Access als Alternative brauchbar?
Ich will nicht unbedingt eine Diskussion lostreten, eine Handvoll von
relevanten Übersichts-Artikeln würde mir schon reichen, um nicht einen
riesigen Suchaufwand mit Google starten zu müssen.
Gruß Ingo
Ralf Mimoun
Ingo Balzer <con...@ibalzer.de> wrote:
...
> Ich habe vor vielen Jahren, irgendwann Anfang der 90er noch unter
> Turbo-Pascal mit 'ner B-Tree-ISAM-DB (ENZ - EDV Beratung GmbH)
> gearbeitet. Letzte Version war glaub ich für TP 5.0. Die Fa. ging,
> soweit ich weiß, um 95 Pleite. Ist DBISAM damit irgendwie
> vergleichbar?
Nö, die Namensähnlichkeit zu ISAM ist zufällig. Und auch sonst gibt es
keinen Zusammenhang, außer daß all diese System auf die eine oder andere
Weise Daten speichern.
...
> Paradox hielt ich bisher für ziemlich universell. Wenn ich aber die
> Meinungen hier lese, kommen mir langsam Zweifel, obwohl ich bisher
> keine negativen Erlebnisse hatte.
Bis Du mal einen Windows-Server und/oder Multi-User-Zugriffe hast. Oder RI -
die ganzen Indexe gehen gern vor die Hunde.
> Was ist denn so schlimm an Paradox, wenn man mal die Netzwerkfähigkeit
> außer Acht läßt, bei der man mit einer C/S-Variante sicher besser
> fährt ?
Daß es auch bei einem Single-User-System trotz heftigstem Einsatz aller
Tricks und Kniffe nicht auszuschliessen ist, daß bei der wöchentlichen
Reparatur Fehler gefunden werden. Meist würde das Programm erstmal trotzdem
weiterlaufen, aber Vertrauen ist anders. Ach ja, und das leidige
BDE-Problem. Wenn der User eine Software draufspielt, die Settings ändert
oder noch böser eine unpassende BDE-Version installiert, ist Hängen im
Schacht. Das will ich nie wieder erleben, denn irgendwann wird der Kunde
leicht ungeduldig.
Bye, Ralf
Ralf Mimoun
Ingo Balzer <con...@ibalzer.de> wrote:
...
> ist vielleicht etwas zu oberflächlich, ich habe ja hier und an anderen
> Stellen mitgelesen. Was ich aber las, war meist recht subjektiv und
> insbesondere meist abhängig von bestimmten Gegebenheiten.
Naja, wenn 80% der Projekte größere Probleme machen, ist das zwar subjektiv,
aber für mich Grund genug, das DB-System zu wechseln. Die anderen 20%
machten einfach nur weniger Ärger (ein paar mal im Jahr anstelle 1-4x im
Monat). Und es wurde wirklich alles genutzt, was Borland zur Stabilisierung
empfiehlt.
> Ich brauche eine Universal-DB, die keine besonderen Anforderungen
> erfüllen muß. An sich würde mir Paradox, was die Eigenschaften
> betrifft, genügen. Insbesondere ist eine Netzwerkfähigkeit nicht
> unbedingt erforderlich.
Da gibts verschiedene Systeme. Von Oracle/MSSQL/Interbase (rein C/S mit
eigener Client-Installation) über ADS (geht auch ohne Server [der auch etwas
kostet], und die Client/Lokal-Installationb besteht aus wenigen DLLs, die
man einfach rüberkopieren kann) bis zu DBISAM (genau null
Installationsaufwand, null DLLs oder Client-Software, aber bei Bedarf auch
C/S-fähig - und immer noch null Installation auf Client-Seite).
> Also nochmal, was ist so schlimm an Paradox?
Daß Daten verloren gehen. Daß Programme aus heiterem Himmel stehen bleiben.
Daß so etwas sehr oft passiert. Reicht das?
> Und hier meine ich, welch
> reproduzierbare Gemeinheiten erwarten mich genrell, wenn ich Paradox
> als Desktop-DB einsetze?
Reproduzierbar ist das meist nicht einmal, aber Du wirst damit zu kämpfen
haben.
> Wozu ist Paradox brauchbar, wo wären die
> Grenzen?
Brauchbar? Gar nicht. Naja, vielleicht um Daten aus älteren Anwendungen mit
Paradox-DB zu übernehmen.
> Welche alternativen Desktop-DB's gibt es, die eben die
> Mängel von Paradox nicht haben?
ADS oder DBISAM. Und noch ein paar andere, wie Apollo, TurboDB, FlashFiler
(wobei FlashFiler wegen der aktuellen Situation vielleicht nicht jedermanns
Sache ist).
> Ist Access als Alternative brauchbar?
Hm. Wenn Du ADO zum Zugriff benutzt, mußt Du sicherstellen, daß es in der
richtigen Version auf dem Zielsystem installiert ist. Außerdem benötigst Du
eine Access-Entwickler-Version. Unter älteren Windows-Versionen kann es
problematisch werden.
> Ich will nicht unbedingt eine Diskussion lostreten, eine Handvoll von
> relevanten Übersichts-Artikeln würde mir schon reichen, um nicht einen
> riesigen Suchaufwand mit Google starten zu müssen.
Das wird Dir wohl nicht erspart bleiben. Wenn ich in den NGs nach "Delphi
Paradox BDE problem" suche und ca. 12.700 Treffer kommen, weiß ich, daß ich
mit meiner Meinung nicht allein dastehe.
Bye, Ralf
Ingo Balzer
Re: Paradox-Fehler: BLOB wurde geändert:
> Das will ich nie wieder erleben, denn irgendwann wird der Kunde
> leicht ungeduldig.
Wie wahr!
Gruß Ingo
Ingo Balzer
Re: Paradox-Fehler: BLOB wurde geändert:
> Naja, wenn 80% der Projekte größere Probleme machen, ist das zwar subjektiv,
> aber für mich Grund genug, das DB-System zu wechseln.
Hmm, 80% würde ich nicht mehr als subjektiv ansehen
>> Ich brauche eine Universal-DB, die keine besonderen Anforderungen
>> erfüllen muß. An sich würde mir Paradox, was die Eigenschaften
>> betrifft, genügen. Insbesondere ist eine Netzwerkfähigkeit nicht
>> unbedingt erforderlich.
> Da gibts verschiedene Systeme...
Schwierig. Ich will meine Anwendungen weitergeben und die Empfänger haben
absolut keine Ahnung von EDV. Die wissen mit Begriffen wie Client und
Server nichts anzufangen. Schon die Existenz von irgendwelchen
unbekannten Symbolen im Systray führt zu Ohnmachtsanfällen.
>> Also nochmal, was ist so schlimm an Paradox?
> Daß Daten verloren gehen. Daß Programme aus heiterem Himmel stehen bleiben.
> Daß so etwas sehr oft passiert. Reicht das?
OK. Das reicht allemale.
>> Wozu ist Paradox brauchbar, wo wären die
>> Grenzen?
> Brauchbar? Gar nicht. Naja, vielleicht um Daten aus älteren Anwendungen mit
> Paradox-DB zu übernehmen.
Du stürzt mich in eine tiefe Krise! Ich hatte zumindest angenommen, daß
Paradox wenigstens unter Standardbedingungen stabil arbeitet, wenn ich
alle Operationen wirklich kontrolliere (z.b. Öffnen, Schließen), keine
übermäßigen Indexoperationen wage, usw...
>> um nicht einen
>> riesigen Suchaufwand mit Google starten zu müssen.
> Das wird Dir wohl nicht erspart bleiben. Wenn ich in den NGs nach "Delphi
> Paradox BDE problem" suche und ca. 12.700 Treffer kommen, weiß ich, daß ich
> mit meiner Meinung nicht allein dastehe.
Na prima, das ist genau das, was ich meinte :-(
Hilft mir aber trotzdem weiter, Danke.
Gruß Ingo
Thomas Irmler
news:avm62...@hamster.winkhaus.de...
> Hast Du die Datentabellen lokal oder auf einem Netzwerk-Laufwerk liegen?
> Falls Netzwerk-LW: Novell oder Windows? Bei einem Novell-4.x-LW habe ich
> das Problem *nie* gehabt, auf einem Windows NT4/2000-Server aber mind.
> 2x die Woche.
Die Datenbank liegt lediglich lokal, ausserdem ist sie eher trivial (nur 6
Tabellen). Es geht hierbei leldiglich um eine kleine DB-Anwendung, welche
von Privatanwendern eingesetzt werden soll (schätzungsweise: 2000
Datensätze).
> Die einzige *wirkliche* Hilfe die ich Dir geben kann:
> Verzichte so schnell wie möglich auf die Paradox-BDE-Datenbank. Stelle
> auf ein anderes DB-System um, solange es noch nicht so stark schmerzt.
> Ich spreche wirklich aus Erfahrung: Wenn Du täglich(!) bei 2 bis 4
> Kunden telefonisch eine DB-Reparatur durchführen musst, hast Du keine
> Zeit mehr für die Umstellung auf z.B. Interbase/Firebird.
Ich selbst hatte bislang mit Paradox wenig Probleme, allerdings wurden die
meisten Projekte nicht von einer größeren Anzahl Personen sowie unter
höherer Auslastung verwendet. Nachdem was ich jetzt hier so lese, werde ich
wohl tatsächlich auf ein anderes lizenzfreies DB-System wechseln.
Gruß
Thomas
Marian Aldenhövel
> Was ist denn so schlimm an Paradox, wenn man mal die Netzwerkfähigkeit
> außer Acht läßt, bei der man mit einer C/S-Variante sicher besser fährt?
Schlimm ist nix dran. Es gibt aber einfach bessere Alternativen.
Wenn man weiß, daß man es immer mit einem Einzelplatz zu tun haben wird,
und/oder um die Fallstricke weiß und vorbereitet ist auf die Probleme, die
eben immer wieder auftreten, dann kann man es nehmen.
Andererseits ist es ja nicht mehr so, daß die Definition einer richtigen
Datenbanken lautet "kostet viele Mäuse, braucht eine eigene Maschine und
einen Menschen, der auf diese aufpasst". Deshalb kann man gleich richtig
anfangen, denn schnell zusammengehackte Programme sterben entweder oder sie
wachsen, und dann ist man froh wenn man nicht die DB-Schicht auswechseln
muss.
Für mich gibt es nur noch die Entscheidung zwischen "eigenes Datenformat"
oder "ordentlicher Datenbank". Letzteres heißt aus Gewohnheit dann meistens
InterBase, aber das ist Geschmackssache und kann je nach Projekt auch
anders lauten. Also entweder alles vollständig selber machen, oder alles
komplett an ein anderes Programm delegieren.
Ingo Balzer
<mar...@mba-software.de>
zum Thema Re: Paradox-Fehler: BLOB wurde geändert:
>> Was ist denn so schlimm an Paradox, wenn man mal die Netzwerkfähigkeit
>> außer Acht läßt, bei der man mit einer C/S-Variante sicher besser fährt?
> Schlimm ist nix dran. Es gibt aber einfach bessere Alternativen.
> Wenn man weiß, daß man es immer mit einem Einzelplatz zu tun haben wird,
> und/oder um die Fallstricke weiß und vorbereitet ist auf die Probleme, die
> eben immer wieder auftreten, dann kann man es nehmen.
Also doch Paradox:
Ich habe das Los auf mich genommen und zum Thema "Paradox-Probleme"
gegoogelt. Nach Durchsicht einiger hundert Einträge habe ich
festgestellt, daß sich ca. 2 Drittel um Programmierfragen handelte und
das restliche Drittel Probleme äußerte, die sich aber bis auf wenige
Ausnahmen (dann aber wiederum keine Einzelheiten) um Netzwerkeinsatz
rankten.
Was mich an den pauschalen negativen Aussagen zu Paradox irritiert, ist
die
Tatsache, daß kaum etwas Konkretes gesagt wird. Im Netz finden sich bei
Google
dann auch hunderte Beiträge, bei denen Paradox zufriedenstellend local
und
auch im Netz professionell zum Einsatz kommt.
> Andererseits ist es ja nicht mehr so, daß die Definition einer richtigen
> Datenbanken lautet "kostet viele Mäuse, braucht eine eigene Maschine und
> einen Menschen, der auf diese aufpasst".
Ja gut, aber für eine DB-Anwendung, die selten mehr als 1000 Datensätze
zu verwalten hat, ist eine DB in der Art von Interbase einfach mit
Kanonen auf Spatzen schießen.
Was also wäre die bessere Alternative für eine Desktop-DB, die möglichst
genauso universell ist wie dBase und Paradox? Sind es TurboDB, DBISAM?
Eine Eintagsfliege oder Bastel-Lösung sollte es natürlich auch nicht
sein.
> Für mich gibt es nur noch die Entscheidung zwischen "eigenes Datenformat"
> oder "ordentlicher Datenbank".
Bei C/S wäre für mich Interbase auch die richtige Wahl, aber alles selber
schreiben? Das bringt doch wieder einen Haufen anderer Probleme,
abgesehen mal von der Zeit, die dabei drauf geht (na gut, macht man ja
meist auch nur einmal).
Marian Aldenhövel
> Was mich an den pauschalen negativen Aussagen zu Paradox irritiert, ist
> die Tatsache, daß kaum etwas Konkretes gesagt wird.
Das liegt IMHO vor allem daran, daß die üblichen Probleme eben sehr
unspezifisch sind. Die Tabelle geht halt kaputt, man muss sie reparieren
und hoffen, daß das gelingt und keine wichtigen Daten auf der Strecke
bleiben.
Es will eben nicht jeder das im Detail debuggen, wenn eine totale Lösung in
Form von "weg mit dem Ding" in Griffweite liegt.
> Im Netz finden sich bei Google dann auch hunderte Beiträge, bei
> denen Paradox zufriedenstellend local und auch im Netz professionell
> zum Einsatz kommt.
Wie gesagt, einer der Autoren solcher Beiträge bin ich. Trotzdem stehe ich
zu der Aussage, daß ich es nicht wieder tun würde - mir reichen die
unkonkreten Problemäußerungen völlig. Weil ich bis heute nicht weiß, was
ich damals richtig gemacht habe, will ich es nicht wieder riskieren.
> Ja gut, aber für eine DB-Anwendung, die selten mehr als 1000 Datensätze
> zu verwalten hat, ist eine DB in der Art von Interbase einfach mit
> Kanonen auf Spatzen schießen.
Erstens: Wenn die Kanone nichts kostet, genauso gut zu bedienen ist wie die
Spatzenflinte und Spatzen ohne Kollateralschäden erlegt, aber außerdem für
größere Tiere geeignet ist, warum sollte ich sie dann nicht auch für
Spatzen nehmen? Ich kann dann die Spatzenflinte abschaffen und vergessen
wie man sie genau halten muss, damit sie mir nicht das Gesicht wegreißt.
Zweitens: 1000 Datensätze im - garantierten - Einzelplatzbetrieb lade ich
komplett in eine Speicherstruktur und verwende also einen
dokumentenorientierten Ansatz statt einer Datenbank. Das hatte ich mit
selberschreiben gemeint.
> Was also wäre die bessere Alternative für eine Desktop-DB, die möglichst
> genauso universell ist wie dBase und Paradox? Sind es TurboDB, DBISAM?
Ich habe keine eigenen Erfahrungen damit, weil ich keine Desktop-Datenbanken
mehr benutze.
> Bei C/S wäre für mich Interbase auch die richtige Wahl, aber alles selber
> schreiben?
Ich meinte nicht, daß ich eine Datenbank selber schreibe - um Gottes Willen!
Ich schreibe einfache Routinen für Instanz-Auf-Platte und
Platte-In-Instanz.
Ingo Balzer
zum Thema Re: Paradox-Fehler: BLOB wurde geändert:
> Es will eben nicht jeder das im Detail debuggen, wenn eine totale Lösung in
> Form von "weg mit dem Ding" in Griffweite liegt.
mmh
> Erstens: Wenn die Kanone nichts kostet, genauso gut zu bedienen ist wie die
> Spatzenflinte und Spatzen ohne Kollateralschäden erlegt, aber außerdem für
> größere Tiere geeignet ist, warum sollte ich sie dann nicht auch für
> Spatzen nehmen? Ich kann dann die Spatzenflinte abschaffen und vergessen
> wie man sie genau halten muss, damit sie mir nicht das Gesicht wegreißt.
Ist eine Überlegung wert.
> Zweitens: 1000 Datensätze im - garantierten - Einzelplatzbetrieb lade ich
> komplett in eine Speicherstruktur und verwende also einen
> dokumentenorientierten Ansatz statt einer Datenbank. Das hatte ich mit
> selberschreiben gemeint.
Geht in diesem Falle nicht so ohne weiteres.
> Ich meinte nicht, daß ich eine Datenbank selber schreibe - um Gottes Willen!
> Ich schreibe einfache Routinen für Instanz-Auf-Platte und
> Platte-In-Instanz.
Aha, ich hatte Dich schon fast unter die Masochisten eingestuft :-)
Gruß Ingo