DBGrid zeigt nicht alle Werte an

[Jelen]

Hallo,
kennt jemand folgendes Problem:
Meine Anwendung zeigt den Inhalt einer dBase-Datei (*.DBF) in einem DBGrid an.
Dabei fehlen allerdings Werte in Spalten, die als ftfloat typisiert sind (Ausnahme: ein 6-stelliger Wert wird angezeigt).
Die Felder erscheinen leer, auch wenn die Werte nachweislich vorhanden sind - ich kann z.B. einen Filter auf das Feld setzen und bekomme nur die Datensätze, die die Filterbedingung erfüllen.
Aber sehen würde ich Werte schon gerne!
Weiß jemand Rat? Danke!

[mashutu]

Poste mal ein wenig Code, damit das Problem besser zu verstehen ist.
Und: fehlen Spalten oder Werte in Spalten?
Werden Zellen leer angezeigt in denen sich Werte befinden sollten?

[Jelen]

Ich habe dasselbe Problem auch direkt in der IDE, ohne eine Zeile Code:
Man nehme ein neues Projekt, füge dem Formular ein TDataBase-, TTable- und TDataSource- sowie ein TDBGrid-Objekt hinzu.
Dann setze ich die Eigenschaften DatabaseName auf den Pfad zur lokal auf C: liegenden Datei sowie TableName auf den Dateinamen der DBF-Datei.
Das DBGrid zeigt daraufhin die Spalten und Werte an. Nur in den Spalten, die Werte vom Typ ftfloat enthalten, zeigt das Grid nur einen einzigen Wert an, den einzigen 6-stelligen und gleichzeitig größten. Die übrigen Werte sind unsichtbar, aber vorhanden, siehe Bild.

[mkinzler]

Wie sieht die Tabelle dazu aus?

[Jelen]

Wenn ich dieselbe dBase-Datei in Excel öffne, sind alle Werte da - siehe Bild.

[mkinzler]

und wie sieht die Originaltabelle aus?

[Jelen]

Die Tabelle stammt aus einer anderen Anwendung, die mir nicht zur Verfügung steht, und ist daher für mich in dieser Form das Original.
Wie die Feldinhalte aussehen sollten, weiß ich nur aus Excel - und natürlich soll mein Programm gerade die nicht angezeigten Werte auslesen und verarbeiten.
Wenn ich versuche, die Felder selbst auszulesen (z.B. mit Table.Fields[i].AsString), erhalte ich dasselbe Ergebnis wie im DBGrid.

[Jelen]

Bislang konnte ich nur feststellen, dass DBGrid nicht das Problem ist.
Wenn ich DBGrid herausnehme und nur über TTable auf die Tabelle zugreife, fehlen die Werte auch.
Erstaunlich ist nach wie vor, dass die BDE die Werte kennt, irgendwo tief drinnen...
Der Filter hat sie zur Verfügung und reagiert korrekt, aber nach außen (über Table.Fields, Table.FieldByName etc. kommt nichts durch.
Hat schon mal jemand Kompatibilitätsprobleme mit dBase gehabt?

[Union]

Stell doch mal die Tabelle zur Verfügung. Vielleicht ist es ja kein echtes dBase-III Format sondern neueres Foxpro oder dBase-IV.

[Jelen]

Hier ist die Tabelle. Mußte sie zippen, DBF ist nicht erlaubt.

[bluesbear]

Moin Jelen,
eine Erklärung für das merkwürdige Phänomen habe ich auch nicht.
Ich habe die Tabelle mal in Excel geöffnet, und mit "speichern unter" unter einem anderen Namen abgespeichert. Mit dieser Datei klappts bei mir dann auch in Delphi.

[Union]

Also die Tabelle ist strukturell vollkommen in Ordnung. Mit Advantage Treibern kann sie gelesen werden. Ich habe auch mal ein Prüfprogramm drüberlaufen lassen aus alten DOS Zeiten und das hat auch keine Fehler gefunden, Header, Signaturen und Datensätze sind in Ordnung. Sogar mit altem DBU kann die DBF geöffnet werden. Vielleich liegt es an der Satzlänge oder Anzahlder Felder (921 byte 110 Felder) dass damit die BDE nicht klar kommt. Wenn ich nämlich ein paar Felder entferne (z.B. DBU) funktioniert es (bei 99 Stück).

[Jelen]

Wenn ich die Originaldatei (die in Delphi klemmt) mit der von Excel gespeicherten (die in Delphi läuft) vergleiche, unterscheiden sie sich nur in den Bytes 3 und 4:

Code:

Original 03 6C 01 15 4E 00 00 ...
Excel    03 6C 02 10 4E 00 00 ...

Hat jemand eine Ahnung, wofür die stehen?
Danke schonmal an alle, die sich das Problem angesehen haben!

[Union]

Code:

Original 03 6C 01 15 4E 00 00 ... 
Excel    03 6C 02 10 4E 00 00 ...

Das ist das Aktualisierungsdatum:

Code:

Alt
$6C = 108 = 2008
$01 =   1 = Januar
$15 =  21 
Neu
$02 =   2 = Februar
$10 =  16

[Jelen]

Tja, am Datum liegts ja wohl nicht.
Genauer betrachtet gibts noch weitere Unterschiede. Insbesondere speichert Excel alle Datenwerte rechtsbündig, während sie in der Originaldatei linksbündig stehen.

[Jelen]

Nachdem alle Werte intern sowieso als strings gespeichert sind, bin ich mit dem Holzhammer auf die Tabelle los und ändere das Datenformat des Feldes von ftfloat auf ftstring:

Delphi-Quellcode:

Table1.FieldDefs[25].DataType := ftstring;

Siehe da, schon sind alle Werte sichtbar.
Bleibt die Frage, welche "Kollateralschäden" diese Aktion nach sich zieht...

[bluesbear]

Zitat:

Zitat von Jelen

Nachdem alle Werte intern sowieso als strings gespeichert sind, bin ich mit dem Holzhammer auf die Tabelle los und ändere das Datenformat des Feldes von ftfloat auf ftstring:
Siehe da, schon sind alle Werte sichtbar.
Bleibt die Frage, welche "Kollateralschäden" diese Aktion nach sich zieht...

Sehr wahrscheinlich keine. Ein Feld in dem ursprünglichen Typ als solches auszuwerten ist die richtige Methode :wink:
So weit hatte ich Dein Problem dann doch nicht analysiert, mir die Typen genauer anzuschauen. Wieso die BDE auf das schiefe Brett kommt, das als TFloatField herzunehmen - keine Ahnung. Aber ich hab da schon merkwürdigere Sachen erlebt.

[Union]

Selbst wenn man mit einer Query und Cast nach integer oder char arbeitet bleiben die Felder leer. Ist wohl ein Treiberproblem, denn auch mit ADOTable und ADOQuery gibts den gleichen Müll. Nur mit dem Advantage OLE DB Treiber funkioniert es problemlos.

[Jelen]

Danke für Eure Hilfe.
Advantage habe ich mir auch angesehen, interessant besonders, ohne BDE auszukommen.
Auf jeden Fall ist Land in Sicht! Schönes Rest-Wochenende noch!

[Union]

Wenn Du DBF Dateien nur für den Import (Readonly) brauchst, musst Du Dich nicht mit den Treiber belasten. Dann geht es auch mit einer simplen Routine, die das direkt liest (Quick and dirty):

Delphi-Quellcode:

type
  TFieldDef = class
  public
     FieldName : string[10];
     FieldType : char;
     FieldLen  : smallint;
     FieldDec  : smallint;
  end;
...
uses contnrs, (* Für TObjectlist *)
     math     (* Für max()       *)
...
procedure TMainForm.ReadDbfFile(const AFileName: string);
const
   HeaderRecordLen = 32;
var
   fs : TFileStream;
   Buffer : string;
   RecLen, c, p, r : integer;
   FieldList : TObjectList;
   FieldDef : TFieldDef;
begin
   (* Öffnen der Datei zum Lesen *)
   fs := TFileStream.Create(AFileName, fmOpenRead or fmShareDenyNone);
   fs.Seek(HeaderRecordLen, soFromBeginning);

   (* Felddefinitionen einlesen *)
   FieldList := TObjectList.Create(True);
   SetLength(Buffer, HeaderRecordLen);
   RecLen := 0;

   fs.ReadBuffer(Buffer[1], HeaderRecordLen);
   while buffer[1] <> #13 do
   begin
      FieldDef := TFieldDef.Create;
      FieldDef.FieldName := trim(copy(buffer, 1,10));
      FieldDef.FieldType := buffer[12];
      FieldDef.FieldLen  := ord(buffer[17]);
      FieldDef.FieldDec  := ord(buffer[18]);
      if (FieldDef.FieldType = 'C') and
         (FieldDef.FieldDec  > 0) then
      begin
         FieldDef.FieldLen := FieldDef.FieldDec * 256 + FieldDef.FieldLen;
      end;
      inc(RecLen, FieldDef.FieldLen);
      FieldList.Add(FieldDef);
      fs.ReadBuffer(Buffer[1], HeaderRecordLen);
   end;

   (* Eintrag der Feldnamen in Stringgrid *)
   StringGrid.RowCount  := 2;
   StringGrid.FixedRows := 1;
   StringGrid.FixedCols := 0;
   StringGrid.ColCount  := FieldList.Count;

   for c := 0 to FieldList.Count-1 do
   begin
      StringGrid.Cells[c, 0]  := TFieldDef(FieldList.Items[c]).FieldName;
      StringGrid.ColWidths[c] := Max(Length(StringGrid.Cells[c, 0]), TFieldDef(FieldList.Items[c]).FieldLen)*10;
   end;

   (* Zurück an das Ende der Felddefinitionen gehen *)
   fs.Position := fs.Position-HeaderRecordLen+1;

   (* Die Daten können direkt nach dem Endekennzeichen #$D stehen *)
   (* Wurde die DBF durch Clipper erzeugt, so steht hier noch ein *)
   (* zusätzliches Nullbyte                                       *)
   fs.ReadBuffer(Buffer[1], 1);
   if Buffer[1] <> #0 then
      fs.Position := fs.Position-1;

   (* Satzlänge um eins erhöhen, an erster Stelle steht *)
   (* das Löschkennzeichen                              *)
   inc(RecLen);

   r := 0;
   (* Daten einlesen und in Stringgrid eintragen        *)
   SetLength(buffer, RecLen);
   while fs.Position < fs.Size do
   begin
      if fs.Read(Buffer[1], RecLen) = RecLen then
      begin
         inc(r);
         if r > 1 then
            StringGrid.RowCount := StringGrid.RowCount+1;
         Application.ProcessMessages;
         p := 2;
         for c := 0 to FieldList.Count-1 do
         begin
            StringGrid.Cells[c, r] := copy(buffer, p, TFieldDef(FieldList.Items[c]).FieldLen);
            inc(p,TFieldDef(FieldList.Items[c]).FieldLen);
         end;
      end;
   end;
   FieldList.Free;
   fs.Free;
end;

[Jelen]

ReadDbfFile ist 'ne feine Sache - keine Treiber, keine BDE o.ä., und liest auch diesen Problemfall korrekt ein.
Für das schnelle Auslesen von dBase-Dateien eine echte Erleichterung.

[bluesbear]

Hallo Jelen,
hast Du herausfinden können, warum die BDE die Datei nicht mochte?
Natürlich ergibt es keinen Sinn, einem Problem hinterherzurennen, wenn man die Lösung hat. Ich frage nur aus reiner Neugier.

[Jelen]

Hallo bluesbear,
bislang noch nicht. Aber ich bleibe an der Sache dran. Wenn ich etwas herausfinde, stell' ich es hier rein.