ADOQuery - SQLQuery ??

[xReva]

Hallo, Danke für die Antwort ich benutze momentan zuhause die Testversion was der Enterprise entspricht und die selbe benutze ich auch in der Uni.


Wenn ich mit ADOQuery Parameter eingeben will sagt er immer Tstrings does not contain a member named 'Params'

Ich kenne auch leider nur den einen weg es mit Parametern zu machen bzw habe keinen anderen weg gefunden bis jetzt.

EDIT: Funktioniert das mit ADO Query dann im Prinzip gleich außer das es anders geschrieben wird bzw mit Parameters anstadt mit Params?



Mfg Lucas

[DeddyH]

Zumindest funktioniert es ähnlich. Sollte Dir die Delphi-Hilfe nicht zur Verfügung stehen, kannst Du auch die DP-Referenz verwenden, um genauere Informationen zu bestimmten Themen/Klassen/Methoden zu erhalten, z.B. zu TADOQuery.Parameters.

[HolgerX]

Hmm..

Hier mal eine (mit 'SQLQuery1' als TADOQuery) leicht bereinigte Version:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin
  SQLQuery1.ParamCheck := true;    // Bewirkt, dass die Parameter direkt 'initialisiert' = Erstellt werden!!

  SQLQuery1.SQL.Text:='INSERT into taccounts (sUsername,sUserPass,sUserPassSalt,sEmail,nAuthID,sIP) ' +
    'Values (:sUsername,:UserPass,:UserPassSalt,:email,:AuthID,:sIP)' ;

{ Brauchst Du nicht wegen SQLQuery1.ParamCheck := true
  SQLQuery1.Sql.Clear;
  SQLQuery1.Params.Clear;
  SQLQuery1.Params.CreateParam(ftString, 'Username', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'UserPass', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'UserPassSalt', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'email', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftInteger, 'AuthID', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'sIP', ptInputOutput);
}


  SQLQuery1.ParamByName('sUsername').Value := edit3.text;      // Hier fehlte das 's', siehe dein SQL     Values (:sUsername
  SQLQuery1.ParamByName('UserPass').Value := edit4.text;
  SQLQuery1.ParamByName('UserPassSalt').Value := edit5.text;
  SQLQuery1.ParamByName('email').Value := edit6.text;
  SQLQuery1.ParamByName('AuthID').Value := '4';
  SQLQuery1.ParamByName('sIP').Value := edit7.text;            // Hier stand 'email' statt das 'sIP'

  if (SQLQuery1.ExecSQL() = 1) then begin                     // Prüfen, ob der Insert erfolgreich war

    SQLQuery1.SQL.Clear;
//  SQLQuery1.Params.Clear;   // Wird beim löschen des SQL-Befehls direkt wieder entfernt...

    SQLQuery1.SQL.Text:='select last_insert_rowid() as nemid from taccounts';
    SQLQuery1.Open;

    nemid := SQLQuery1.FieldByName('nemid').AsString;

    SQLQuery1.Close;
  end;
end;

[xReva]

Zitat von HolgerX:

Hmm..

Hier mal eine (mit 'SQLQuery1' als TADOQuery) leicht bereinigte Version:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin
  SQLQuery1.ParamCheck := true;    // Bewirkt, dass die Parameter direkt 'initialisiert' = Erstellt werden!!

  SQLQuery1.SQL.Text:='INSERT into taccounts (sUsername,sUserPass,sUserPassSalt,sEmail,nAuthID,sIP) ' +
    'Values (:sUsername,:UserPass,:UserPassSalt,:email,:AuthID,:sIP)' ;

{ Brauchst Du nicht wegen SQLQuery1.ParamCheck := true
  SQLQuery1.Sql.Clear;
  SQLQuery1.Params.Clear;
  SQLQuery1.Params.CreateParam(ftString, 'Username', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'UserPass', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'UserPassSalt', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'email', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftInteger, 'AuthID', ptInputOutput);
  SQLQuery1.Params.CreateParam(ftString, 'sIP', ptInputOutput);
}


  SQLQuery1.ParamByName('sUsername').Value := edit3.text;      // Hier fehlte das 's', siehe dein SQL     Values (:sUsername
  SQLQuery1.ParamByName('UserPass').Value := edit4.text;
  SQLQuery1.ParamByName('UserPassSalt').Value := edit5.text;
  SQLQuery1.ParamByName('email').Value := edit6.text;
  SQLQuery1.ParamByName('AuthID').Value := '4';
  SQLQuery1.ParamByName('sIP').Value := edit7.text;            // Hier stand 'email' statt das 'sIP'

  if (SQLQuery1.ExecSQL() = 1) then begin                     // Prüfen, ob der Insert erfolgreich war

    SQLQuery1.SQL.Clear;
//  SQLQuery1.Params.Clear;   // Wird beim löschen des SQL-Befehls direkt wieder entfernt...

    SQLQuery1.SQL.Text:='select last_insert_rowid() as nemid from taccounts';
    SQLQuery1.Open;

    nemid := SQLQuery1.FieldByName('nemid').AsString;

    SQLQuery1.Close;
  end;
end;

Danke für die umfangreiche antwort! Aber wie würde das ganze mit ADOQuery aussehen? Da bei mir das ganze mit SQL Query nicht so wirklich klappt.

MFg Lucas

[HolgerX]

Hmm..

Zitat von xReva:

Danke für die umfangreiche antwort! Aber wie würde das ganze mit ADOQuery aussehen? Da bei mir das ganze mit SQL Query nicht so wirklich klappt.

MFg Lucas

(Einfach)
Packe nen TADOQuery auf deine Form und Benenne dann 'SQLQuery1' gegen 'ADOQuery1' (Name des erstellten ADOQuerys) um.

Fertig.

Wie ich geschrieben hatte, gilt das Beispiel für ein TADOQuery mit dem Namen 'SQLQuery1'

Auch sollten eigentlich alle von TDataSet abgeleiteten Querys nach dem Schema funktionieren (ohne Gewähr ).

[sko1]

Datensätze mit ADOQuery einfügen geht doch völlig problemlos ohne Parameter, Pseudocode:

Delphi-Quellcode:

ADOQuery.SQL.Text := 'Select irgendwas';
ADOQuery.Open;
ADOQuery.Append; //ein leerer Datensatz hinzu
ADOQuery.FieldByName('Feld1').AsString := 'Hallo';
ADOQuery.FieldByName('Feld2').AsInteger := 12345;
ADOQuery.FieldByName('Feld').AsBoolean := true;
ADOQuery.Post; //abschicken

Ciao
Stefan

[p80286]

Es mag sein, das es eine Konstellation gibt, mit der das funktioniert, aber im allg. geht das nicht.
Des Muster dafür sieht ungefähr so aus (mit Abweichungen je nach DB und Querykomponente)

Delphi-Quellcode:

Query.SQL.Text:='update mytable set myfield=:prm1 where id=:id';
Query.Parameters.Parambyname('prm1').asstring:='Wert1';
Query.Parameters.Parambyname('id').asinteger:=12345;
Query.ExecSQL;
{ggf betroffene Sätze Holen}
if Query.Rowsaffected>0 then showmessage('Update erfolgreich');

(und je nach Version für ADO: .Value='Wert1; und .Value:='12345'; )!!


Gleiches gilt für Insert und Select. Esrst den SQL-Text,dann die Parameter setzen, dann ein .Open oder .ExecSQL.

Gruß
K-H

[haentschman]

[meine Meinung]
Hallöle...

Zitat:

Ich kenne auch leider nur den einen weg es mit Parametern zu machen bzw habe keinen anderen weg gefunden bis jetzt.

...lieber nicht! Es gibt keinen Weg an Parametern vorbei.

kleiner Fehler:

Delphi-Quellcode:

SQLQuery1.ParamByName('sUsername').Value := edit3.text;
...
SQLQuery1.ParamByName('UNA').AsString := edit3.text; // besser
...
SQLQuery1.SQL.Clear; // braucht man nicht bei SQl.Text

1. Im Prinzip ist es egal... aber die Parameter (z.B. 3 stellig) als Kürzel sind von Feldnamen besser zu unterscheiden. Logischerweise müssen die Kürzel auch im SQL auftauchen.
2. nicht an @TE: Warum wird immer wieder .Value wenn keine Notwendigkeit auf den Cast besteht benutzt...Langeweile beim Debuggen?. As....für den exakten FeldTyp ist besser. Da erkennt man das man den falschen Typ übergibt.
3. In welchen Büchern steht sowas drin? Das SQl.Clear ist nicht notwendig da der komplette Text in der SQL Stringlist getauscht/aktualisiert wird.
[/meine Meinung]

[HolgerX]

Hmm..

Zitat von haentschman:

3. In welchen Büchern steht sowas drin? Das SQl.Clear ist nicht notwendig da der komplette Text in der SQL Stringlist getauscht/aktualisiert wird.

Das steht im Source-Code von TDataSet!
TDataSet.CheckInactive;
-> Aufgerufen von TCustomADODataSet.SetCommandText(const Value: WideString);

bevor der SQL-Query gesetzt wird (bei OnChange des SQLs).

Edit...
Blubber.. Blödsinn.. (Close als Clear interpretiert..)
Der Tag ist schon zu lange..

Aber hier im Forum war erst vor kurzem ein Thema, in dem dies erläutert wurde..

@xReva

Immer erst den SQL.Text setzen und dann die Parameter, nicht umgekehrt!
Die Parameter könnten sonst gecleart werden

[haentschman]

Zitat:

Das steht im Source-Code von TDataSet!

...da gehört es auch hin (ohne Gewähr). Aber nicht vor SQl.Text im eigenen Quellcode.

Noch ein Hinweis:
Die ungarische Notation (DatenTyp vor Variablen) ist heute nicht mehr üblich. Besser vernüftige Benamsung...https://de.wikipedia.org/wiki/Ungarische_Notation Abschnitt: Kritik.