ADOQuery meckert bei leeren Strings

[Gargamel]

Hallo

Wenn ich alle Datensätze nach einer Abfrage auflisten will und ein leerer String ist dabei, meckert AdoQuery.
Meldung: "Variante des Typs (NULL) konnte nicht in Typ (String) konvertiert werden"
Hier ist der Code:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var numRecs:integer;
begin
  ListBox2.Clear;
 
  AdoQuery1.SQL.Clear;
  AdoQuery1.SQL.Add('select * from testtabelle order by testfeld');
  AdoQuery1.Active:=true;
  AdoQuery1.ExecSQL;
  numRecs:=ADOQuery1.RecordCount;

  if NumRecs > 0 then
  Begin
    ADOQuery1.First;
    while(ADOQuery1.RecNo < numRecs) do
    Begin
      ListBox2.Items.Add(ADOQuery1.FieldValues['testfeld']);
      ADOQuery1.Next;
    End;
    ListBox2.Items.Add(ADOQuery1.FieldValues['testfeld']);
  End;
end;

Viele Grüße
Gargi

[sirius]

Prüfe vorher mit isempty ab.

Und verwende nicht RecordCount, sondern lass eine kopfabweisende schleife bis Query.eof laufen.

[mikhal]

Verwende statt
ADOQuery1.FieldValues['testfeld'] besser
ADOQuery1.FindField('testfeld').AsString Dann solltest du auch nicht mehr auf den Fehler laufen.

Grüße
Mikhal

[marabu]

Hi,

Active := True oder Open, immer wenn eine Ergebnismenge zurückgegeben wird.
ExecSql in allen anderen Fällen.
Nie beides gleichzeitig verwenden.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  ListBox2.Clear;
 
  with AdoQuery1 do
  begin
    SQL.Text := 'select * from testtabelle order by testfeld';
    Open;
    while not Eof do
    begin
      ListBox2.Items.Add(FieldByName('testfeld').AsString);
      Next;
    end;
    Close;
  end;
end;

Freundliche Grüße

[Bernhard Geyer]

As Designed.

Mit FieldValues['testfeld'] bekommst du ein Variant zurück und eine Empty-Variant lässt sich nunmal nicht in einen String wandeln (Bedeutung SQL-nil <> '')

[Gargamel]

Hallo

Herzlichen Dank für die vielen, sehr hilfreichen, Informationen.
Jetzt sieht der Code so aus:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  ListBox2.Clear;
  
  AdoQuery1.SQL.Clear;
  AdoQuery1.SQL.Add('select * from testtabelle order by testfeld');
  AdoQuery1.Active:=true;  // alternativ open

  while not AdoQuery1.EOF do
  Begin
    ListBox2.Items.Add(ADOQuery1.FieldByName('testfeld').AsString);
    ADOQuery1.Next;
  End;
end;

Mir ist aufgefallen, daß AdoQuery1.First nicht verwendet wurde. Kann es sein, daß bei einer neuen Abfrage der Datensatzzeiger immer auf den ersten Datensatz gesetzt wird?

Viele Grüße
Gargi

[mikhal]

Ja.

Grüße
Mikhal

[Bernhard Geyer]

Zitat von Gargamel:

Kann es sein, daß bei einer neuen Abfrage der Datensatzzeiger immer auf den ersten Datensatz gesetzt wird?

Mir wäre nichts anderes bekannt. Aber was dieser Datensatz ist ist ohne ein "order by ..." im SQL-Statement unbestimmt.

[marabu]

... und wenn du SQL.Add() nur einmal verwendest, dann erspart die die Zuweisung an SQL.Text den Aufruf von Clear().

[Gargamel]

Jetzt habe ich noch eine generelle Frage an Euch. Es geht um die Sicherheit.

Folgendes habe ich vor:

Die Datenbank soll Leveldaten beinhalten. Ein Haus soll hier stehen, ein Baum dort, usw. ...
Der Ablauf ist so, daß die 3D-Engine eine DLL lädt, die wiederrum auf die Access-DB zugreift und alle relevanten Daten in eine geeignete Datenstruktur schreibt, die sich in der DLL befindet. Danach werden alle Elemente im 3D-Raum platziert. Da die DB nur zum Laden des Levels und zum Laden/Speichern von Spielständen genutzt werden soll, ist die Frage nach der Geschwindigkeit nicht gegeben.

Die Access-DB ist zwar passwortgeschützt, dennoch drängt sich mir die Frage auf, ob diese Vorgehensweise halbwegs sicher ist.
Nichts ist schlimmer, als daß der Spieler später die Leveldaten einfach so abändern kann.

Meine Frage ist also: Sollte ich so vorgehen oder habt Ihr noch andere Ideen?

PS: Die 3D-Engine kann ich bereits in Delphi auf einem Formular, alternativ auch ein TPanel, darstellen. Der Leveleditor wird so aufgebaut.

Viele Grüße
Gargi