Fehler: zu wenig Arbeitsspeicher für Datenbank

[nahpets]

@mkinzler

Zitat von mkinzler:

@nahpets: Bist du der Autor der Komponente?
Unsere Beiträge sind nicht gegen diese Komponenet gerichtet sondern gegen Desktopdatenbanken im Allgeimeinen und das dBase Format im Speziellen.
Zudem sollte man imho immer die Erweiterungsmöglichkeiten im Kopf haben und deshalb scheidet für mich TDBF usw aus. Du kannst das natürlich anders sehen und mit TDBF glücklich werden.

nein, ich bin nicht der Autor.
Normalerweise nutze ich Oracle, SQL-Server, Ingres, Postgres..., wie der Kunde es will oder wie es für die Aufgabenstellung angebracht ist. Und wenn es um etwas einfaches, kleines geht, bei dem nicht mit einer Erweiterung zu rechnen ist, dann darf es auch mal dBase, Access... sein.

Für Mehrbenutzersysteme oder mandantenfähige Anwendungen sind die letztgenannten selbstverständlich nicht geeignet, aber für die Miniadressverwaltung für den USB-Stick durchaus, da scheidet die BDE dann aus, da sie installiert werden muss.

Sind die Embeddedversionen von SQLite, Firebird... eigentlich auch Desktopdatenbanken?
Für Client-Server-Anwendungen sind sie aber sicherlich nicht geeignet

Ach, was soll's, eigentlich weichen wir hier massive von der eigentlichen Fragestellung ab.

[mkinzler]

Zitat:

Sind die Embeddedversionen von SQLite, Firebird... eigentlich auch Desktopdatenbanken?

Nein. Da es einen (In-Process-)Server gibt.

Zitat:

Für Client-Server-Anwendungen sind sie aber sicherlich nicht geeignet Wink

Der embedded(Server)Client von FireBird ist ein "normaler" Client, der statt dem lokalen Protokoll einen Server im Bauch trägt. Der Client erkennt anhand, des Connectionstring, ob eine Netzwerkverbindung zu einem Server verwendet werden soll, oder die eingelagerte Serverkomponente die Datenbank öffnen soll. So kann das selbe Programm sowohl embedded arbeiten, wie auch auf einen remoten ( oder lokalen) (FB-)Server zugreifen soll oder sogar beides parallel.

[Satty67]

Schlagt mich nicht für meine Blasphemie...

Aber 100 Datensätze.. zukünftig vielleicht 200. Dafür eine SQL-Datenbank, selbst wenn es nur eine emmbed oder lokal ist? Ab wann sind wir soweit, das wir für die Daten aus einer Ini-Datei eine SQL-Datenbank ans Herz gelegt bekommen?

Wenn man wüsste, welche Daten es genau sind, würde ich da doch eher XML oder sogar nur ein eigenes kleines File of Record verwenden. Sind ja wohl kaum mehr als 200 KByte Daten...

[nahpets]

Hallo,
@Satty67

Zitat von Satty67:

Schlagt mich nicht für meine Blasphemie...

Aber 100 Datensätze.. zukünftig vielleicht 200. Dafür eine SQL-Datenbank, selbst wenn es nur eine emmbed oder lokal ist? Ab wann sind wir soweit, das wir für die Daten aus einer Ini-Datei eine SQL-Datenbank ans Herz gelegt bekommen?

Wenn man wüsste, welche Daten es genau sind, würde ich da doch eher XML oder sogar nur ein eigenes kleines File of Record verwenden. Sind ja wohl kaum mehr als 200 KByte Daten...

deshalb ja z. B. TDBF
(weil ja schon Datenbankkomponenten genutzt wurden)

[mkinzler]

Zitat:

oder sogar nur ein eigenes kleines File of Record verwenden.

Warum was einfaches nehmen, wenn man was selber was kompliziertes stricken kann? Warum was Flexibles nehmen wenn man doch was Unflexibles selber basteln kann?
Hier hat er geschrieben, das er etwas Erweiterbares will und typisierte Dateien sind nicht unbedingt für dieses Feature berühmt.

Ich geb mich geschlagen, nimm TDBF und seit glücklich.

[nahpets]

Hallo @mkinzler,

Zitat von mkinzler:

Zitat:

oder sogar nur ein eigenes kleines File of Record verwenden.

Warum was einfaches nehmen, wenn man was selber was kompliziertes stricken kann? Warum was Flexibles nehmen wenn man doch was Unflexibles selber basteln kann?
Hier hat er geschrieben, das er etwas Erweiterbares will und typisierte Dateien sind nicht unbedingt für dieses Feature berühmt.

Ich geb mich geschlagen, nimm TDBF und seit glücklich.

ich gebe mich auch geschlagen, lese nicht sämtliche Threads und hatte daher eine "Wissenslücke". Habe meine Aussage nur auf den Inhalt dieses Thread gestützt und nicht nach Querverbindungen zu anderen Fragestellungen des Threaderstellers in anderen Threads gesucht, die ggfls. die Antwort auf die gestellte Frage beeinflussen oder gar zu einer vollkommen anderen Sichtweise auf die Fragestellung führen.

[Satty67]

Zitat von mkinzler:

Hier hat er geschrieben, das er etwas Erweiterbares will

Ok, dann sieht das anders aus und schließe mich nahpets Fazit an. Man kann nicht jeden Thread lesen...

PS: File of Record sehe ich nicht unflexibler... eher für die Anwendung das am wenigsten komfortable Format. Aber auch nur weil man keine mehrere 100 KByte DBMS hat, die den Komfort ja erst bereitstellen. Das muss man alles selber programmieren. Intern ist doch jedes Format nur eine Anhäufung von Datenfeldern.

[mkinzler]

Zitat:

File of Record sehe ich nicht unflexibler...

Dann ändere mal nachträglich das Format der Daten.

[Satty67]

Zitat von mkinzler:

Zitat:

File of Record sehe ich nicht unflexibler...

Dann ändere mal nachträglich das Format der Daten.

Funktioniert technisch ja wohl genauso, wie es intern in einer SQL-Datenbank abläuft. Alte Spalte einlesen und in neue Spalte mit neuem Format ausgeben. Es fehlt der Komfort, weil man es selber machen (programmieren) muss. Wobei ich hier inzwischen Tools hab', die das auch ganz komfortabel lösen.

Ich konvertiere im Moment meine Record-Datenbanken nach Firebird-SQL. Bin aber inzwischen bei einigen Dateien am zweifeln, ob ich für die paar 100 KByte Daten wirklich den Aufwand betreiben sollte. Fast 5 Mbyte .DLL und Hilfsdateien bei FireBird und Komponenten (Zeos), die den Code aufblähen. Programmiertechnisch bekommt man auch nichts geschenkt, auch wenn natürlich schon sehr viel vom DBMS abgenommen wird.

Der Komfort oder auch Flexibilität steckt hauptsächlich im DBMS, nicht zwingend im Datencontainer. Wenn ich die Tabellen und Konfigurationsdateien aus dem Datenbank-Container raus ziehe, bleiben auch nur....