Zeos und Lazarus 1.6.4

[aebding]

Hallo Forengemeinde,

seit dem Lazarus Update auf Version 1.6.4 (32Bit, Windows-Version) mit Zeos (7.2 Rev. 3986) habe ich folgendes Problem :

Tabelle Test : Var1, Var2, Var3, Var4, Var5. Variablen Typ gleichgültig ...
Wenn ich in einem TZQuery als SQL Script z.B. "select * from ..." verwende ist alles OK,
verwende ich eine Teilmenge z.B. "select Var1, Var2 from ..." wird zur Laufzeit der Fehler "Field not found : Var3" ausgegeben,
also das nächste Feld das nicht in der Aufzählung enthalten ist.

Selbe Konfiguration mit Lazarus 1.6.2 läuft problemlos ...

Hat jemand eine Idee ?

[af0815]

Schon geschaut ob da nicht fixe Felddefinition hinterlegt sind ?

[aebding]

... fixe Felddefinition ???

und wie gesagt, die selbe Konfiguration lief bis Lazarus 1.6.2 ohne Probleme ...

[Soner]

...
Wenn ich in einem TZQuery als SQL Script z.B. "select * from ..." verwende ist alles OK,
verwende ich eine Teilmenge z.B. "select Var1, Var2 from ..." wird zur Laufzeit der Fehler "Field not found : Var3" ausgegeben,

Es sieht danach aus dass du Var3 irgendwo verwendet hast und nachdem es jetzt in der Teilmenge nicht enthalten ist wird Fehlermeldung erzeugt.
Lösung
1. Suche nach DBControl in dem Var3 als Feld eingetragen ist und entferne es.
2. Suche in persistenten Feldern von dein Query(=wo du SQL-ABfrage verwendest) nach Var3 und entferne es.
(Rechtsclick auf TZQuery > Felder bearbeiten)

Am besten öffne LFM-Datei in Texteditor und such nach Var3

[aebding]

Danke für die schnelle Anwort aber ...

Rechner 1, Lazarus 1.6.2 -> Anwendung läuft !!
Rechner 2, Lazarus 1.6.4 -> beschriebener Fehler !!

Greife von beiden Rechnern auf die selbe Anwendung zu ...

[af0815]

Was ist, wenn in Lazarus 1.6.2 noch ein Fehler in den DB Komponenten war, der mit 1.6.4 gefixt wurde ?

Kannst ja auch 'select Va1, Var2, 'Dummy' as Var3 from ..' probieren und sehen, ob irgendwo der Dummy auftaucht.

Auch mit einem guten Suchtool kann man im Source nach Var3 suchen. Das muss ja in einer pas oder lfm ja auftauchen.

Andreas

[aebding]

Dann würde der Fehler bereits seit Lazarus 0.9.? existieren, mein Projekt läuft seit 2011 ...

Als Fehler wird immer das erste, nicht in der select-Anweisung enthaltene, Tabellenfeld ausgegeben.

z.B. "select Var1, Var2, Var3 from ..." -> "Field not found : Var4"
"select Var1, Var3, Var4 from ..." -> "Field not found : Var2"

usw.

[wp_xyz]

Was machst du mit der Query? Hängt da vielleicht ein DBGrid dran, in dem alle Felder fest "verkabelt" sind? Wenn nicht, schreibe eine kleine Demo, in der alles weggelassen wird, außer der Abfrage, poste sie her, falls der Fehler hier auch auftritt.

[aebding]

Ich habe jetzt mal ein Beispiel angehängt.

Normalerweise arbeite ich nicht mit einem DBGrid aber für das Beispiel ist das OK. Im ZQuery1 sind alle Felder der Tabelle angelegt (select *).
Ich benutze das um bei bestimmten Abfragen nur Teilmengen in den Speicher zu laden, normalerweise werden alle Felder geladen ...

Programm arbeitet bis Lazurus 1.6.2 und Zeos 7.2 Rev. 3986 mit Firebird 2.5 problemlos, ab Lazarus 1.6.4 -> Fehler !!

[wp_xyz]

Wenn jetzt noch die fbd-Datei mit dabei wäre, könnte man etwas machen, aber so: weiterhin nur mit den Schultern zucken...

[aebding]

Sorry, diemal mit Datenbank ...

[wp_xyz]

Wie oben schon von anderen vermutet wurde, hast du persistente Felder definiert, die aber beim Öffnen der Abfrage nicht mehr vorhanden sind, weil sie im SQL-Text fehlen. Ich kann bestätigen, dass Laz 1.6.2 das schluckt, wobei allerdings das DBGrid alle Felder anzeigt und die fehlenden leer lässt; Laz trunk meldet einen Fehler. Ersetze ich ZEOS durch SQLDB meldet auch Laz 1.6.2 einen Fehler. Delphi konnte ich nicht testen, weil ich die Rückumwandlung des Projekts nicht hingekriegt habe - ich erinnere mich aber an einige hässliche Erfahrungen mit Delphi, das permanent Probleme machte, wenn persistente Felder nicht korrekt definiert waren oder fehlten. Daher habe ich persistente Felder eigentlich immer vermieden, weil sie spätere Änderungen am Feldtyp o.ä. praktisch unmöglich machen.

Ich kann mir nicht vorstellen, dass es richtig ist, wenn persistente felder vorhanden sind, die aber in der Abfrage fehlen. Meiner Meinung nach lag bis einschließlich 1.6.2 ein Fehler vor, der dann offenbar irgendwann inzwischen behoben worden ist.

P.S.
Statt mit persistenten Feldern würde ich mit normalen Feldern arbeiten, auf die ich über FieldByName zugreife. Nur wenn die Felder in einer Schleife über viele Datensätze abgefragt werden, würde ich vor der Schleife lokale Variablen für die Felder definieren:

Code: Alles auswählen

var
  FirmenNrField: TField;
  ArtikelNrField: TField;
begin
  FirmenNrFeld := ZQuery1.FieldByName('FirmenNr');
  ArtikelNrFeld := ZQuery1.FieldByName('ArtikelNr');
  ZQuery1.First;
  while not ZQuery1.EoF do begin
    // mache etwas mit FirmenNrFeld und ArtikelNrFeld
    ZQuery1.Next;
  end;

[aebding]

Hallo Leute,

dieser "Trick" war für mich immer eine schnelle Möglichkeit eine Teilmenge einer Datenbank-Tabelle abzufragen ...
Das hat mich jetzt eingeholt und ich darf nun ca. 150 Units ändern, aber damit bin ich für die Zukunft sicher !!??

Vielen Dank für Eure Hilfe ...

PS
Wie kann ich diesen Zweig auf erledigt setzen ...