Kevin Steppe wrote: > The double quote should fix #2. Any time you are putting a string > into a varchar type field you should use either single or double > quotes. Without quotes you'll have all sorts of errors. As for > performance successful statements will always go faster than failed > statements :) > > The preparedStatement option seems nice in theory but I believe > doesn't merit the work: > 1) The configuration would need to be more complicated to properly > handle the variety of types/values/etc you might want to set. > 2) Escaping is still a problem, b/c the appender has to handle any > number of quotes in a general fashion (unlike your example where you > know exactly how many and where the quotes are) > 3) The performance value of preparedStatements is debate-able. > 4) Batch inserts make far more difference and will be included very > soon (it's being tested) > 5) stored procs will work the current appender which is the same or > better than preparedStatements anyway > > Stored Procedure example (works with MS-SQL, not tested on Oracle) > > sql= myLoggingSproc "%c", "%t", "%p" > > Kevin
Kevin, I agree it's not worth the effort -- primarily because for my projects I don't want log data stored in a database anyway -- and I work at a company historically known for it's database software! :-) (Sybase) I do take issue with two of your statements, #2 and #3 in particular. #2, I don't see how escaping is still a problem -- with string columns you can simply pass any data into the parameter without escaping at all. You don't need to know anything about the contents or the target database server. #3, this performance opinion of prepared statements is very implementation dependant. I'm not sure what exactly is giving you negative feelings towards the PreparedStatement object, but realize that the performance levels vary widely by driver -- the PreparedStatement implementation often gets the shaft when it comes to optimization time, I fear. For the JDBC driver produced by my employer, prepared statements and normal statements have effectively the same performance level -- it doesn't really matter how you are passing the parameters. With our JDBC driver, it isn't actually preparing the statement and caching the query plan on the server unless you enable a flag in the JDBC driver to explicitly do server-side statement preparing. If this is done, performance can vary widely depending on whether or not the statements actually get re-used or not. Many times it goes down, sometimes, if there is much statement reuse it will go up. Unfortunately the JDBC spec leaves out the possiblity of a parameterized "unprepared statement" for those times when I have a query that I don't plan on re-using. It really is almost obscene that we ever need to resort to generating queries by concatenating strings, as advanced as other pieces of the Java API's have become... <shrug> :-) Ben -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
