peter-e hat geschrieben:
Was "SQL-Statement absetzen" heißt, weiß ich nicht, so ein Datenbankspezialist bin ich nicht. Aber ich glaube nicht, dass DBFV das kann - habe in den Menüs nichts dergleichen gesehen.
SQL ist eine Abfragesprache, die einheitlich genormt ist und von allen ernstzunehmenden modernen Datenbank-Systemen unterstützt wird. Dies ermöglicht es, Abfragen ohne Rücksicht auf das verwendete System zu formulieren und identisch mit gleichen Ergebnissen auf unterschiedlichen Systemen durchzuführen.
peter-e hat geschrieben:
Nebenbei bemerkt: Im DBFV fand ich auch eine Funktion: OEM zu ANSI konvertieren und umgekehrt. Das hat mir jahrealte Darstellungsprobleme gelöst, die ich immer dann hatte, wenn ich im TextMaker-eigenen Datenbankmodul arbeiten wollte. Jedesmal musste man erst manuell auf Windows-Zeichensatz umstellen oder mit einem Dokument und einer zugeordneten Datenbank arbeiten. Jetzt ist alles umgestellt auf OEM-Zeichensatz - dank DBFV. Das erleichtert vieles.
OEM steht für "Original Equipment Manufacturer" und bezeichnet eigentlich den Hersteller eines EDV-Geräts. Einen OEM-Zeichensatz oder was auch immer kann es daher eigentlich nicht geben. Solche Unsauberkeit bei Fachbegriffen macht mich immer argwöhnisch. Der korrekte Ausdruck würde lauten: ASCII, evtl. auch DOS-ASCII o. dgl. Im übrigen ist ASCII bzw. DOS-ASCII bei DBF-Tabellen nach wie vor Standard. Inzwischen sind zwar auch DBF-Tabellen mit ANSI- oder sogar anderen Zeichensätzen definiert, aber nicht besonders verbreitet. Alle SoftMaker-Programme sollten aber diese Unterscheidung kennen und sauber durchführen, es kommt
wirklich nur darauf an, das richtige Dateiformat beim Laden und Speichern auszuwählen. Sollten dabei Fehler auftreten, ist eine Meldung an den Support oder hier im Forum erwünscht, damit die entsprechenden Funktionen verbessert werden können. OEM-Konversions-Programme sind hingegen eigentlich völlig überflüssig, in meinen Augen sogar ein Unding.
peter-e hat geschrieben:
Und ich glaube, für eine günstige Datenbank bestünde am Markt echt Bedarf. Da ist eine Lücke. Ich sehe ja, was einem angeboten wird, wenn man nach einer Datenbank sucht. Manche günstigen Produkte, die es früher gab (z.B. Datamat von DataBecker) sind schon längst wieder vom Markt verschwunden. Ansonsten bleibt nur das, wovon ich geschrieben habe.
Aber als dieser Tage wieder der Newsletter von SoftMaker kam mit dem neuen, tollen Angebot - was war es noch? 50 Schriften für Weihnachten oder so - da dachte ich im Stillen: Ach Leute... wie schade, wieder ein Jahr um, und wir sind genauso weit wie zuvor.
Nun ist es so, dass DM99 gleichsam einer anderen Generation von Datenbanksystemen angehört. Heute sind graphische Oberflächen, Datenbank-Relationen zum Ziehen mit der Maus, graphisch ansprechende Formulare, Masken, Filter usw. usf. etabliert und bis zu einem gewissen Grad Standard.
Leider ist es nun nicht ganz so einfach, ein Programm, das alle diese Merkmale nicht oder nur ansatzweise aufweist, mal schnell so ein bisserl umzuprogrammieren und neu zu kompilieren, und da ist es dann auch schon. Nur um die SQL-Abfrage zu implementieren, braucht es einen Kern, der diese Sprache fehlerfrei nachbildet. Die Beta-Version von DM weist dagegen noch eine ganze Menge mehr auf, was ebenfalls ganz neu ist, z. B. die ODBC-Schnittstelle.
Um es nochmals anders auszudrücken: Es gibt keinen einfachen evolutionären Weg von DM99 zum "neuen" DM. Wenn DM99 ein Fachwerkhaus wäre, dann wäre der "neue" DM vielleicht eine Stahl-Beton-Glas-Konstruktion. Diese kann man aber nicht einfach auf das Fachwerkhaus aufsetzen, etwa indem man einfach ein Stockwerk oben drauf stellt.
Ich wähle noch einen anderen, vielleicht hier näher liegenden Vergleich: den mit PDF. Fast jeder hier "weiss", was PDF ist. Nun basiert PDF auf der Seitenbeschreibungssprache Postscript, ist aber mit dieser nicht identisch, sondern ein Derivat (oder modern gesagt: ein "Spin-off") davon. Adobe als ursprünglicher Hersteller hat mit dem Acrobat und anderen Hilfsprogrammen ein nahezu perfektes Paket für den Umgang mit PDF geschaffen. Dieses ist nun leider etwas teuer.
Daher gibt es eine Menge preiswerter oder sogar kostenloser Hilfsmittel, vor allem PDF-Druckertreiber. Von diesen habe ich einige ausprobiert, und die meisten davon weisen irgendwelche Mängel auf. Zur Zeit arbeite ich oft mit ghostscript, da ich ein Buch-Mauskript damit in ein PDF umwandeln muss, um daran dann Korrekturen zu lesen. (Und nach jeder Änderung muss natürlich das PDF wieder neu erstellt werden, versteht sich ...) Dabei sind mir ebenfalls einige, nun sagen wir mal freundlich: Eigenheiten von ghostscript im Vergleich zu Acrobat aufgefallen.
Es ist eben alles andere als trivial, eine komplette Sprache wie Postscript bzw. PDF zuverlässig fehlerlos nachzubauen.Ich habe auch Tests mit einem in der graphischen Industrie verbreiteten Test-Set von PDF-Dokumenten angestellt. Dabei habe ich festgestellt, dass selbst Acrobat Reader erst sei ca. einem Jahr überlagernde Farben mit Transparenzen, die in einem der Test-Dokumente enthalten sind, fehlerfrei darstellen kann. Drucken kann er diese allerdings nicht fehlerfrei. Alle anderen getesteten PDF Viewer versagen bei diesem Test, auch ghostscript/ghostview. Selbst der originale Acrobat schafft nur die Bildschirm-Anzeige korrekt, versagt jedoch beim Druck ebenso wie alle seine Konkurrenten. Dabei handelt es sich bei PDF um eine Erfindung von Adobe; wenn einer das können sollte, dann der ...
Nun mag jemand einwenden, dass es auf solche Spezialitäten nicht ankommen mag. Gewiss, dem stimme ich zu. Bloss habe ich des öfteren Manuskripte von Büchern als PDF zur Korrektur bei mir, und wenn nun schon beim Öffnen derselben eine Meldung erscheint, dass dies oder jenes nicht untersützt werde oder nicht richtig angezeigt, dann kann ich eben genau das, was ich müsste, nicht gewissenhaft tun, nämlich das Dokument korrigieren.
Das möchte ich all denen einmal gesagt haben, die sich von nicht Trivialem frustrieren lassen.
Anmelden
Registrieren
FAQ
Suche
