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 Jon Wilmoth wrote: >The double quote around the thread worked to fix the multiple single quote >problem. > >That sounds like a very good approach as it handles the previous problem and >should also handle the next problem (see #2). It should also improve the >also performance correct? > >#2 Unfortunately, the next problem is the weblogic thread string >(ExecuteThread: '11' for queue: 'default') also contains colons, which >oracle is interpreting as schema objects resulting in an SQLException >"ORA-00972 identifier is too long" > > >-----Original Message----- >From: Ben Sandee [mailto:[EMAIL PROTECTED]] >Sent: Thursday, June 06, 2002 8:23 AM >To: Log4J Users List >Subject: Re: Log4j JDBCAppender > >Kevin Steppe wrote: > >>Jon, >> Please post to the users list only for this kind of question. Now >>to answer your question: >> >>try: >>sql=insert into logtable (threads) values ("%t") >> >>For most databases you can use either ", or ', for varchar fields. >>Use the one not in the value. If both are in the value you have to do >>escaping. As far as I can tell the JDBC version in JDK1.3.1 does not >>have a generic escape call. If I'm wrong, someone please tell me so I >>can get that into the JDBCAppender. >> > >Kevin, > >Ideally the appender would support the optional use of PreparedStatement >objects, rather than building SQL strings dynamically. With a >PreparedStatement there is no need to escape any text values. For example: > >PreparedStatement st = conn.prepareStatement("insert into logtable >(threads) values (?)"); >try >{ > st.setString(1, "I can put single quotes ' and double quotes \" in >this text"); > st.executeUpdate(); >} >finally >{ > st.close(); >} > >I believe this would take some reworking of the current JDBCAppender, >however, due to the fact that simple text replacements cannot be used. > Instead there would have to be some way to associate a the integer >parameter index with a piece of data (%t or whatever). > >BTW, I don't actually use the JDBCAppender myself -- that's my >view-from-the-outside. > >Ben > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
