Fehler beim matchen von Strings via Query

[neomizer]

Tach Zusammen,

ich habe ein ziemlich stranges Problem, wenn ich versuche einen String per SQL zu vergleichen. Ich habe (als Teil einer größeren Anwendung, deswegen hier nur ein ganz kleiner Ausschnitt) eine Tabelle mit Freitexten

create table all_values(
id int(11) PRIMARY KEY not null,
value text)

Nun hole ich mir eine Liste aller values und versuche danach die id's anhand der values herrauszufinden:

"select * from all_values where value=\""+value+"\";

Der Witz ist nun, dass dies bei ca. 100 Werten (von 10k) nicht klappt. Wenn ich allerdings folgendes mache, dann klappt es (und da hört irgendwie mein Verständnis auf):

"select * from all_values where value=\""+value+"\" and id="+id+";

Die Tabelle ist UTF-8. MySQL 5.0.18 und MySQL-Connector 3.1.12.

Folgender Beispiel-Code:

	private void testDbValuesOhnePrep(){
		try{
			String statement = "select id,value from all_values;";
			Statement stmt = _conn.createStatement();
			ResultSet result = stmt.executeQuery(statement);
			
			Hashtable<Integer,String> hash = new Hashtable<Integer,String>();
			while (result.next()){
				hash.put(result.getInt(1),result.getString(2));
			}
			result.close();
			
			int counter = 0;
			for (int key : hash.keySet()) {
				// Dies würde klappen
				//String statement2 = "select * from all_values where value=\""+hash.get(key)+"\" and id="+key+";";
				// Dies klappt nicht immer
				String statement2 = "select * from all_values where value=\""+hash.get(key)+"\";";
				
				ResultSet result2 = stmt.executeQuery(statement2);

				if(!result2.next()){
					counter++;
					System.out.println("fehler bei id "+key+" und value <"+hash.get(key)+">");
				}
				result2.close();
			}
			System.out.println("ingesamt "+counter);
		} catch (SQLException e){
			e.printStackTrace();
		}
	}

Da ich mit meinem Latain nun langsam am Ende bin, bin ich für jede (noch so abwegige) Idee dankbar!!

Gruß, Mark

PS: Die Werte, bei denen das matchen nicht klappt, weisen keine besondere Charakteristika auf...

 

[Kawa-Mike]

Der Value ist ein String.
Versuch doch einmal folgendes:
String s = (String)hash.get(key);
oder
String s = hash.get(key).toString();

und setze den den String in deine SQL-Query ein.
Evtl. gibt es Problem, weil die Hashtable ja ein Object zurückliefert, das einen String enthält, und nicht einen String.

2.)
du kannst auch ein Prepared Statement benutzen. Falls in deinen Werten Sonderzeichen wie z.b. ' " % ? vorkommen, kann die Abfrage verfälscht werden. Nutzt man Prepared Statements, so werden alle Sonderzeichen gequotet.

Gruss
Mike
P.S. Bitte gib mir ein kurzes Feedback, falls es geklappt hat.

 

[neomizer]

Hi!

Der Value ist ein String.
Versuch doch einmal folgendes:
String s = (String)hash.get(key);
oder
String s = hash.get(key).toString();

und setze den den String in deine SQL-Query ein.
Evtl. gibt es Problem, weil die Hashtable ja ein Object zurückliefert, das einen String enthält, und nicht einen String.

Naja, es ist ein Hash von (Integer,String), sprich ich bekomme einen String-Object zurück, bzw. der Compiler übernimmt das casten für mich. Im kompletten System prüfe ich u.a. auch auf String. Das ist also mit Sicherheit ein String Objekt.

2.)
du kannst auch ein Prepared Statement benutzen. Falls in deinen Werten Sonderzeichen wie z.b. ' " % ? vorkommen, kann die Abfrage verfälscht werden. Nutzt man Prepared Statements, so werden alle Sonderzeichen gequotet.

Hätte ich vielleicht mehr zu sagen sollen. Im kompletten System (der Code im Posting war nur eine Reduktion auf das Problem) benutzte ich Prepared Statements, ich habe dir nur als potentielle Fehlerquelle auch entfernt.

Mittlerweile habe ich leider herrausgefunden, dass das leider kein Java Problem ist, sondern nur MySQL: Ich kann das leider mit den MySQL-Client reproduzieren...
"Zum Glück" habe ich mich aber in der Version geirrt, die 5er läuft auf dem Produktivsystem, auf dem Testsystem läuft eine 4er Version (warum auch immer die beiden Versionen nicht gleich sind :-/).

Wobei es mich noch immer brennend interessiert, was das für ein Fehler ist...

Gruß, Mark