AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

ADOQuery - SQLQuery ??

Ein Thema von xReva · begonnen am 18. Apr 2017 · letzter Beitrag vom 24. Apr 2017
Antwort Antwort
Seite 2 von 6     12 34     Letzte » 
HolgerX

Registriert seit: 10. Apr 2006
Ort: Leverkusen
969 Beiträge
 
Delphi 6 Professional
 
#11

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 15:44
Hmm..

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

Geändert von HolgerX (18. Apr 2017 um 15:50 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.387 Beiträge
 
Delphi 12 Athens
 
#12

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 15:49
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.

Geändert von haentschman (18. Apr 2017 um 15:55 Uhr)
  Mit Zitat antworten Zitat
xReva

Registriert seit: 15. Nov 2016
20 Beiträge
 
#13

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 15:54
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
  Mit Zitat antworten Zitat
HolgerX

Registriert seit: 10. Apr 2006
Ort: Leverkusen
969 Beiträge
 
Delphi 6 Professional
 
#14

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 16:02
Hmm..


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 ).
  Mit Zitat antworten Zitat
sko1

Registriert seit: 27. Jan 2017
588 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#15

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 16:23
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
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#16

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 16:38
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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector

Geändert von p80286 (18. Apr 2017 um 16:40 Uhr)
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
555 Beiträge
 
Delphi 10.3 Rio
 
#17

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 16:57
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.


Geändert von MichaelT (18. Apr 2017 um 17:28 Uhr)
  Mit Zitat antworten Zitat
xReva

Registriert seit: 15. Nov 2016
20 Beiträge
 
#18

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 17:35
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;
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#19

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 17:53
Weil ein "Select" Daten von einer DB holt,
und ein "Insert" oder "Update" Daten(Änderungen) in sie schreibt.
(vgl #16 )

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
xReva

Registriert seit: 15. Nov 2016
20 Beiträge
 
#20

AW: ADOQuery - SQLQuery ??

  Alt 18. Apr 2017, 18:14
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;
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz