Gateway_man Geschrieben 29. Dezember 2010 Teilen Geschrieben 29. Dezember 2010 Guten Morgen, folgendes Problem besteht: Ich habe eine MySQL Datenbank in der eine Tabelle User existiert. Diese verfügt unter anderem über die Spalten Username und Password. Jetzt hatte ich mir eine Funktion in Java geschrieben, die überprüfen soll ob ein solcher Useraccount existiert. Siehe hier: public boolean Authenticate(String User,String Pass){ boolean lresult = false; if(!(User==null && Pass==null)){ try { Statement cmd = con.createStatement(); ResultSet ada; ada = cmd.executeQuery("Select count(*) From ems.tbl_user Where Username='" + User + "' AND Password='" + Pass + "'"); int response = 0; while(ada.next()){ System.out.println(ada.getObject(1).toString()); } if (response>0){ lresult=true; this.User = User; this.Pass = Pass; bAuth = true; } } catch (SQLException e) { e.printStackTrace(); } } return lresult; } Egal wie ich es drehe und wende der Loop des ResultSets liefert mir immer als Count Ergebniss 0. Wenn ich aber in meine mysql console gehe und selbiges Statement mit selbigen User-Login-Daten ausführe, dann erhalte ich als Count Ergebniss 1. Ich bin mit meinem Latein am Ende. Wenn jemand was sieht wäre ich sehr erfreut. PS: An der SQL-Connection kanns nicht liegen, da er nicht in den Catch Block springt. lg Gateway Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 29. Dezember 2010 Teilen Geschrieben 29. Dezember 2010 Erst einmal würde ich Prepare Statements verwenden, das ist sicherer. Du brauchst auch kein while next, denn nach der Definition steht nach einer Query der Zeiger vor dem ersten ersten Datensatz, d.h. ein einfaches if (ada.next) reich aus. Weiterhin liefert count(*) einen numerischen Typ (int) und kein Objekt oder String Außerdem würde ich hier nicht via Count prüfen, sondern auf die Existentz des Datensatzes. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gateway_man Geschrieben 29. Dezember 2010 Autor Teilen Geschrieben 29. Dezember 2010 Danke, ich hatte bereits getInt(columindex), allerdings hatte er mir dann auch 0 zurückgegeben, dann wollte ich es eben mal anders versuchen . Ich prüfe doch auf Existens. Ich gebe die Filterfunktionen an und wenn ein Datensatz vorhanden ist dann existiert der User. (Wohl gemerkt ist das so geregelt das jeder Username eindeutig ist). Ich glauble zwar nicht das es nur am while Konstrukt liegt aber ich werds mal ändern. lg Gateway Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gateway_man Geschrieben 29. Dezember 2010 Autor Teilen Geschrieben 29. Dezember 2010 Okay das hat sich erledigt. Das Password das übergeben wurde, stammt von einem JPasswordField. Was mich etwas verwundet ist, das die Property getPassword mir kryptische Zeichen zurückgibt. Jetzt nutze ich getText (und ja ich weiß das es Obsolet ist aber wenns nicht funktioniert...). lg Gateway Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 29. Dezember 2010 Teilen Geschrieben 29. Dezember 2010 Ich prüfe doch auf Existens. Nein, ein count(*) wird _immer_ eine Row zurück liefern, das Feld enthält allerdings dann 0. Wenn Du ein Select * machen würdest und Username und Passwort stimmen nicht, dann würde das next() false liefern. Letzteres ist die Prüfung auf Existenz Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gateway_man Geschrieben 29. Dezember 2010 Autor Teilen Geschrieben 29. Dezember 2010 Das was ich oben gemacht habe war ja nur zu testzwecken. So hatte ich es vorher: public boolean Authenticate(String User,String Pass){ boolean lresult = false; if(!(User==null && Pass==null)){ try { Statement cmd = con.createStatement(); ResultSet ada; ada = cmd.executeQuery("Select count(*) From ems.tbl_user Where Username='" + User + "' AND Password='" + Pass + "'"); int response = 0; while(ada.next()){ response=ada.getInt(1); } if (response>0){ lresult=true; this.User = User; this.Pass = Pass; bAuth = true; } } catch (SQLException e) { e.printStackTrace(); } } return lresult; } Count liefert immer eine Row zurück deswegen prüfe ich ja auch den Wert des Counts. Wenn dieser größer als null ist, dann existiert der User.... lg Gateway Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 29. Dezember 2010 Teilen Geschrieben 29. Dezember 2010 Count liefert immer eine Row zurück deswegen prüfe ich ja auch den Wert des Counts. Wenn dieser größer als null ist, dann existiert der User.... Ja und genau das ist nicht notwendig und Du brauchst auch keine While Schleife Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gateway_man Geschrieben 29. Dezember 2010 Autor Teilen Geschrieben 29. Dezember 2010 Vielen Dank. Das Resultat sieht jetzt wie folgt aus: public boolean Authenticate(String User,String Pass){ boolean lresult = false; if(!(User==null && Pass==null)){ try { Statement cmd = con.createStatement(); ResultSet ada; ada = cmd.executeQuery("Select * From ems.tbl_user Where Username='" + User + "' AND Password='" + Pass + "'"); if(ada.next()){ UID = ada.getInt(1); lresult=true; this.User = User; this.Pass = Pass; bAuth = true; } } catch (SQLException e) { e.printStackTrace(); } } return lresult; } lg Gateway Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 29. Dezember 2010 Teilen Geschrieben 29. Dezember 2010 Jetzt noch ein PrepareStatement, dann finde ich es perfekt.... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 6. Januar 2011 Teilen Geschrieben 6. Januar 2011 Jetzt noch ein PrepareStatement, dann finde ich es perfekt.... Naja das Teil ist weit davon entfernt perfekt zu sein: 1. Fehlerbehandlung. Der Aufrufer kriegt davon nichts mit und es wird einfach weitergemacht, des weiteren verschwindet die Meldung einfach auf der Konsole. Eine "perfekte" Methode würde das via Log4J wegschreiben. 2. Ressourcen werden nicht im finally Block freigegeben. Je nach Implementierung des JDBC Treibers kann das dann irgendwann zu Problemen führen, vor allem, wenn an anderer Stelle auch so schludrig mit DB-Ressourcen umgegangen wird. 3. Bei einer reinen Existenzprüfung sollte immer ein COUNT verwendet werden anstatt den kompletten Datensatz zurückzuliefern. Das ist deutlich performanter. Insb. wenn auf die Maschine mal Last kommen sollte, wirkt sich das positiv aus. Die while Schleife kann man sich in diesem Fall auch sparen. Das PrepStatement wurde ja schon erwähnt. Als weitere Verbesserung wäre noch anzubringen, dass Methoden und Variablennamen im allgemeinen mit einem Kleinbuchstaben beginnen. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gateway_man Geschrieben 6. Januar 2011 Autor Teilen Geschrieben 6. Januar 2011 Nehmen wir mal an ich hätte diese Testroutine so 1zu1 ins Projekt übernommen . Trotzdem danke für deine Ratschläge. lg Gateway Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.