How to Update Date data type field value in oracle

Question

I want to update records in a table that has a Date data type field. It's a oracle databse. I use the oracle thin drive to connect to the database. The everything works well, only when i try to update records that have date type value, something doesn't work.
I use the following stmt to update DB:
Class.forName("oracle.jdbc.driver.OracleDriver");
Conn = DriverManager.getConnection("jdbc:oracle:thin:@hostname:portnumber:schname", "uid","pwd");
stmt=Conn.createStatement();
String updStr = "UPDATE Article SET Archive = ' Disable' WHERE ArticleDate = # " + sqlDate +"# " ;
stmt.executeUpdate( updAStr ) ;
But I always got the SQLException run time error, which is "ORA-00911: invalid character"
Who can help me to find out how to write the above Update statement correctly? esp. that how to present the Date type variable in the statement.!
BTW, sqlDate is a Java.sql.Date variable, Is it "# " + sqlDate + "# " the right way?
Many thanks

Answer 1

What do you get out of Oracle's TO_DATE that java.sql.PreparedStatement.setDate()
won't give you? - MODWell, I don't know that I've used all capabilities of either, but when it comes to managing Date Strings my Oracle bias :) would be to code using Oracle's TO_CHAR and TO_DATE functions. Perhaps someone can tell me vendor neutral ways to do something simiilar to managing these input date/times (and hopefully just as easily, pretty much all done in a single line, single function)?
WHERE aDATE > TO_DATE('2010','YYYY')
WHERE aDATE > TO_DATE('2010 AUG 22','YYYY MMM DD')
WHERE aDATE > TO_DATE( 'January 15, 1989, 11:00 A.M.', 'Month dd, YYYY, HH:MI A.M.')
I believe most databases have something similar to this, although I have found Oracle's to be the most flexible and consistent, if not the most intuitive. Other vendors (DB2, SQL Server, Access) don't force you to always be explicit, and can accept a variety of date strings without masks. The problem is that while you might not be getting an error, it also may not be parsing your date as expected.
One could argue that this vendor specific hodgepodge of literal date/time strings is only one program modification away from disaster. They might be right.
Just to be clear. I'm not recommending using a vendor specific approach, but it's not a perfect world and somtimes you have to use what works easiest or best or fastest, and in some cases, that is the vendor specific alternatives.