SQL Abfrage liefert in Delphi keine Ergebnisse in DB-Browser aber schon

[Wiener]

Hallo Leute :-D
habe folgendes Problem und bin schon am Verzweifeln:

Ich mache in einer Procedure 2 SQL Abfragen. Die erst liefert mir die Daten die ich will ABER die 2 liefert mir nichts.
Zuerst habe ich einen Fehler in meiner Abfrage gesucht. Nachdem ich aber den SQL String in einen DB-Browser (Heidi-SQL) eingegeben hab und dieser auch Daten lieferte kann es nicht daran liegen.

Delphi-Quellcode:

procedure TForm1.Grid1SelChanged(Sender: TObject);
begin
  DataModule1.FDConnection1.Connected:= true;

  // Abfrage Tel.Nr. welche die Versicherer liefern.
  with DataModule1.FDQuery_TelNr do
  begin
    SQL.Clear;
    SQL.Text:=SqlAbfragen.Sql_Text('TelNrVersicherung');
    ParamByName('PNR').AsString := FDQueryPerson.FieldByName('Personennr').AsString;
    Open;
  end;

  Edit_Person_privat_Vers.Text:=  DataModule1.FDQuery_TelNr.FieldByName('PT').AsString;
  Edit_Person_email_Vers.Text:=   DataModule1.FDQuery_TelNr.FieldByName('PE').AsString;
  Edit_Person_handy_Vers.Text:=   DataModule1.FDQuery_TelNr.FieldByName('MT').AsString;
  Edit_Person_fax_Vers.Text:=     DataModule1.FDQuery_TelNr.FieldByName('GF').AsString;
  Edit_Person_arbeit_Vers.Text:=  DataModule1.FDQuery_TelNr.FieldByName('GT').AsString;
  Edit_Person_url_Vers.Text:=     DataModule1.FDQuery_TelNr.FieldByName('GW').AsString;

  // Abfrage Tel.Nr. welche der Betreuer selbst eingegeben hat.
  with DataModule1.FDQuery_TelNr do
  begin
    SQL.Clear;
//    SQL.Text:=SqlAbfragen.Sql_Text('TelNrMakler');
//    ParamByName('PNR').AsString := FDQueryPerson.FieldByName('Personennr').AsString;
    sql.Text:= 'SELECT Mobil AS MT, Privat AS PT, Arbeit AS GT, Fax AS GF, EMail AS PE, URL AS GW FROM KONTAKTPERSON WHERE Personnr LIKE ''11025177''' ;
    Open;  //HIER KOMMT NICHTS - IM DB-BROWSER ABER SCHON
  end;

  ShowMessage(DataModule1.FDQuery_TelNr.SQL.GetText + ' Count: '+ IntToStr(DataModule1.FDQuery_TelNr.RecordCount));

  Edit_Person_privat_Makler.Text:=  DataModule1.FDQuery_TelNr.FieldByName('PT').AsString;
  Edit_Person_email_Makler.Text:=   DataModule1.FDQuery_TelNr.FieldByName('PE').AsString;
  Edit_Person_handy_Makler.Text:=   DataModule1.FDQuery_TelNr.FieldByName('MT').AsString;
  Edit_Person_fax_Makler.Text:=     DataModule1.FDQuery_TelNr.FieldByName('GF').AsString;
  Edit_Person_Arbeit_Makler.Text:=  DataModule1.FDQuery_TelNr.FieldByName('GT').AsString;
  Edit_Person_url_Makler.Text:=     DataModule1.FDQuery_TelNr.FieldByName('GW').AsString;
end;

Im Anhang ein Screenshot von HeidiSQL mit Ergebinsdaten.
Wenn ich aber die Abfrage Nr. 2 über einen anderen Table der DB mache kommen Daten zurück.

Hat wer eine Idee an was es liegen kann??

[DeddyH]

Zu jedem Open gehört auch ein Close, das fehlt mir irgendwie, oder ich habe es übersehen.

[edit] Nachtrag: Du solltest auch die 2. Abfrage parametrisieren, das schützt vor SQL-Injection und macht den Code einfacher zu lesen. Außerdem solltest Du schnell wieder vergessen, dass es das unsägliche "with" überhaupt gibt, Du nimmst Dir damit jede Chance, ordentlich zu debuggen. [/edit]

[dataspider]

Bei ''11025177''' fehlt wohl noch ein '

[DeddyH]

Und ich sach noch: Parameter, dann passiert das nicht.

[Jumpy]

Zitat:

Zitat von dataspider (Beitrag 1505154)

Bei ''11025177''' fehlt wohl noch ein '

Das müsste aber mMn in dem Fall so richtig sein. Entspricht ja so einem ....'+QuotedStr('110025177')
Aber wie DeddyH schon sagte: Parameter sind trotzdem immer besser.

[Wiener]

Die Abfrage mache ich eh mit Parameter.
Das hab ich nur zum testen so gemacht.
Bin schon auf den Fehler gekommen: ich depp hatte noch im Debugger Ordner eine alte DB drinnen. Und diese hatte noch keine Daten in den Table. Dafür habe ich einige Stunden gesucht. :oops:

[haentschman]

Moin...:P
[Gebetsmühle ON]
...bitte kein WITH mehr benutzen. :warn:
[Gebetsmühle OFF]
:zwinker:

[jobo]

Zitat:

Zitat von Wiener (Beitrag 1505161)

Bin schon auf den Fehler gekommen: .. alte DB. Und diese hatte noch keine Daten in den Table. Dafür habe ich einige Stunden gesucht. :oops:

Ein Klassiker, ich habe sowas auch schon mindestens einmal gehabt.
Und irgendwann habe ich mir eine Tabelle angelegt, die es im Prinzip auch aus anderen Gründen geben musste. DB Customizing, ein paar spezifische Konfigurationsangaben des System Setups und schlicht und ergreifend ein Name, Dev XY alpha, .. Prod <Standort> ..
Ist irgendwie hilfreich. Ich kann die DB einfach (ab)fragen, wer sie ist. Letztlich ist das sogar im Frontend gelandet und es gibt auch eine Version bzw. sogar 2, eine für das Datenmodell und eine für den Stand der Applikationsstammdaten. Die Versionen kommen natürlich aus Scripten.

Kehrseite der Medaille ist natürlich, dass auch diese Information gepflegt werden muss. Tatsächlich ist aber der Umgang mit dem DB Namen*, mit der DB ein anderer als mit Codezeilen, Connectionstrings, Versionierungstools usw. Es klappt gut.

*Nicht der technische, sondern der "Taufname"

[dataspider]

Zitat:

Zitat von Jumpy (Beitrag 1505159)

Zitat:

Zitat von dataspider (Beitrag 1505154)

Bei ''11025177''' fehlt wohl noch ein '

Das müsste aber mMn in dem Fall so richtig sein. Entspricht ja so einem ....'+QuotedStr('110025177')
Aber wie DeddyH schon sagte: Parameter sind trotzdem immer besser.

Bei mir kompiliert er das gar nicht, was ja auch zu erwarten ist...

Frank

[dataspider]

Zitat:

Zitat von DeddyH (Beitrag 1505158)

Und ich sach noch: Parameter, dann passiert das nicht.

Deine Aussage ist grundsätzlich korrekt!
Ich bin aber auch schon abgewichen, weil:

SQL-Code:

select * from adresse a where a.ort like 'Dresd%'
select * from adresse a where a.ort like :ort

Die erste Abfrage verwendet den Index, die zweite nicht. Ist bei mir zumindest bei Firebird so.
Grund ist, dass beim Prepare der oberen Abfrage schon bekannt ist, dass der Index benutzbar ist.
Bei der zweiten Abfrage könnte ja statt 'Dres%' '%Dresd%' kommen, deshalb ist Like mit Parametern immer ein full table scan.

Wie gesagt, deine Aussage ist koerrekt. Man sollte diese eine AUsnahme dennoch auf dem Schirm haben.

Frank