Problem with properties file

[GoogleCodeExporter]

What steps will reproduce the problem?

Use this log4jdbc.properties

log4jdbc.dump.sql.addsemicolon=true
log4jdbc.dump.sql.select=true
log4jdbc.dump.sql.insert=true
log4jdbc.dump.sql.update=false
log4jdbc.dump.sql.delete=true
log4jdbc.dump.sql.create=true

What is the expected output?
log for all transactions except the update ones

What do you see instead?
Nothing

What version of the product are you using? On what operating system?
1.2beta2
Windows 7

Please provide any additional information below.

Original issue reported on code.google.com by jaimea.m...@gmail.com on 24 Aug 2010 at 9:02

[GoogleCodeExporter]

Can you show me a dump of some of your sample sql?  It has to explicitly start 
with the word 'insert', 'update', 'delete', 'select' , etc. in order to be 
filtered, and anything that doesn't won't show.  This might limitation may be 
too strict, as often SQL can start with other keywords e.g. declare , etc. that 
I'm not checking for.

Original comment by arthur.b...@gmail.com on 25 Aug 2010 at 12:43

[GoogleCodeExporter]

This is one example, the problem is with batching statements, you add the 
string in the statement logger before you check if it should be logged or not, 
and the check fails because you only look for the first 6 chars in the string:

batching 1 statements: 1: update WONDER.CML_NF_ELETR_LOTES set 
ID_RECIBO=431000005062353

Original comment by soler...@gmail.com on 28 Aug 2010 at 2:34

[GoogleCodeExporter]

Yeah, that's a problem.  I'll fix it later.  I think attempting to determine if 
the sql is an insert/update/select/delete or whatever is definitely a slippery 
slope (although that is unrelated to the batching issue.)  I may remove this 
feature entirely or implement it in an alternative way.

Original comment by arthur.b...@gmail.com on 8 Sep 2010 at 2:09

• Changed state: Accepted

[GoogleCodeExporter]

considering the prior SQL is always written by you, should be easy to fix, 
maybe split the log call into 2 parameters, description and statement, so you 
always have the unchanged part to check and them add them later prior to write

Original comment by soler...@gmail.com on 13 Sep 2010 at 8:23

[GoogleCodeExporter]

yes that particular issue is fixable, however, the problem of reliably 
determining what type of statement the sql is, is tough if not impossible to 
solve in all cases.  for example, you could run an update and a select all at 
once in one sql statement (very common in a database I'm working with at the 
moment.)

Original comment by arthur.b...@gmail.com on 14 Sep 2010 at 12:58