I have made the jdbc connection with the oracle database but I am not able to search for a particular record from the database. Actually I have made a drop down menu on the form from where member can select any entity for searching record for that entity. Now, what should be the sql query for searching that record. Can anyone plz answer my question.........?
select * from table where columnpickedfromcombobox like '%whattosearchfor%'
Look up JDBC: Connection, Statement, Resultset and you should be good.
gmaheshwari just check my reply to you for Searching from the database.
your query should contain variables..
and a String query using vairables would look like this:
statement.executeQuery("SELECT rented_or_not FROM rooms WHERE room_id = "+ room_id);
any way don't forget to check the reply...(^_^);
> gmaheshwari just check my reply to you for
> Searching from the database.
> your query should contain variables..
> and a String query using vairables would look like
> this:
> statement.executeQuery("SELECT rented_or_not
> FROM rooms WHERE room_id = "+ room_id);
>
> any way don't forget to check the reply...(^_^);
Don't do that, use PreparedStatement's instead.
> Don't do that, use PreparedStatement's instead.
you know i've should have taken your permission before thikning of the way that WORKS....
thanks anyway..(^_^);
> you know i've should have taken your permission
> before thikning of the way that WORKS....
> thanks anyway..(^_^);
I don't get your point, that sentence doesn't make sense to me.
> > Don't do that, use PreparedStatement's instead.
>
> you know i've should have taken your permission
> before thikning of the way that WORKS....
> thanks anyway..(^_^);
Concatenating strings together to hobble together an SQL statement is perfectly valid and "WORKS", however, when anyof those variables might possibly contain user entered information (or any other data that is outside of your control) it is dangerous to use it in such a way.
In those cases you should always use a PreparedStatement and the proper set...() method. Otherwise you are leaving yourself open for a world of pain in the form of an SQL injection attack (since I didn't notice you making any effort before building the SQL statement to ensure that none of the contents of the variables used contained anything that could have messed up your SQL statement, i.e. a ' or something similar and possibly much more sinister).
Food for thought.
> Concatenating strings together to hobble together an
> SQL statement is perfectly valid and "WORKS",
> however, when anyof those variables might possibly
> contain user entered information (or any other data
> that is outside of your control) it is dangerous to
> use it in such a way.
>
> In those cases you should always use a
> PreparedStatement and the proper set...() method.
> Otherwise you are leaving yourself open for a world
> of pain in the form of an SQL injection attack
> (since I didn't notice you making any effort before
> building the SQL statement to ensure that none of
> the contents of the variables used contained
> anything that could have messed up your SQL
> statement, i.e. a ' or something similar and
> possibly much more sinister).
>
> Food for thought.
Why make things complicated by having two ways to do the same thing, just use the safer way.
It's also more readable and thus maintainable.
> Why make things complicated by having two ways to do
> the same thing, just use the safer way.
> It's also more readable and thus maintainable.
I was not advocating his use of Statement. However, there is a least a small amount of overhead involved with PreparedStatement that is not present with a Statement. There are also other reasons, why, at times, it makes more sense to use a simple Statement rather than a PreparedStatement.
Simply saying "Always use PreparedStatement" is not the answer. It is safe as it will (usually) work, but that doesn't mean that it is a pat, standard, always applicable answer (only most times).
"Having two ways to do the same thing" is a good thing, and I see no valid reason to restrict yourself to always (always being the keyword there) doing something in the same manner.
I can't think of any other situation to use Statement over PreparedStatement than when there are no parameters to be set.
And just to be clear, I meant always use PreparedStatement when you need to set parameters to the statement.
Do you have any other situations?
> I can't think of any other situation to use Statement
> over PreparedStatement than when there are no
> parameters to be set.
> And just to be clear, I meant always use
> PreparedStatement when you need to set parameters to
> the statement.
>
> Do you have any other situations?
Ah, but that is not what you said. With that statement is general agreement, and is, essentially what I had posted in the long diatribe that you responded to. That does not make a concated Statement invalid or incorrect, however, only ill-advised.
> Do you have any other situations?
Also, IN lists are a bear. First you have to find out how many arguments there are, then String concat or StringBuffer together the right amount of ?'s, then call the right amount of the right set....() method.
A pain, but definately advisable when the information to populate the IN list is unregulated, if, however, the data uses to populate the IN list is regulated, it is much easier to simply String concat or StringBuffer the SQL using the values directly rather than ?'s. But a String concat, or StringBuffer, is necessary in any case.
