Fehler: zu wenig Arbeitsspeicher für Datenbank

[BAMatze]

Hallo nochmal an alle DP´ler,

Wusste jetzt nicht, in welche Sparte ich das Posten sollte, da ich eigentlich eine Komponente derzeit vorbereite, die eine Datenbank-Anbindung beinhaltet aber da ich derzeit nur bei der Implementierung der Datenbank stecke, habe ich für diese Sparte entschieden.

Also ich habe folgenden Code für meine Datenbank erstellt:

Delphi-Quellcode:

unit TischDatenbank;

interface

uses Classes, Controls, DBTables, DB, DBCtrls, Dialogs, Graphics;

const DatenbankFile = 'Sensordatenbank.db';

Type TTischDatenbank = class(TWinControl)
  private
    FTable: TTable;
    FTBTableSensorname: TStringfield;
    FTBVersuchstabelleSpleisspositionrechts: TFloatField;
    FTBVersuchstabelleSpleisspositionlinks: TFloatField;
    FTBVersuchstabelleMantellaenge: TFloatField;
    FTBVersuchstabelleGap: TFloatField;
    FTBVersuchstabelleManteldurchmesser: TFloatField;
    FDataSource: TDataSource;
    FDBNavigator: TDBNavigator;
    FDBEdit: TDBEdit;
    function CreateTable: TTable;
    function CreateDataSource: TDataSource;
    function createDBNavigator: TDBNavigator;
    function createTDBEdit: TDBEdit;
  protected
    //procedure CreateWnd; override;
  published

  public
    constructor create(AOwner: TComponent);

end;

implementation

constructor TTischDatenbank.create(AOwner: TComponent);
begin
  inherited create(AOwner);
  Controlstyle := Controlstyle - [csAcceptsControls];
  Visible := true;
  Color := clBlack;
  Width := 300;
  Height := 300;
  FTable := CreateTable;
  //FDataSource := CreateDataSource;
  //FDBNavigator := CreateDBNavigator;
end;

function TTischDatenbank.CreateTable: TTable;
begin
  result := TTable.Create(nil);
  result.TableName := DatenbankFile;
  result.TableType := ttParadox;
  
  if not result.Exists then // <--- hier kommt der Fehler
    begin
      Showmessage('Die Datenbankdatei "Sensorendaten.db" konnte nicht gefunden werden');
      Enabled := false;
    end
  else result.Open; 
  {FTBTableSensorname := TStringField.create(nil);
  result.Fields.Add(FTBTableSensorname);
  {result.Fields.Add(FTBVersuchstabelleSpleisspositionrechts);
  result.Fields.Add(FTBVersuchstabelleSpleisspositionlinks);
  result.Fields.Add(FTBVersuchstabelleMantellaenge);
  result.Fields.Add(FTBVersuchstabelleGap);
  result.Fields.Add(FTBVersuchstabelleManteldurchmesser); }
  //result.CreateTable;
end;

function TTischDatenbank.CreateDataSource: TDataSource;
begin
  result := TDataSource.Create(nil);
  result.DataSet := FTable;
end;

function TTischDatenbank.createDBNavigator: TDBNavigator;
begin
  result := TDBNavigator.Create(nil);
  result.Parent := Self;
  result.DataSource := FDatasource;
  result.Left := 10;
  result.Top := 10;
  result.Width := 200;
  result.Height := 20;
end;

function TTischDatenbank.createTDBEdit: TDBEdit;
begin
  result := TDBEdit.Create(nil);
  result.Parent := Self;
  result.Enabled := true;
  result.DataSource := FDataSource;
  //result.DataSource.DataSet := FTable;
  result.DataField := FTBTableSensorname.FieldName;
  result.Left := 10;
  result.Top := 50;
  result.Width := 100;
  result.Height := 20;
end;

{procedure TTischDatenBank.CreateWnd;
begin
  //FDBEdit := CreateTDBEdit;
end;}

end.

Die db-Datei existiert und es hat auch bis ebend sehr gut funktioniert, bis auf einmal die Meldung in der gekennzeichneten Zeile kommt, dass zu wenig Arbeitsspeicher vorhanden ist. Habe alle Änderungen, welche ich seit der funktionierenden Version, rückgängig gemacht (glaube ich :-D ) trotzdem bleibt der Fehler.

[mkinzler]

Alle Anwendungen, welche die BDE verwenden (auch die IDE) beenden und neu starten.
Das ist einer der Gründe, warum man die BDE nicht mehr verwenden sollte.

[BAMatze]

Zitat:

Zitat von mkinzler

Alle Anwendungen, welche die BDE verwenden (auch die IDE) beenden und neu starten.
Das ist einer der Gründe, warum man die BDE nicht mehr verwenden sollte.

Passiert sowas oft?

[hoika]

Hallo,

Ursache ist, dass du das Programm beim Debuggen wohl manchmal abschiesst,
die BDE bleibt aufgrund der offenen IDE aber auch offen.

Die BDE benutzt intern ein paar begrenzte Speicher,
die dann irgendwann voll sind.


Heiko

[mkinzler]

Zitat:

Passiert sowas oft?

Hin und wieder bis oft.

[BAMatze]

Also bleibt mir doch nur auf externe Komponenten zurückzugreifen, wenn ich nicht alles in Ini oder Excel über Ole speichern will?

[mkinzler]

Ist IBX nicht Teil von TDE? Sonst wären vielleicht Zeos einen Blick wert ( auf jeden Fall für lokale/embedded Datenbestände)

[hoika]

Hallo,

Zitat:

Hin und wieder bis oft.

Moment ! ;)

Das kommt drauf an.

Bsp. 1
TTable wird im Design-Mode schon geöffnet
-> besser erst zur Laufzeit öffnen

Bsp2:
excessives Nutzen von Ctrl+F2.
-> besser das Programm sauber beenden.


Heiko

[nahpets]

Hallo,

welche Datenmenge?

Wenn's wenig ist, schau Dir mal TDBF an, kann mit dBase-Tabellen umgehen, braucht keine BDE und keinen (wie auch immer gearteten) Datenbankserver. Für kleinere Sachen durchaus brauchbar.

Hoika nennt die wesentlichen Ursachen für Probleme mit der BDE, bei "sachgerechter" Nutzung läuft sie durchaus über lange Zeiträume stabil.

[mkinzler]

Trotzdem würde ich heute keine (Neu-)Programm mehr damit entwickeln bzw. den Umgang mit der BDE erlernen

[hoika]

Hallo,

wir reden von Paradox.
Da gibt es leider keine "alternative" Komponente.

Ein Umstieg auf DBase (TDBF) würde vielleicht was bringen.

Aber BDE bedeutet auf jeden Fall ein Rückschritt.


Heiko

[mkinzler]

TDBF ist allerdigs auch nicht so der Bringer und da es viele bessere Alternativen gibt würde ich diese verwenden

[Die Muhkuh]

Embedded FireBird wäre eine gute Alternative ;)

[BAMatze]

Zitat:

Zitat von mkinzler

Ist IBX nicht Teil von TDE? Sonst wären vielleicht Zeos einen Blick wert ( auf jeden Fall für lokale/embedded Datenbestände)

Hier auf Arbeit hab ich auch eine CodeGear 2007 Professional Version. Leider kann ich in meinem Profil nur eine Version angeben, deswegen habe ich meine private (also die TD-Version) angegeben, da dies ja auch ein privater Account ist.

[BAMatze]

Zitat:

Zitat von nahpets

Hallo,

welche Datenmenge?

Wenn's wenig ist, schau Dir mal TDBF an, kann mit dBase-Tabellen umgehen, braucht keine BDE und keinen (wie auch immer gearteten) Datenbankserver. Für kleinere Sachen durchaus brauchbar.

Hoika nennt die wesentlichen Ursachen für Probleme mit der BDE, bei "sachgerechter" Nutzung läuft sie durchaus über lange Zeiträume stabil.

Datenmenge ist eher sehr gering, wenn es mal 100 werden, dann ist das sicherlich schon viel.

[nahpets]

Hallo,

dann reicht TDBF allemal aus, da ist jeder Server überdimensioniert.

Für TDBF wird nichts zusätzlich benötigt, sprich: Programm und dBase-Dateien (Datendatei und Indexdatei). Keine Installation von Irgendwas, läuft auf jedem Rechner und auch vom USB-Stick...

[mkinzler]

Bei embedded DBMS braucht man auch keine Installation. Diese sind aber Featurereicher als TDBF ( können SQL). TDBF ist gut für den Import von dBase-Daten zu mehr aber imho nicht.

[nahpets]

Naja,

wofür brauche ich bei ca. 100 Datensätzen jetzt groß SQL?
Kommt also erstmal auf die Aufgabenstellung an, mit Filtern kann man (auch bei TDBF) durchaus sehr viel erreichen. Und bei einer Tabelle braucht man keine Joins..., sortieren per Index ist auch kein Problem.

[mkinzler]

Zitat:

wofür brauche ich bei ca. 100 Datensätzen jetzt groß SQL?

Jetzt vielleicht noch nicht

Zitat:

Und bei einer Tabelle braucht man keine Joins...

Ein paar Angaben mehr und eine Normalisierung macht Sinn -> weitere Tabellen
Besser gleich vorsorgen :zwinker:

[hoika]

Hallo,

und schon wären wir bei den Nachteilen einer DBF.

- zerschossene Indizes
- Datei ist beschädigt, aber nicht der Header.


PS:
Die habe ich mir nicht ausgedacht, aber wer mal früh um 06:00
von einem Kunden geweckt wird, wegen sowas,
erinnert sich ungern, aber er erinnert sich ;( ...


Heiko

[BAMatze]

Also hab ich jetzt die Wahl zwischen TDBF und DBMS. Dann stelle ich mal die Frage, die für mich sicherlich am wichtigsten ist: Wie gut kann man sich jeweils in das eine oder andere einarbeiten, also als Anfänger?

[mkinzler]

DBMS steht für Datenbank Management System, also kein bestimmtes. Um den Umgang mit Datenbanken zu verstehen sollte man mit der Theorie von Realtionen auskennen und ein Verständis von SQL schadet auf keinen Fall.

[hoika]

Hallo,

z.B. mit den entsprechenden Tutorials hier
(Hauptseite ganz unten).


Heiko

[Blup]

Ein Steuerelement das sich mit der grafischen Darstellung/Bearbeitung von Daten beschäftig direkt auf die Datenbank zugreifen zu lassen, ist eher nicht optimal.

Definiere besser ein Property einer Ableitung von TCollection bzw. TCollectionItem das die zu bearbeitenden Daten verwaltet. Dann funktioniert das Steuerelement auch erst einmal ohne Datenbankanbindung.

Alternativ oder zusätzlich könnte man diese Properties vorsehen:
DataSource (TDatasource) Der Entwickler kann sich für sein Datenbanksystem und Tabellenstruktur selbst entscheiden.
DataLinks (TStrings) Einfache zeilenweise Zuweisung TCollectionItem.Property=TDatasource.Feldname.

[nahpets]

Hallo Hoika,

Zitat:

Zitat von hoika

Hallo,

und schon wären wir bei den Nachteilen einer DBF.

- zerschossene Indizes
- Datei ist beschädigt, aber nicht der Header.


PS:
Die habe ich mir nicht ausgedacht, aber wer mal früh um 06:00
von einem Kunden geweckt wird, wegen sowas,
erinnert sich ungern, aber er erinnert sich ;( ...


Heiko

diese Probleme kenne ich, aber nur von der BDE, mit TDBF ist mir das noch nicht passiert.

[hoika]

Hallo,

das liegt wohl auch daran,
dass obige Fehler meistens mit Paradox-DB's auftreten.
Die haben z.B. pro Index immer 2 Dateien,
und jede der Dateien will bei einem Update aktualisiert werden.

Mache mal mit TDBF übers Netz eine längere Aktion,
dann ziehe während der Aktion den Netzwerkstecker und fange an zu beten ... ;)
Oder starte den betreffenden File-Server während der Aktion neu (beten nicht vergessen ...)


Heiko

[nahpets]

Hallo Hoika,

mag alles sein, aber dem Threadersteller scheint es nicht um eine mehrbenutzer- und netzwerkfähige Datenbankanwendung zu gehen, sondern um ein Programm mit einer eventuell bis zu 100 Datensätzen großen Tabelle.

Bleiben wir von daher mal auf dem Teppich.

[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.

[hoika]

Hallo,

ich werde demnächst TDBF nutzen *schäm*
aber nur um den aktuellen (BDE)-DBase-Export von der BDE abzukoppeln.


Heiko

[himitsu]

Und ich dachte so kleine DesktopEmbedded-Datenbanken können auch mal ganz nett sein?

Bisher hab ich selbst nie mit do großen DBs gearbeitet (ok, abgesehn von etwas mySQL in 'ner Webseite)
und das lag meißtens auch mit daran, daß ich kein weiteres großes System mitliefern bzw. voraussetzen wollte.
Hab also am Ende dann meißt stattdessen binäre Dateien und seit 'ner Weile XML-Dateien genutzt.

Und Jetzt entsteht hier nebeibei der Grundstock für ein kleines "Tool", welches eine XML-Datei in etwa wie eine Datenbank nutzen läßt, damit ich dann auch abundzu mal 'ne kleine DB nutzen kann und vermutlich auch mal werde.

Klar daß sowas dann nicht für Unmassen an Daten so sehr geeignet sein wird, aber große Datenmengen kommen hier eh nicht vor.

[nahpets]

@mkinzler

Zitat:

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? :stupid:

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:

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? :stupid:

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:

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:

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:

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....