4. mysql SELECT-Anweisung

mysql SELECT-Anweisung

  • C
     

    if (Query1->Active==true) 
   Query1->Close();

Query1->SQL->Clear(); 
Query1->SQL->Add("SELECT nick,.... FROM userdaten WHERE nick= '"+UserID+"'"); 
//UserID ist String sonst geht das nicht ohne Datenkonvertierung
//Wenn Du die Spalten kennst, die Du abfragen möchtest, dann verzichte auf den Joker
Query1->Open(); 
// Datenmenge muß vor Zuweisung in Variabelen etc. geöffnet werden !!
// ExecSQL kann bei Select weggelassen werden

asNickname=Query1->FieldValues["nick"]; // geht bei bekannten Spalten

    Vielleicht hilft das.

    0
  • ?

    Bin wohl irgendwie zu blöd ...

    Query2->Close();
    Query2->SQL->Clear();
    Query2->SQL->Add("SELECT nick FROM userdaten WHERE id='1'");
    Query2->Open();
    String Nickname = Query2->FieldValues["nick"];

    "Query2: Cannot perform this operation on a closed dataset"

    Das einfügen funktioniert, also eine Verbindung zur Datenbank besteht.

    0
  • ?

    Edit:
    nun klappt es doch ... 🙂
    Vielen Dank

    0
  • ?

    Hab dann noch ein kleines Problem O.o

    Login_Check->Close();
    Login_Check->SQL->Clear();
    Login_Check->SQL->Add("SELECT * FROM userdaten WHERE nick='"+add_nick->Text+"' AND pass='"+add_pass->Text+"'");
    Login_Check->Open();

    String UserID = Login_Check->FieldValues["id"];
    Form1->Caption = UserID;

    Wenn das falsche PW oder der falsche Nick eingetragen wird, dann ist Login_Check... NULL und das kann nicht als String deklariert werden ... Bekomm immer die Meldung:

    "Could not convert variant of type (Null) into type (String)"

    0
  • B

    Du könntest ja darauf testen.

    Variant var = Login_Check->FieldValues["id"];
String UserID = var.IsNull() ? "" : var;
    0
  • ?

    "Two operands must evaluate to the same type"

    0
  • ?

    Die Idee ist aber gut 🙂
    Ich werd mal nen bisschen weiter testen.

    0
  • K
    Mod

    Hallo

    wie waere es mit ainem Test der Rueckgabe
    (Tip -> RecordC....)

    Mfg
    Klaus

    0
  • -

    Braunstein schrieb:

    Du könntest ja darauf testen.

    Variant var = Login_Check->FieldValues["id"];
String UserID = var.IsNull() ? "" : var;

    "Two operands must evaluate to the same type"

    Variant var = Login_Check->FieldValues["id"];
String UserID = var.IsNull() ? String("") : String(var);

    Oder so ähnlich... Problem ist jedenfalls, das der Rückgabewert in beiden fällen identisch sein muss.

    (Tip -> RecordC....) finde ich persönlich aber auch schöner 😉

    mfg
    xXx

    0
  • B

    Ich stimme da in beiden Fällen zu. Casten nach AnsiString oder Umwandeln von operator ? nach if würden das Zuweisungsproblem lösen. Anwendung von RecordC... ist aber besser.

    0
  • ?

    Hm, ich weiß nicht so recht... Die Verwendung von RecordC... ist eigentlich nur ein SELECT COUNT(*) auf eine Datenmenge. Da dazu innerhalb der Datenmenge bis zum letzten Datensatz iteriert werden muß und ansschließend wieder auf den ersten DS gesprungen werden muß...
    Also gleich einfach nur versuchen, die Datenmenge auf den ersten DS zu setzen.

    0
  • C

    Bei Problemen mit SQL NULL-Werte ändere einfach Deine SQL-Abfrage.

    Bei MS-SQL müßte sie so lauten

    select ISNULL(nick,'') ... //ISNULL bewirkt die Umwandlung von NULL in einen anderen Wert - hier Leerstring

    Bei mySQL gibt es garantiert eine äquivalente Funktion (vieleicht mit anderem Namen [in Centura = @NullValue]).

    Wenn es darum geht zu sehen, ob die Auswahl eine Menge zurückgibt, teste mit RecordCount

    if (Query->RecordCount>0) {
//...
// hier die Zuweisungen auf Variablen etc.
}
    0
  • ?

    caspar_louis schrieb:

    Wenn es darum geht zu sehen, ob die Auswahl eine Menge zurückgibt, teste mit RecordCount

    Eben das würde ich nicht tun. Begründung steht oben.

    0
  • C

    Dann frag doch gleich mit select Count(*) ... ab. Noch Schneller geht dann wirklich nicht, wobei ich bezweifle, daß Du mit RecordCount ein Geschwindigkeitsproblem haben wirst. Du hast Dein Select ja ziemlich eingeschränkt. .... und eine leere Datenmenge hat keinen ersten Datensatz !

    0
  • ?

    In diesem Fall ist die Tabelle wohl winzigst und es wird keine Millisekunde Unterschied machen. Aber wenn die Tabellen mal größer werden kann es einen Unterschied machen.
    Vielleicht bin ich in dem Punkt auch einfach nur zu empfindlich. Aber wenn man jahrelang einen völlig unterdimensionierten Datenbankserver hatte...

    0
  • C

    Bei einer Tabelle mit ca. 3,5 Mio DS dauert eine select count(*)... Abfrage im Query Analyzer ca. 6 Sekunden, wenn Tabelle nicht im RAM des Servers gepuffert ist. Ca. 8 Sekunden braucht RecordCount und ADOQuery über SQLOLEDB.
    Der Unterschied sollte also auch bei großen Tabellen zu vernachlässigen sein.

    0
  • ?

    Schon komisch. Auf unserer informix-DB dauert ein RecordCount (ca. 1,5 Millionen DS) ca 34 Sekunden, ein SELECT COUNT wird in weniger als 1 ms zurückgeliefert. Das ist dann doch schon ein gewaltiger Unterschied. (Beides über Frontend: ADO / OLEDB.)

    0
  • C

    34 sec .... 👎 Ich hätte schon bei 8 sec so meine Probleme (wenn's nicht gerade die History-Tabelle ist).

    0
Anmelden zum Antworten