ADOQuery - SQLQuery ??

[xReva]

Hallo, Ich bin jetzt seit ca 2 Monaten dabei Informatik zu studieren allerdings geht es mir dort noch etwas zu langsame voran von daher mache ich ziemlich viel hobbymäßig alleine zuhause.

Nun zu meiner frage wollte mich mal mit Datenbankverbindungen ausprobieren und habe mir dafür eine Mysql datenbank angelegt und kann von dort auch daten auslesen überprüfen und anzeigen lassen.

Mein Problem liegt nun beim hinzufügen von daten. 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.
Dann habe ich es mit einer SQLQuery versucht und habe auch alles ohne fehlermeldung hinbekommen bis zu dem Punkt das ich überhaupt nicht weiß wie ich die SQLQuery mit der Datenbank verbinde. Mit der ADOQuery habe ich es ja über die ADOConnection gemacht von daher gehe ich aus das auch irgendwie mit der SQLConnection zusammenhängt allerdings weiß ich nicht so recht wie ich das hinkriegen soll.
Sorry wenn das für die meisten wohl nach etwas wirrwarr klingt aber ich bin noch recht neu in dem bereich.

Ich hänge auch noch mal den Code ran da ich mir halt ziemlich unsicher in der ganzen Geschichte bin, ich hoffe mir kann hier weitergeholfen werden.

Mfg Lucas

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin

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('Username').Text:=edit3.text;
SQLQuery1.ParamByName('UserPass').Text:=edit4.text;
SQLQuery1.ParamByName('UserPassSalt').Text:=edit5.text;
SQLQuery1.ParamByName('email').Text:=edit6.text;
SQLQuery1.ParamByName('AuthID').Value:='4';
SQLQuery1.ParamByName('email').Text:=edit7.text;

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

SQLQuery1.ExecSQL();

SQLQuery1.SQL.Clear;
SQLQuery1.Params.Clear;

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

[jobo]

Welche Delphi Version benutzt Du?

Dein Weg, die Connection herzustellen ist sicher falsch.

Schau mal hier:
http://docwiki.embarcadero.com/RADSt...SQL_Connection
bzw.
http://docwiki.embarcadero.com/RADSt...sing_TSQLQuery

Ich bin mir nicht sicher, aber braucht man nicht mindestens eine Professional Version dafür?

Ansonsten wüsste ich nicht, warum es nicht auch mit ADO gehen sollte:
http://docs.embarcadero.com/products...arameters.html

[DeddyH]

Müsste es bei ADO nicht eher so lauten?

Delphi-Quellcode:

SQLQuery1.Parameters.ParamByName('Username').Value := edit3.text;

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

[haentschman]

[meine Meinung]
Hallöle...:P

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. :warn:

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. :zwinker:
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.
[/meine Meinung]

[p80286]

Zitat:

Zitat von xReva (Beitrag 1368072)

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

Delphi-Quellcode:

.Value:=Irgendwas;

nutzen vgl- #6 um die Werte zu übergeben und der Update wird mit

Delphi-Quellcode:

.ExecSQL

und nicht mit

Delphi-Quellcode:

.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.

[xReva]

Kann man das ganze eigentlich auch irgendwie ohne Parameter machen so in die richtung?

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin

ADOQuery1.SQL('EMID').Values := '4';
ADOQuery1.SQL('Username').Text := edit3.Text;
ADOQuery1.SQL('UserPass').Text := edit4.Text;
ADOQuery1.SQL('UserPassSalt').Text := edit5.Text;
ADOQuery1.SQL('email').Text := edit6.Text;
ADOQuery1.SQL('AuthID').Values := '4';
ADOQuery1.SQL('sIP').Values := '127.0.0.1';


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

ADOQuery1.ExecSQL();

[haentschman]

@p80286

Zitat:

unter D7 geht kein weg an .Value vorbei

...upps. :oops: 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. :zwinker:

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

[Olli73]

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

Evtl. fehlt noch ein ADOQuery1.Connection.CommitTrans;

[xReva]

So gibt er ne Fehlermeldung aus : No Transaction active

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin

ADOQuery1.Connection.CommitTrans;
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



end;

[Olli73]

Zitat:

Zitat von xReva (Beitrag 1368142)

So gibt er ne Fehlermeldung aus : No Transaction active

Das muss natürlich ans Ende. Aber ob ADO überhaupt standardmäßig automatisch Transaktionen startet weiß ich nicht.

[xReva]

Am ende hatte ich das schon er sagt immer das keine Transaction aktiv ist. Ohne das Command funktioniert es zwar fehlerfrei allerdings wird auch kein Db eintrag hinzugefügt.


Mfg Lucas

Delphi-Quellcode:

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.Connection.CommitTrans;

[Olli73]

Wenn das fehlerfrei durchläuft, steht der Eintrag auch in der DB.

Wie prüfst du denn, ob der neue Eintrag da ist?

[HolgerX]

Hmm..

ADO braucht BeginTrans..
Ein ComitTrans brauchst DU auch nur machen, wenn Du bei ADO vorher ein BeginTrans gemacht hast.

Aber, wieso gehst Du denn nun den Weg mit Append/Post?

Ein Insert ist immer performanter, außer, Du hast die Datenmenge bereits zur Anzeige in z.B. eines DBGrids offen.

In meinem ersten post (#6) habe ich Dir eine korrigierte und lauffähige Lösung aufgezeigt.
Schade, dass Du sie nicht verwendest.

Hast Du überhaupt Schreibrechte auf die MySQL-DB?

Mit der Zeile

Delphi-Quellcode:

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

hättest Du auch eine Prüfung, ob der Insert erfolgreich gewesen ist.

[xReva]

Ich überprüfe das direkt in der mysql Datenbank.


Holger danke für deine Antwort ich habe deine Lösung gesehen und auch ausprobiert allerdings erkennt er in dem Code block :

Delphi-Quellcode:

ADOQuery1.ParametersByName('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'

ParamByName muss bei der ADOQuery ja ParameterByName heißen richtig? Weil den teil ParamByName sieht er als fehlerhaft an genau wie .Value


Mfg Lucas

[HolgerX]

Hmm..

Ok, richtig..

Müsste so lauten:

Delphi-Quellcode:

ADOQuery1.Parameters.ParamByName('sUsername').Value :=

Das natürlich bei allen Parameter..

Es fehlte das Parameters

[xReva]

Jetzt sagt er mir Missing Sql Property :/

[HolgerX]

Hmm..


Dann zeig uns erstmal deinen jetzigen Source und die Stelle, an der die Fehlermeldung angezeigt wird..

[xReva]

http://prntscr.com/exylrv Da ist der Fehler zu sehen

Delphi-Quellcode:

unit try3;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Data.DB, Data.Win.ADODB,ShellAPI,
  Data.FMTBcd, Data.SqlExpr;

type
  TForm1 = class(TForm)
    Edit2: TEdit;
    Label1: TLabel;
    Label2: TLabel;
    Edit1: TEdit;
    ADOConnection1: TADOConnection;
    ADOQuery1: TADOQuery;
    Button1: TButton;
    Button2: TButton;
    Edit3: TEdit;
    Edit4: TEdit;
    Edit5: TEdit;
    Edit6: TEdit;
    Edit7: TEdit;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('select * from taccounts where susername='''+edit1.Text+''' and suserpass='''+edit2.Text+''' ');
ADOQuery1.Open;
if not ADOQuery1.Eof then
begin
ShellExecute(Application.Handle, 'open', PChar('C:\Program Files (x86)\Internet Explorer\iexplore.exe'), nil, nil, SW_NORMAL);
end
else


ShowMessage('Falscher Benutzername oder Password!');
end;

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

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

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

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

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

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

    ADOQuery1.Open;



    ADOQuery1.Close;
  end;
end;




end.

[HolgerX]

Dann schaue DIr doch mal diese Zeilen an:

Zitat:

Zitat von xReva (Beitrag 1368157)

Delphi-Quellcode:

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

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

    ADOQuery1.Open;
    ADOQuery1.Close;
  end;
end;

Ich sag nur 'Clear' -> 'Open'!
Was soll denn da für ein SQL-Befehl geöffnet werden?

Wenn Du das nach dem dem ExecSQL nicht mehr brauchst, dann kannst Du es auch weglassen.

[xReva]

Oh man jetzt kriege ich diese Meldung : http://prntscr.com/exzfpl

[nahpets]

Mir ist nicht klar, was Du hiermit bezweckst:

Delphi-Quellcode:

 // Wurde ein Datensatz eingefügt? 
 if (ADOQuery1.ExecSQL() = 1) then begin 
    // Lösche das letzte SQL
    ADOQuery1.SQL.Clear;
    // und führe nun das nicht existierende SQL aus?
    ADOQuery1.Open;
    // Und schließe es sofort?
    ADOQuery1.Close;
  end;

Das Open setzt das Vorhandensein eines gültigen SQL-Statements voraus, kann daher nach einem ADOQuery1.SQL.Clear nur zu der von Dir erhaltenen Fehlermeldung führen, da dann kein SQL-Statement mehr vorhanden ist.

[xReva]

Also wenn ich das open und das close rausnehme kommt keine Fehlermeldung mehr allerdings passiert in der db auch nichts x.x

[xReva]

http://prntscr.com/ey01qv das ist die datenbank + source code

[p80286]

könnte es sein, daß da noch ein "commit" fehlt bzw. Autocommit nicht auf true steht?

Gruß
K-H

[xReva]

Wo finde ich denn Autocommit?

[Poelser]

In der Datenbank-Connection.

Bis denne,
Poelser

[haentschman]

Moin...:P
@xReva: Warum hängst du die Screenshots nicht an den Beitrag an?
1. Irgendwann ist das Original verschwunden und der Beitrag ist nicht mehr vollständig. :?
2. Die meisten weigern sich Scripte auf der Internetseite in Übersee (automatisch) auszuführen um nur das Bild zu sehen. :evil:

zum Thema:
Diesen Teil verstehe ich von der Logik nicht:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  ADOQuery1.SQL.Clear; // kann weg wenn du SQL.Text verwendest
  ADOQuery1.SQL.Add('select * from taccounts where susername='''+edit1.Text+''' and suserpass='''+edit2.Text+''' '); // besser Parameter und SQL.Text
  ADOQuery1.Open;
  if not ADOQuery1.Eof then // du erwartest nur einen Datensatz, warum die Bedingung auf EOF?
  begin
    // nur den Internetexplorer öffnen und nichts damit machen? Das könnte auch ohne Benutzernamen geschehen *grübel*
    ShellExecute(Application.Handle, 'open', PChar('C:\Program Files (x86)\Internet Explorer\iexplore.exe'), nil, nil, SW_NORMAL);
  end
  else
    ShowMessage('Falscher Benutzername oder Password!');
end;