ADOQuery - SQLQuery ??

[haentschman]

@p80286

Zitat:

unter D7 geht kein weg an .Value vorbei

...upps. Das hatte ich bei dir übersehen. Sorry.

Zitat:

Hallo, Danke für die Antwort ich benutze momentan zuhause die Testversion was der Enterprise entspricht

...er hat die aktuelle Version. Da sollte es möglich sein.

[p80286]

Zitat von xReva:

Ich habe es zum großteil mit ADOConnection und ADOQuery gemacht allerdings wenn ich daten hinzufügen möchte muss ich dies ja über parameter tun und diese kann ich bei einer ADOQuery ja gar nicht erst hinzufügen wenn ich das richtig verstanden habe.

Zum einen, Du mußt nicht mit Parameteren arbeiten, aber es ist meist sinnvoll.
Z.B

Code:

update anytable (ID) values(nextkey.nextval)

kommt vollkommen ohne Parameter aus.
zum anderen mußt Du unter ADO .Value:=Irgendwas; nutzen vgl- #6 um die Werte zu übergeben und der Update wird mit .ExecSQL und nicht mit .Open abgeschickt

Gruß
K-H

@haentschmann
unter D7 geht kein weg an .Value vorbei, bei .asstring oder .asinteger bekommt der Compiler einen Schluckauf.
das .Asstring besser als das .Value wäre, darüber müssen wir nicht diskutieren.

[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 von xReva:

[/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;

[Olli73]

Nein, das Erste (#18) war schon richtig. Nur das ExecSQL ist zuviel.

Evtl. fehlt noch ein ADOQuery1.Connection.CommitTrans;