I found this problem in my work: in Oracle versions earlier than 10 Gb, there is a bug that PreparedStatement preprocessing is used to dynamically query data, using placeholders? If the field is of the char type, it is used to replace it during execution? The variable must be the same as the length of the field. If the length of the field is insufficient, fill in enough digits with spaces. Otherwise, no correct results can be found. If this field is not of the char type, this problem does not exist.
Yesterday, a strange problem occurred. hibernate obtained data through the entity Id (char (10) type), session. find ("from TableName where id =? "," Value ");
No data is obtained, but the database contains this data. It was really strange. Later I used pl/SQL to look at the database. When I clicked on the Id, I could see some spaces behind the content. I made the values in the field with expectation and question, and made the session. find ("from TableName where id =? "," Value "); can be found later.
I specially tried connection. createStatement ("select * from table_name where id = 'value '");
The data is normally retrieved, session. find ("from TableName where id =? "," Value ");
But I couldn't find the data, and then I tried again.
Ptmt = connection. prepareStatement (select * from table_name where id =? ");
Ptmt. setString (1, "year ");
This does not work either. The conclusion is: The jdbc-driven PrepareStatement queries the char field type, because hibernate uses PrepareStatement. Naturally, hibernate cannot find the attribute conditions corresponding to char,
Solution:
1. TRIM function processing is used for attributes: session. find ("from TableName where TRIM (id) =? "," Value ");
2. Change the char type to varchar2.
I tried mysql today and it won't be like this, so the conclusion is: Oracle JDBC PreparedStatement bug (it may have deliberately)