mysql SELECT-Anweisung
-
Hallo
wie waere es mit ainem Test der Rueckgabe
(Tip -> RecordC....)Mfg
Klaus
-
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
-
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.
-
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.
-
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. }
-
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.
-
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 !
-
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...
-
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.
-
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.)
-
34 sec ....
Ich hätte schon bei 8 sec so meine Probleme (wenn's nicht gerade die History-Tabelle ist).