Kevin, I'd personally be glad to share the code. Unfortunately, since it's company property, I have to get permission from the powers that be before I can release source code outside the company. Hopefully it won't take to long for my request to wend it's way through the bureaucracy. :(
I haven't seen problems yet with setObject, but I'm assuming it will take feedback from users of a variety of databases and drivers in order to know if this will work across the board. Re. the stored procs, I don't know - I'm guessing it's partly due to perceptions about increasing workload for our DBAs, or possibly lack of support in previous versions. Andrew -----Original Message----- From: Kevin Steppe [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 4:59 PM To: Log4J Users List Subject: RE: Log4j JDBCAppender Andrew, If you're willing, I'd love to see the code. I like your idea of the comma-separated keys and would like to see how you've implemented it. If setObject will work for all types then that will be the way to go. For my own enlightenment, why would a company prevent developers from using a stored proc. for repeatedly executed sql? Kevin --- "Tumpach, Andrew J" <[EMAIL PROTECTED]> wrote: > I've extended the JDBCAppender to do > PreparedStatement work. Here's a synopsis: pass in > a Hashtable as the message, with multiple database > columns' values in it. A new property in the log4j > property file contains comma-separated keys (in the > order used in the SQL statement) used to pull values > out of the Hashtable. Re #1 below, > PreparedStatement.setObject() works just fine so > far. Re #2, escaping is not an issue with Prep. > Stmts. Re #5, some shops don't let developers do > stored procs. My main problem right now is Ceki's > declaration of the uncertain future of JDBCAppender. > :) > > Andrew -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
