ADOQuery - SQLQuery ??

[HolgerX]

Hmm..

Zitat:

Zitat von haentschman (Beitrag 1368105)

3. In welchen Büchern steht sowas drin? :gruebel: 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. 8-)

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.

[xReva]

Zitat:

Zitat von HolgerX (Beitrag 1368104)

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:

Zitat von xReva (Beitrag 1368116)

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:

Delphi-Quellcode:

.Value='Wert1;

und

Delphi-Quellcode:

.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

[MichaelT]

Je nachdem :)

Du hast in der MS Welt in der Regel ein paar historische gewachsene Geschichten
a) Die Client Library welche mit der Datenbank kommuniziert. libmysql.dll
a1) zu der gibt es ein Header File bspw. für C Programmierung
a2) jede Datenbank hat eine eigene Bibliothek/Library für den Zugriff
a3) jeder nennt die Funktionen für den Zugriff auf eine Datenbank anders und sie verhalten sie anders
b) Als Datenbanken aufkamen hatte jeder Schuppen nur eine. Mit der Zeit wollten die Kunden oder Werkzeughersteller aber nicht auf dieser Ebene eine Abhängigkeit vom Hersteller einhandeln. Deswegen wurden Standards beschlossen. Einer davon wäre bspw. ODBC realisiert über einen Treiber
b1) CLANG bspw. wäre ein Treiber für verschiedene C/C++ Compiler.
b2) MS hatte keine Datenbank und war als 'Werkzeughersteller' an Normierung interessiert
c) Ein Treiber harmonisiert weitestgehend die unterschiedlichen Funktionsname und das Verhalten seiner Funktionen in Richtung des Programmierwerkzeugs
c1) ODBC, OLEDB, DBX, BDE (Borland Database Engine aus DOS Zeiten).
c2) Ein Treiber nutzt an sich die Funktionen der Client Library wie er will

Ebene Progammierumgebung und Komponenten
d) Microsoft hatte 2 Komponentenarchitekturen DAO und RDO (Remotekomummikation zu einer DB ohne (komplexen) Treiber am Client) die später durch ADO wurden abgelöst. Die Sicht Table, Query, Stored Procedures als Komponenten stammt eher aus der DA Sicht. Diese Sicht ist aber weder berühmt noch abwegig.
d1) Du empfängst immer Ergebnisse einer Abfrage. Es gibt auch Bibliotheken in C/C++ die solche Ergebnisse als Stream behandeln.
e) Borland/Embarcadero hatte ihre Borland Database Engine und auch DBExpress. Aus DB Express stammt die TSQLQuery.
f) MS ging dann her und hat in ADO (ActiveX Data Object) das Konzept der Tables, Queries usw. harmonisiert und als ein Ergebnis der Harmonisierung ging das 'Command' hervor. ADOCommand, ADO.net Command. So ein ähnliches Konzept findet sich auch in FireDAC wieder. *)
g) Die Harmonisierung der verschiedenen Konstrukte (Query, Table, usw...) bei Borland erfolgte über den TDataSet und bei MS war es der Command.
g1) Eine Query im U.S. Sprachgebrauch ist eigentlich eine parametrierbare View. Wenige Datenbanken kann zu Beginn Views und manche wie X-Base Datenbanken gar nicht. Ein Zeit nahm der Table diese Rolle ein und die Query war eher fokussiert auf DML Statements. Kurz danach gesellte sich wieder der ResultSet (Abfrageergebnis) zur Query hinzu.

*) Eigentlich kümmert sich ein Command um das SQL Statement (Query, Table, Stored Procedures basieren auf Commands und auch andere Komponenten). Ein SQL Statement kennt Ergebnisfelder und Bind Variablen in erste Linie.

Im Delphi selbst gibt es eine zentrale Komponente die eigentlich alles macht und diese ist die *Connection*.

(*
Die Query ist, wie in den Filmen aus den 80ern mit den blonden Business Ladies mit den großen Brillen welche gestresst in Bürotürmen vor einem Terminal saßen und tonnenweise Endlospapier am Schreibtisch liegen hatten, die Businesssicht bezogen auf einen Datenbestand in Beziehung zu einem einen Arbeitsplatz, ein Ergebnis angezeigt auf einem Terminal (IBM Host) welche auf einem Report wurde gedruckt. QMF (Query Management Facility) erinnert noch dran. Damals war die DB noch eine logische schicht gleichstrukturierte Dateien. Deswegen sind die Queries im SQL Server auch als eine Businesssicht vorhanden. Eine Query ist an sich kein SQL-Statement, eine Query kann auf einem solchen basieren.

QMF in der Delphi Welt wäre 'Editing Data in FDMemTable at Designtime'.
*)

Eine Connection sofern die Komponenten (d) bis g) )nicht direkt auf einer Client Library aufsetzt bemüht einen Treiber. Das kann sein ein ODBC Treiber, ein OLEDB Treiber oder (OLDEB über ODBC), ein DBX (DB Express) Treiber. Heute macht eher die Connection die Arbeit und mithilfe einer Query beschreitet der Entwickler einen mehr oder minder komfortablen einheitlich Weg eine Abfrage zusammenzustöpseln.

Die Queries der Borland Welt halten zwecks Navigierbarkeit das Ergebnis der Abfragen in 'ihrem' Puffer. Pures ODBC macht das nicht.

Normalerweise wird beim Parsen eines SQL Statements nach Bind Variables gesucht ':' vor dem Namen.

a) Ein Field ist ein Wert (Zelle) in einer Zeile eines Abfrageergebnisses.
b) Eine FieldDefinition ist ähnlich der Definition einer Column in einer DB (vereinfacht gesagt). Eigentlich ein Beschreibung von beliebigen Bytes im Ergebnispuffer. Man kan vereinfacht sagen, eine Query gibt eine neue Tabellenstruktur mit Zeilen zurück (Dynamisch erzeugter Typ) vs. dem Statischen Datenbanktabelle.
c) Param ist eine Bind Variable

Die Defintion eines Parameters einer Abfrage und einer Felddefintion beschreibt bestenfalls mal in erster Linie die Interpretation des übergebenen Werts (sagen wir mal so).

Du brauchst die Connection damit überhaupt irgendein Teil der Software die Abfragen wegschickt, die Ergebnisse in Empfang nimmt, die Transaktion handelt (DB Connection hat Transaction) usw...

TSQLConnection wäre dann die Verbindung zur Datenbank welche DBX (DB Express) Treiber bemüht, die greifen ihrerseits auf die DBClientLibrary (bspw. libmysql.dll) zu . DBX hat noch dazu Treiber die man stacken kann (vergiss das für den Moment).

Den Rest haben dir die das Forum Bewohnenden schon geschrieben.

Zitat:

Zitat von xReva (Beitrag 1368072)

[/DELPHI]

[xReva]

Ich habe das ganze jetzt so gemacht und es treten auch keine Probleme auf allerdings wird in der Datenbank auch nichts verändert.

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin

ADOQuery1.SQL.Text := 'Select * from taccounts';
ADOQuery1.Open;
ADOQuery1.Append; //ein leerer Datensatz hinzu
ADOQuery1.FieldByName('nEMID').AsInteger := 4;
ADOQuery1.FieldByName('sUsername').AsString := 'Hallo';
ADOQuery1.FieldByName('sUserPass').AsString := 'Hallo1';
ADOQuery1.FieldByName('sUserPassSalt').AsString := 'Hallo1';
ADOQuery1.FieldByName('sEmail').AsString := 'Hallo1';
ADOQuery1.FieldByName('nAuthID').AsInteger := 4;
ADOQuery1.FieldByName('sIP').AsString := '127.0.0.1';
ADOQuery1.Post; //abschicken
ADOQuery1.ExecSQL;

end;

[p80286]

Weil ein "Select" Daten von einer DB holt,
und ein "Insert" oder "Update" Daten(Änderungen) in sie schreibt.
(vgl #16 )

Gruß
K-H

[xReva]

oh man ja ergibt sinn aber wie muss ich das dann schreiben? so?

Delphi-Quellcode:

ADOQuery1.SQL.Text := 'Insert into * from taccounts';
ADOQuery1.Open;
ADOQuery1.Append; //ein leerer Datensatz hinzu
ADOQuery1.FieldByName('nEMID').AsInteger := 4;
ADOQuery1.FieldByName('sUsername').AsString := 'Hallo';
ADOQuery1.FieldByName('sUserPass').AsString := 'Hallo1';
ADOQuery1.FieldByName('sUserPassSalt').AsString := 'Hallo1';
ADOQuery1.FieldByName('sEmail').AsString := 'Hallo1';
ADOQuery1.FieldByName('nAuthID').AsInteger := 4;
ADOQuery1.FieldByName('sIP').AsString := '127.0.0.1';
ADOQuery1.Post; //abschicken
ADOQuery1.ExecSQL;