ZEOS select

[Perlsau]

Zitat:

Zitat von DeddyH (Beitrag 1158695)

Es kann ja immerhin sein, dass die Spaltenanzahl ZEOS-intern als Byte definiert ist.

Ist sogar ziemlich wahrscheinlich: The Maximum Number of Columns Per Table

Zitat:

Zitat von DeddyH (Beitrag 1158695)

Da gehen halt nur 256 (obwohl eigentlich 255?) rein, was normalerweise dicke ausreichen sollte.

Wieso 255? Ein Byte kann Werte 0 bis 255 annehmen, also 256 ...

Ausreichen sollte es in der Tat. Aber wenn er nun mal eine Tabelle mit über 500 Feldern hat und die so benötigt, muß er sich wohl anders behelfen.

[DeddyH]

Der Maximalwert von Byte ist aber nunmal 255, deshalb meine Verwunderung. Kann man eigentlich Tabellen ohne Spalten anlegen? Wenn nicht (sowas versuch ich ja gar nicht erst), dann wird wohl intern die 0 als 1 interpretiert, somit wäre alles klar.

[mkinzler]

Ja aber der Wertebereich ist von 0 -255 als 256 Werte (Felder)

[DeddyH]

Achso, wenn das der Spaltenindex ist, klar. Ich war gedanklich bei einer Anzahl, was bei genauerer Überlegung ja auch Quatsch wäre.

[Perlsau]

Zitat:

Zitat von jangbu (Beitrag 1158666)

... die Probleme die ich beim update,select habe mit der Anzahl der Datenbankfelder zu tun haben ...

Ich hab jetzt mal kurz in einer MySQL-Testtabelle 800 Felder vom Typ INT angelegt. Die werden im DBGrid korrekt angezeigt ... Ich kann dein Problem nicht nachvollziehen ...

MySQL-Version: 5.5
Zeos-Version: 7.0.0-dev
Delphi-Version: 2009 pro
Windows-Version: XP Pro

[DeddyH]

Das könnte am 7er ZEOS liegen, da soll sich ja einiges getan haben.

[Perlsau]

Zitat:

Zitat von DeddyH (Beitrag 1158735)

Das könnte am 7er ZEOS liegen, da soll sich ja einiges getan haben.

Leider hat der TE nicht angegeben, welche ZEOS-Version er verwendet. Dabei kann man sich zahlreiche Komponenten via SVN automatisch aktuell halten.

@jangbu: Bastel dir doch mal ein kleines Testprogramm und probiere selber aus, wo die Grenzen liegen. Vor allem aber solltest du bei Fremdkomponenten nach Möglichkeit immer die neuesten Releases einsetzen.

Mein kleines Testprogramm:

Delphi-Quellcode:

unit UnitMain;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Grids, DBGrids, JvExDBGrids, JvDBGrid, ComCtrls;

type
  TFormMain = class(TForm)
    Button_Tabellen: TButton;
    ListBox_Tabellen: TListBox;
    Button_Anlegen: TButton;
    ListBox_Spalten: TListBox;
    DBGrid1: TDBGrid;
    Button_FelderDel: TButton;
    UD_Anzahl: TUpDown;
    Edit_Anzahl: TEdit;
    procedure Button_TabellenClick(Sender: TObject);
    procedure FormActivate(Sender: TObject);
    procedure Button_AnlegenClick(Sender: TObject);
    procedure Button_FelderDelClick(Sender: TObject);
  private { Private-Deklarationen }
  PROCEDURE TabellenNamen;
  public  { Public-Deklarationen  }
  end;

var
  FormMain: TFormMain;

implementation
{$R *.dfm}

USES
    UnitData;

VAR
   Pfad : String;

procedure TFormMain.FormActivate(Sender: TObject);
begin
     Pfad := ExtractFilePath(ParamStr(0));
     DatMod.ZCon.Connect;
     IF NOT DatMod.ZCon.Connected THEN
     BEGIN
          ShowMessage('keine Verbindung');
     END;
     DatMod.ZTab_Test.Active := TRUE;
     TabellenNamen;
end;

PROCEDURE TFormMain.TabellenNamen;
BEGIN
     DatMod.ZCon.GetTableNames('test',ListBox_Tabellen.Items);
     DatMod.ZTab_Test.Close;
     DatMod.ZTab_Test.Open;
     DatMod.ZTab_Test.GetFieldNames(ListBox_Spalten.Items);
END;

// Tabelle erweitern
procedure TFormMain.Button_AnlegenClick(Sender: TObject);
VAR
   i,A,Z   : Integer;
   Datei,
   Aus : String;
begin
     A := ListBox_Spalten.Count;
     Z := A + UD_Anzahl.Position -1;
     Datei := Pfad + 'Alter.txt';
     DatMod.ZQuery1.SQL.Clear;
     DatMod.ZQuery1.SQL.Append('ALTER TABLE test.testtabelle');

     FOR i := A TO Z DO
     BEGIN
          Aus := IntToStr(i);
          IF i < 100 THEN Aus := '0' + Aus;
          IF i <  10 THEN Aus := '0' + Aus;
          IF i = Z                                 THEN
             Aus := 'ADD Spalte_' + Aus + ' FLOAT' ELSE
             Aus := 'ADD Spalte_' + Aus + ' FLOAT,';
          DatMod.ZQuery1.SQL.Append(Aus);
     END;

     // DatMod.ZQuery1.SQL.SaveToFile(Datei);

     DatMod.ZQuery1.ExecSQL;

     TabellenNamen;
     ShowMessage(IntToStr(Z - A + 1) + ' neue Spalten angelegt');
end;

// Spalten löschen
procedure TFormMain.Button_FelderDelClick(Sender: TObject);
VAR
   i,A : Integer;
   Aus : String;

begin
     A := ListBox_Spalten.Count -1;
     DatMod.ZQuery1.SQL.Clear;
     DatMod.ZQuery1.SQL.Append('ALTER TABLE test.testtabelle');

     FOR i := 1 TO A DO
     BEGIN
          Aus := ListBox_Spalten.Items[i];
          IF i = A                                           THEN
             DatMod.ZQuery1.SQL.Append('DROP ' + Aus)        ELSE
             DatMod.ZQuery1.SQL.Append('DROP ' + Aus + ',');
     END;
     DatMod.ZTab_Test.Close;
     DatMod.ZQuery1.ExecSQL;

     TabellenNamen;
     ShowMessage('Alle Spalten bis auf Spalte_000 gelöscht');
end;

procedure TFormMain.Button_TabellenClick(Sender: TObject);
begin
     TabellenNamen;
end;

end.

Bei 990 Spalten, wobei die letzten 290 vom Typ FLOAT sind, war dann aber Schluß. Ich vermute daher, daß der für eine einzige Tabellendefinition verfügbare Speicher begrenzt ist ...

Nun hab ich mir noch die Mühe gemacht und eine Lösch-Methode geschrieben, nach deren Ausführung ich ohne Probleme 900 Felder vom Typ FLOAT in meiner Testtabelle anlegen konnte, die ebenfalls alle korrekt angezeigt werden ... Also ich weiß nicht ...

[Medium]

Ungeachtet der Testreihen hier zu "wie viele Spalten gehen denn?" ist der Hinweis von p80286 das einzig vernünftige. (Exakt so protokollieren wir übrigens auch Messwerte die wir aus SPSen fischen ;)). Nur nicht den Index auf Datum und die Messtellen-ID vergessen, sonst wird's Suchen/Selecten darin nach ein paar zig Monaten recht gemütlich. Das ist dann flott, handlich, nicht so grenzenanfällig und zudem wohlgeformt.

[Perlsau]

Zitat:

Zitat von Medium (Beitrag 1158740)

Ungeachtet der Testreihen hier zu "wie viele Spalten gehen denn?" ist der Hinweis von p80286 das einzig vernünftige.

Vernünftig hin oder her, man bekommt als Entwickler nicht selten alte Systeme aus dem letzten Jahrhundert vorgesetzt, um dort irgend eine Erweiterung einzubauen oder Anpassung vorzunehmen. Meist dürfen vorhandene Datenstrukturen dabei nicht verändert bzw. verbessert werden, weil der Kunde das aus diversen Gründen nicht möchte (gewöhnlich aus Kostengründen). Dann bleibt dir nichts anderes übrig, als entweder den Auftrag abzulehnen (was ich meistens mache, wenn's darum geht, alte BDE-Applikationen zu erweitern) oder eben in den sauren Apfel zu beißen (wenn's entsprechend gut entlohnt wird bzw. Aussicht besteht, überhaupt Geld dafür zu bekommen).

Meine "Testreihen" dienten vor allem als Beleg dafür, daß der vom TE genannte Fehler nicht an irgend einer Begrenzung von MySQL oder Zeos liegt. Ich habe das gemacht, weil ich's genau wissen wollte. Dagegen ist doch hoffentlich nichts einzuwenden ...

[Medium]

Ist es nicht, und ich kenne die von dir beschriebenen Situationen zu Genüge. Da ich aber befürchtete, dass der Hinweis auf die "best-practice" im letzten Beitrag auf der Seite versupmft, wollte ich das nur nochmals hervor heben. Gegebenenfalls besteht ja die Möglichkeit des Umbaus für den TE, oder es ist ein Tipp für sein nächstes Projekt, oder irgend jemandem, der den Thread in 2-4 Jahren hier mal mit einem ähnlichen Problem liest, ist mit etwas Glück früh genug geholfen es gleich richtig zu machen. Dagegen ist hoffentlich auch nichts einzuwenden ;)